[...] > Within ALSA we have two priority queues, one for tick (bar,beat) scheduled > events, and one for clock (ns) scheduled events.
As MIDI uses MIDI tick messages for time based sync and MIDI clock messages for tempo based sync I kind of feel the ALSA sequencer naming is a little confusing :) > In case of immediate > scheduling the priority queue is bypassed and the event submitted in the > receiver's fifo (which would be your immediate queue). > > Due to potential blocking at the receivers you'll need a fifo for every > destination. Correct, that's what I've been calling queues. > Reason for having 2 priority queues with different reference is to cope with > tempo/signature changes while remaining in sync. The clock and tick priority > queues are in fact parallel in ALSA. I don't want to support tempo (MIDI clock) scheduling in my MIDI API. This could be better handled in the application itself. Also, when slaved to MIDI clock it is no longer possible to send messages ahead of time, and not supporting this in the API makes that clear to the application programmer. > Since especially for soft synths (but also for some -undocumented!- USB midi > interfaces, like Emagic AMT) Yes, I've repeatedly asked Emagic for documentation on their AMT protocol without success. :( > the events need to be scheduled ahead (sort of > a pre-delay, say 10ms or more) to let the device/softsynth handle the micro > scheduling, it would seem a good idea to handle this at the clock based > queue. Since variable predelay in ms would be not quite friendly to the tick > based queue (different units), it might make sense to have the tick based > queue send events into the clock based queue instead of immediate delivery). I'd rather see MIDI clock sync handled in the application. This also keeps the API cleaner. [...] > A good reason for applications to use (UST/ALSA) scheduling instead of > taking care of micro scheduling itself and using rawmidi interfaces is > better support for softsynths to trigger at the right spot in the buffer, > and for the upcoming smart (eg. USB) midi devices. Or even MWPP. [...] > You can't overcome the limits of the MIDI physical line if that's your > target transport. However when sending events to soft- or onboard synths > these limits are different (typically less of an issue). > > When using events instead of midi bytes the merging is a no brainer I was planning on doing that, but even then there are issues with for example (N)RPNs. > leaves room for events not defined in midi spec). ...I'm not sure that is a good idea. What kind of events? --martijn ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
