On 09/09/11 15:03, Joe Emenaker wrote: > On 9/9/2011 1:56 AM, William Zwicky wrote: >> We could let each synthdriver decide their own queue policy (ie, only >>> hold one message per widget, or hold all of them). A more-complicated >>> solution would be for widgets to indicate which messages belong as a >>> set... but I don't see a need for that. >>> >> I think my example above matches that last case. Once the message for >> widget A has started sending, other messages can be queued, but they can't >> be sent until widget A says 'handshake complete'! > My initial reaction to this is that this isn't an issue with the rate of > data sent by the MIDI layer, so the MIDI layer shouldn't be involved. > I'm thinking that the synthdriver should be able to manage all of this > itself. The only reason we'd need to trouble the MIDI layer with this is > if your synthdriver either needed special transfer-rate limits *or* if > your synthdriver needed to block all traffic for *other* synths on that > interface while the communication were happening. Otherwise, this should > be able to be managed by the synthdriver.
I think it does concern the midi layer because transmitting data to one synth could overload a different synth on the same port. Although we can expect a synth driver to know how much traffic its device can handle, we can't expect a synth driver to care or know about other synths. So it could make sense for the midi layer to have the ability to enforce the lowest common denominator throughput if required. I would think drivers would need to be able to specify a maximum number of bytes to occur in a specified timeframe. But maybe for a driver the problems occur only while processing large sysex messages, in which case maybe it would need to lock its port for e.g. 30ms after sending a message. frankie ------------------------------------------------------------------------------ Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
