oh ok ..
ppl use so many smileys these days .. it causes smiley-inflation
"I think I have stated before, but euhm.. wouldn't it be a good thing to see what the Moonsound owners would like to see for a tracker?"
Realfun supports also 32 channels (instead of just 16) with over 16 steps because of reactions on this forum
"I for one thought the Realfun trial version had some nice features and was hoping you'd elaborate on those instead of moving more towards 'something like Meridian' (which you kind of are doing right now, if you ask me)."
Realfun isn't moving towards Meridian at all. It doesn't support MIDI, or layered voices, mouse, etc. It will be very much like the trail version, but with a new dataformat, a new look and better voice selection screens. And better sample support I did have some more MIDI sequencer-like ideas, but those are quite hard to implement on MSX
On the other hand, if Realfun should be somewhat between Moonblaster and Meridian, it should move towards Meridian, don't you think
Well, as a programmer I don't care if it can only play half an octave of notes, as long as it doesn't take 50% of my precious CPU time away...
By that ofcourse I mean, it should be FAST above all...
Yup, I think the first and foremost objective of Realfun should be SPEED. Both Moonblasters have their limitations and Meridian is probably going to be a highly CPU-intensive replayer. To be able to use the Moonsound in games and demo's, the MSX community really needs a versatile (but quick) tracker and replayer. So, more details: great, but not if it drastically increases CPU load
Either way, euhm.. we haven't seen you around on the forums for a while and that gave me (and probably several others) the impression that you weren't working on Realfun anymore. It's good to hear you're still in action. I hope you keep us posted on a more regular basis, that way at least I will give as much feedback as I can
It should depend on the amount of channels ... basically the amount of channels should be quite open.. if some coder says: 'we require tons of cpu time' then it means that the composer needs to reduce the amount of channels .. but if the coder says: 'we don't require a lot of cpu time', then the composer can use many channels.
So, keep it flexible/open..
Well, usually that should pretty much be automatic. If a channel contains a bundle of zer0s a replayer would normally do something like OR A, JR Z NEXTCH. That shouldn't take up too much time. I've never tried it, but I _hope_ even MoonBlaster 'supports' that 'trick'. Usually the CPU time goes into calculating the data sent to the device and actually sending it.
Oh, and open is a horrible word for both the programmer and a computer. Everything _needs_ limits in order to be quick. You don't want to be checking variables all the time if you want to make a fast replayer. All you need to do is balance those limits with the desires of the average musician.
There are solutions to being completely open and flexible and still being extremely fast. I plan on implementing those solutions in an editor/player of my own some day... (Which, needless to say, will kick major butt, but as of now is little more than vaporware.)
Additionally I'll just say that "OR A, JR Z NEXTCH" 'trick', although the most common, is a slow solution
I use 'ORAJRNZNEXTCH' in Realfun It's not only a slow solution, it's also an easy solution. And fast enough in a tracker... (Even worse, I don't see 'better' solutions
)
Moonblaster is full with 'easy solutions' as well... (though a few less than FST )