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. > Finally, I'd like to vote against the user rate-limit option that was > proposed earlier. Rate limiting is not a real feature, it's a workaround to > cope with flaky synths. And these workarounds should be properly researched > and coded in the driver so that the user doesn't need to worry about it at > all. It *might* be useful as an emergency feature to cope with situations > the developer didn't discover, but it should *not* be part of the normal > operation of JSynthLib. Okay... just so we're clear, you're referring to *user* rate-limit. The idea of the end user being able to determine how often widgets send updates to the synth, right? But raw data throughput limiting in the MIDI layer is still a useful feature? - Joe ------------------------------------------------------------------------------ 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
