On Thu, Sep 8, 2011 at 2:31 AM, frankster <[email protected]>wrote:
> (just have each driver register a max amount per time frame it can handle). > What if the delay depends on the nature of the change? Maybe parameter changes are no problem, but those huge patch sets take a few seconds to digest. It might be possible to send a request that is only answered when the synth is done, or you might have to just set a 3 second timer and hope. The sender could then store the latest value received from the widget > for a parameter, then check with > this central rate tracker whether its allowed to send or not, and if its > not allowed to send then it stores > the widget value and requests notification from the central rate tracker > when it would be ok to send. > In the meantime if any additional widget events come in before the > notification, they can store their values > too. Finally the notification comes through from the central rate > tracker and it sends it. > > Its getting a bit complicated because maybe if two widgets were modified > in close succession we might > need a queue of notifications so that we don't miss out on one widget > update because it was drowned > out by another. > Yeah, that's pretty much it. When a parameter changes but we cannot send, we save the new value, and set a flag. When an opportunity to send arrives, we scan for those flags and send the first one we find. But even this may be synth-dependent -- if multiple params change, I may want to build a single message that updates them all at once. Can anyone think of anything simpler that would do the job? Although one > advantage of this is that it would > keep the driver simple, and all the complexity would be in core base > classes. > The only alternative I can think of is to defer the high-level layer, and instead try these tricks with individual synths. After that, we can hunt for commonalities, and implement a higher-level layer. -Bill Zwicky ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
