Hi,
> > However, I'd like to point out the possibility of an alternative approach
> > (which may have been suggested in the past): Separating the song playing
> > from the actual song and event control (akin to what the DOS sound server
> > used to do). This would mean:
>
> Yes I think I mentioned before that this is how DirectMusic works on Win32.
> Although with that, all of the songs would need to be decoded right at the
> start and put into a song library, and I'm not sure if that's exactly what you
> mean.
I'd prefer on-demand song decoding, but that's just a detail difference
from what you meant.
> So is what you're saying is decode all the songs on startup, and then just have
> what are currently commands in the sound server implemented as events that stop
> and start everything?
We'd have to split up the songs at the loop points to facilitate looping
(not all songs restart at the beginning when looping), but essentially
that's what I meant, yes.
> That should make running the sound server (on any
> platform) a lot smoother,
Only if we can guarantee synchronity, which we can't.
> simpler,
Certainly not in the overall design, but for individual platforms, which
is more important in this context.
> and faster as well
This would depend on the platform in question...
>, as we wouldn't be
> dealing with two things at once.
Well, _someone_'s still playing the music; I don't think there's much of a
performance difference between running playmidi in a separate process and
using our own sound server.
The main advantage will simply be a greater flexibility when implementing
the sound driver. I wouldn't expect any conceptional performance
improvements; OTOH, music might run out of sync with animation
more easily. Since most platforms will provide some sort of notification
(wait(2), a callback, ...) when the current song is finished, we might
want to consider splitting up songs at cue points, too, for maximum
synchronity. This could be overkill, of course, and we should first try it
the other way 'round.
Any volunteers for this operation?
llap,
Christoph
