> PLEASE, PLAIN TEXT!!!
>
> I really HATE HTML-formatted email, even though my email client supports
> it.
OK.
> Doesn't the tone number remain the same??? So then why store it?
> Oh, wait, I get it. The tone number depends on the frequency number. Well,
> there are two options:
> - just store it, don't really care about the size, or
> - only store it if it changes.
Then it'll be the first option, because the second one will make things
complicated you use patterns more than once. Take a look at this example: a
song has three patterns, which are played in the following order: 0,1,2,1.
In pattern 0, a note is triggered for the first time, so it has to be stored
as frequency+tone. In pattern 1, a note is played, and it can use the same
tone, so you only have to store the frequency. In pattern 2, another note is
played, but it cannot use the same tone so you have to store frequency+tone.
After that, pattern 1 is played again. It won't sound good because the note
uses an other tone.
Now there are several options to avoid this:
-use patterns only once -> limitations for composer, so don't use this!
-convert the song in such a way that it can tell if there's such a situation
and create a new pattern if it's neccesary.
Both options will increase the size of the song, but apparently you don't
care about that :)
[about linking notes]
> Not really. It's quite much the same as playing notes, except for that the
> key is not switched off for a short while.
Linking notes is actually quite easy. The replayer already knows which freq.
table it has to use, it only has to get a new freq. from it (offcourse it
has to do some other stuff, too). But with linking notes you'll have the
same problem as mentioned before (the freq. distance C4->D4 is smaller than
F4->G4). This can be solved in the same way as mentioned before. And you'll
also have the same problem with the transpose command, which can be solved
in the same way.
> So this way 2/3rd of all the calculations can be saved...
You've got it right. It's possible to bring CPU usage back to 15% this way
(that's what it uses in the third int of my replayer).
>>My replayer now has a CPU usage of about 25% per int.
> That's a lot... can be critical for a game...
If your game is CPU hungry, it'll be critical. But you don't have to lose
VDP-'power' because of the replayer, if you do it right...
BTW, it uses 25% when you set the number of channels on 24. If you set it on
16, the replayer is about as fast as a .MBM-replayer (15%-20% I guess).
> ...actually I'd like a new fast music-format which supports both Wave as
> well as FM (ofcourse it won't be fast anymore when it's used up to its
full
> potential, but then just don't use it to its full potential). FM sounds
have
> great possibilities (the MB 'X' command) but are still very small. I
really
> miss FM-sounds in the MBWAVE music nowadays.
Well, it should be relatively easy to change MBFM in such a way it could
support 24 wave-channels. And it would also be nice if it's possible to use
2 events per step per channel (or even note, volume, instrument, effect). It
can be done; who wants to do it? (I don't, I'm already working on something
else)
Arjan
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
****
