On Wed, 2011-03-02 at 20:36 -0500, Paul Davis wrote: [...] Do you think this could be adequately expressed as a few fixed cases, like "full data transmission", "rapid updates" (very roughly once every few blocks and/or screen refreshes), "moderate updates" (very roughly every second or so), "slow updates" (very roughly every few seconds)? This would be much more feasible within the framework of LV2 UIs for various reasons (and seems more reasonable anyway, since the host can't really guarantee accuracy to a specific ms interval). If similar benefits could be had without having to invent a hulking parameter polling API, that would be nice... Lars' proposed new UI extension has dynamic "inform me about this port" API (rather than static data for this as in the current UI extension), so stuff like this should be considered. -dr

On Wed, 2011-03-02 at 21:10 -0500, Paul Davis wrote: This could be nice sometimes, but that is host library implementation stuff (i.e. the actual plugin/UI API is not directly involved) Yeah, I can't think of any good reason otherwise, anyway. A library could do it. Personally, the architecture of Ingen is such that it probably wouldn't be useful to me. I think this feature is at least somewhat based on AU having sort of "hidden" parameters, and being tied to its framework (whereas LV2 has a specification/implementation split, i.e. the spec is "neutral"). In LV2, the host fully knows the value of plugin parameters; stuff like "notify the UI about the current value every so often" is code you stick in the middle. Perhaps host-specific code, perhaps a library, either way. It would be a difficult project to make such a library that suits everyone's needs though, and it would be a massive thing. I may be missing the point; as I understand it the point here is to provide this kind of interface for the UI code? (e.g. UI says I am interested in the value of parameter foo every second or so). As far as LV2 specs go, we do need a way for the UI to request notifications like this, so that, from the UI author POV, the nicety of the AU system is there. IMO it is a Good Thing that the host can implement the functionality in whatever way best suits that host - a host with separate UI and engine processes would have a very different implementation strategy here than a simple one with a single address space. Since we lack (and actively don't want) an authority to say "here is the framework, if it doesn't do what you need, tough luck", we need that specification/implementation split. Re: the value/event port dichotomy, all of this is about values. Is there any sensible/desirable equivalent for events? Does it make sense for a UI to only want to know about some events? Which ones? Events of a certain type comes to mind, but I don't know if there's any other reasonable possibilities since you can't compress events in general. -dr