Hi Christoph, Thank you for your positive comments, it's great to hear that!
> > It's looking like this will in the end actually be a re-write of the current > > MCI driver, so no. Unfortunately I have to do bit shifting crap to put it > > into the format Windows needs which I'm having some trouble with. (Each > > (non-SysEx) MIDI command needs to be packed into a 32-bit unsigned int.) > > This should still work with the song iterators (they're supposed to give > you a single MIDI instruction or tell you to wait each time you iterate on > them, after all). Thing is, if this was done platform-independantly, we > could popen() timidity on UNIX, (partially) solving the complaints of some > people that don't have a sequencer or are willing to set up OSS to emulate > one. I'll definitely have a look at the song iterator stuff, that looks useful. Currently what I'm doing 'just to see if it will work' is using a very simple sound server that uses midi_write_block() to dump the whole song to the midiout driver when SOUND_COMMAND_PLAY_HANDLE is received. Then, in the win32mci driver, I'm packing the bits for MIDI commands and running status data into an array of unsigned ints, as required by MCI. This has one or two logic problems currently which perhaps can be overcome/made simpler by using song iterators or expanding on the song iterator code. This is all a short-term solution however, because once a block of MIDI music has been sent to be played, you can only pause the music, not change it in any way. This makes it messy (if not impossible) to fade handles, mute a channel, etc. or to give any flexibility. Hence, I plan to later use the double-buffering scheme as described at http://www.borg.com/~jglatt/tech/stream.htm . This means having two 'blocks' of MIDI data - one playing and one queued. Perhaps 15 ticks (one quarter of a second) of MIDI music might be queued at a time. Then tunes can be modified without too much trouble. Alex.
