> > > channels. There's a world of difference when you use a NNA-type system. > > > >That would require a lot of channels though... Wouldn't it be easier to, for > >example, fade out a channel at a really high speed right before the next > >note instead? > > depends on what channels you mean, internal channels won't exceed 24,but > visual channels can be any number ranging from 1 to 100000.. but lets asume > that we limit the visual channels to 24.
Mixing is virtually impossible on the Moonsound... At least, not real-time. This because you can't play notes while updating the waveram and a short while after. This is a rather big limitation of the OPL4, imho. > When you play 4 notes in 1 visual > channel (and all notes continue), internally it uses 4 channels, it's the > same as spreading those notes manually but this method works better. I > mean, face it: you don't want a split melody, spread over 4 channels, it > looks messy and you're way less flexible. (in most cases then, you're just > copying/pasting patterns and replacing notes with others that way, just > because it saves you work) Your midi equipment works this way too! You're right. But, it reduces the amount of channels you can use quite drastically. And er, well, when watching a song with a split melody playing (or even better: when watching a semi-vu(or whatever)-meter) it looks kinda pretty :). > >Naahhhh it's not that slow a processor... 24 divisions within one interrupt? > >It should definately be able to handle that. However, don't expect a game to > >be running in the background while you're at that ^_^. > > ah, in that case, there's still hope :) anyway, what's the intention of > such a new tracker then? making tunes for a music disk or making tunes for > a game ? As I said, you can make an 'optimized' file format and replayer especially for performance (but not so much space)-oriented applications, like for example a game. That'll also add a little protection (in case you want that), 'cuz it'll be relatively hard to convert the 'optimized' file back to its original again. On a sidenote, this 'file optimizer' / replayer could actually already have been made for Moonblaster. If I'd programmed a game with MoonSound music in it I think I'd have done that. Anyways, back to the point, frequency tables in the replayer are just plain arse, because they haven't got a free base frequency, and they're huge. Ahother thing, giving the frequency for every note might put a little strain on the file size (I personally don't care too much about that, but alas). Usually it's 1 byte/note in MWM format I guess? With frequencies, it would then be 2 bytes/note. What could also be done, is use a solution like, use 1 byte/note + a 256-entry lookup table (with the frequencies belonging to the note). This ofcourse also has limitations, but those can be worked around again. Downside of this approach is that the replayer has to look up the entry, which in itself is not really slow, but still slower than getting the value presented right away. Or, you could throw in some huffman compression, whatever, that would not save RAM space but it would save disk space. There's lots of ideas. ~Grauw _______________________________________________ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
