From: William Z. <wrz...@po...> - 2011-09-08 10:02:23
|
On Thu, Sep 8, 2011 at 2:31 AM, frankster <jsy...@te...>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 |