#27171 - ProblemBaby - Tue Oct 05, 2004 10:27 am
Hi
it is one thing I haven't got yet (probably more things later but for now)
Iam trying to make a modplayer and Ive samples that is different in frequency do Ive to stick to one frequency for all my samples?
or doesnt it care. I dont exaclty understand the relationship between all the stuff of 8393hz, amiga period table, sample frequence, finetune, and the actual frequency on the GBA.
some information would be great!
#27209 - ProblemBaby - Wed Oct 06, 2004 3:47 pm
OK, Ive started to understand things now!
I understand that Ive to stick to one frequency.
But...
If I open my MOD (with my 16khz samples) in ModPlugTracker
the C-5, Middle C (My sample without pitch) is written C-6
I understand that it is becuase the default is 8393 and 16384 is about one octave up.
In SkaleTracker though they are corrected to C-5.
How can they Calculate that cuz the MOD has no information about frequency right?, just length!
I want to correct it to C-5 in my mod2gba too so the pitch is totally correct. But I dont really know how.
second I want to build a Incremt table for each note.
So I know how much to increment the sample each sample =)
I know that
Inc = (frequency<<12) / 18157 (in my case)
I also know that C-5 has frequency 16384 C-6 twice as much
but what about the notes between?
is it like I think a formula or is it unlogical?
Thanks
#27219 - SmileyDude - Wed Oct 06, 2004 11:14 pm
| ProblemBaby wrote: |
How can they Calculate that cuz the MOD has no information about frequency right?, just length!
I want to correct it to C-5 in my mod2gba too so the pitch is totally correct. But I dont really know how. |
I'm not entirely sure what you are asking, but I'll give it a shot (and, it may be a little bit off, so take it with a grain of salt :) ).
The MOD file stores periods, which are how many 3.5MHz clocks there should be between each sample. But, on the GBA, this value is pretty useless as is -- you need to convert it to a sample rate. The sample rate is basically 3.5MHz / period.
Now, the MOD document I have has differences for PAL and NTSC machines, and I'm assuming that this is for the Amiga. But, I don't really understand why these should be different. Is this just a result of tuning for NTSC and PAL that causes C-1 to be different periods? And if so, doesn't that mean to accurately playback a MOD that you need to know if it's tuned for NTSC or PAL?
Does anyone have the real values that should be used in the conversion from period to frequency? :)
As for what to display, if the period doesn't match what the tracker has exactly, it has to find the closest match. It could also be a difference between NTSC and PAL again. But, in reality, what's being displayed has no bearing on what's getting played :)
| ProblemBaby wrote: |
but what about the notes between?
is it like I think a formula or is it unlogical? |
It's a formula -- as you've seen, going one octave down or up involves multiplying or dividing by 2. The tones in between are basically the 12th root of 2 apart, or approximately 1.05946309. There are 12 tones in an octave.
_________________
dennis
#27221 - ProblemBaby - Wed Oct 06, 2004 11:31 pm
Thanks for the information about the frequeny now I understand that=)
My other questions was a bit hard to understand I also think!
Anyway I try to describe it again.
If I load a sample to my tracker that isnt 8393hz instead it is 16384 (for example).
Ive to play a C-6 to hear the original sound that should be C-5 if it was a 8393hz sample, right
well C-6 isnt totally correct either but it is close enough.
this is the case for modPlugTracker BUT if I open the song in SkaleTracker it kind of knows the frequency I dont understand how cause it writes C-5 for the original sound. and not C-6.
And I want to work with 16khz samples and also be able to play
C-7 notes but they would be out of range if I dont correct them C-5.
Hope you got my question!
#27229 - poslundc - Thu Oct 07, 2004 12:53 am
| ProblemBaby wrote: |
| And I want to work with 16khz samples |
Then MOD isn't for you. Try one of the variations on it (S3M, IT, etc.). Most of them support higher-frequency samples, but you won't get MOD working with them unless you hack the format considerably.
Dan.
#27240 - ProblemBaby - Thu Oct 07, 2004 8:13 am
I still wont the simpleness (does that word exist?) from the MOD-format
the fantastic thing with for example SkaleTracker is that I can make a song without telling the program that it is a MOD, XM, SKM so 16khz works.
and cause I will use a LUT for frequency in my musicplayer I cant accept a lot of different samplerates.
#27241 - DekuTree64 - Thu Oct 07, 2004 8:52 am
Do the variable frequency MODs from that tracker play properly in other trackers? Do they still show the correct note names (C, C#, D, etc)? It's possible that they just generate a period table for each sample based on its original frequency, and because MOD only stores the actual period values rather than note numbers, it would work as long as you could regenerate that same period table after saving/loading the file so you could keep the note names the same. The hitch is that MOD doesn't store the original frequency anywhere, so I don't know how they pulled that off. Maybe just append some custom data to the end of the file or something.
Most likely you won't be able to handle that in your player easily unless you store the period values like standard MOD, instead of converting them to note numbers or whatever. Working in periods involves a divide per channel to go from period to Hz, but that shouldn't be too much of a problem, especially if you only do it when the frequency actually changes. Even if you do go with a note/frequency table to get out of the mandatory period-to-Hz divide, you'll then have to divide when doing vibrato/pitch slides and stuff that are period-based, so you may want to work in periods to begin with (that is, assuming that I guessed right about how that tracker works)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#27250 - ProblemBaby - Thu Oct 07, 2004 5:18 pm
Well to me its like magic.
I will use XM instead I think.
anyway i have one little question more..
Ive coded the Shell for my player in C
it looks quite much like the one made by DekuTree (Day 2 of the Audio Mixing tutorial).
But it is damn slow! I dont do anything else then mixing even though the ?mixing two samples take 97% of the GBA if I try to have 3 or 4 it is totally distorted. is it that slow in C or have I missed something really important??
#27253 - SmileyDude - Thu Oct 07, 2004 5:49 pm
| ProblemBaby wrote: |
| But it is damn slow! I dont do anything else then mixing even though the ?mixing two samples take 97% of the GBA if I try to have 3 or 4 it is totally distorted. is it that slow in C or have I missed something really important?? |
In theory, you can write a fast mixer in C on the GBA, but I'm not really entirely sure on how it can be done. I had pretty much the same results on my first mixer in C -- I could mix a couple of channels, but as soon as I added more channels, it all fell apart. I found it much simpler to bite the bullet, and write a mixer in asm. By doing that, I was able to optimize the mixing loop quite well register wise, and was easily able to pull of mixing more than 2 channels at once :)
_________________
dennis
#27256 - poslundc - Thu Oct 07, 2004 5:59 pm
| ProblemBaby wrote: |
| But it is damn slow! I dont do anything else then mixing even though the ?mixing two samples take 97% of the GBA if I try to have 3 or 4 it is totally distorted. is it that slow in C or have I missed something really important?? |
1. Have you tried it on hardware? Remember that emulator slowdown does not equal slow code.
2. Playing slowly or distorted sound doesn't necessarily equal slow code either; it's far more likely to be incorrect code than slow code.
It is far more likely that your mixer is too slow to keep up with the sound processor rather than too slow to run on the GBA. It is extremely suspicious when you say it takes 97% of the GBA's processor, in fact.
A C-coded mixer should, in fact, be sufficient to play music so long as it's efficiently coded. If you want to combine it with other things (like a game) then it will probably have to be coded in assembly.
Dan.
#27260 - ProblemBaby - Thu Oct 07, 2004 7:13 pm
I meant 79% but it isnt fast either.
First I want to get it working in C then I will convert it to ASM.
and put in in IWRAM.
Well the code as I said is much like the code from DekuTrees tutorials on the topic.
| Code: |
for (n = 0; n < 304; n++)
TempBuffer[n] = 0;
for (n = 0; n < 304; n++)
Snd.CurrentMixBuf[n] = TempBuffer[n] >> 1;
|
I tried to just have this code in my update function to see how much that was spent.
and it was 12% can it be true??
#27267 - DekuTree64 - Thu Oct 07, 2004 9:22 pm
Do you have the mixer code compiled as ARM in IWRAM? That should speed it up a bunch, but even THUMB in ROM shouldn't be THAT bad. You'll probably want to rewrite in ASM eventually, but C should be able to mix at least 4 channels in a reasonable amount of time.
For what it's worth, I actually have some free time again, so I'm back to writing on the article series. Hopefully I'll have the beginnings of a MOD player up within the next few days, which should be somewhat helpful for doing XM too.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#27268 - ProblemBaby - Thu Oct 07, 2004 9:29 pm
Nice, I will check it out!
Actually iam trying to mix 8 channels.
But that is all i do.
Ive tried to optimize a little bit, so now I can play 3 channels with 97% CPU=)
#27280 - tepples - Fri Oct 08, 2004 2:48 am
| SmileyDude wrote: |
| In theory, you can write a fast mixer in C on the GBA, but I'm not really entirely sure on how it can be done. I had pretty much the same results on my first mixer in C -- I could mix a couple of channels, but as soon as I added more channels, it all fell apart. |
The mixer in Tetanus On Drugs is in C and somewhat optimized. The keys are 1. ARM code in IWRAM, 2. a bit of explicit unrolling, and 3. occasionally glancing at the generated assembly code. It takes about 20% CPU when mixing eight samples at 18 kHz. Sure it's not as efficient as AAS, but I'm not enough of a genius to understand how the Payback texture mapper works either.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.