On Wed, 2011-03-02 at 21:10 -0500, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 8:54 PM, David Robillard <d@email-addr-hidden> wrote:
> > On Wed, 2011-03-02 at 20:36 -0500, Paul Davis wrote:
> > [...]
> >> well, almost. as i mentioned, AU doesn't really route parameter
> >> changes via the host, it just makes sure that the host can find out
> >> about them. the nicest part of the AU system is the highly
> >> configurable listener system, which can be used to set up things like
> >> "i need to hear about parameter changes but i don't want to be told
> >> more than once every 100msec" and more. its pretty cool.
> >
> > 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)?
>
> well, as we've discussed on IRC, its a bit more than that. its also
> "inform me via the following event loop".
This could be nice sometimes, but that is host library implementation
stuff (i.e. the actual plugin/UI API is not directly involved)
> but yeah, i suspect that
> your reduction would be sufficient for all purpose.
Yeah, I can't think of any good reason otherwise, anyway.
> the event loop
> part .. that seems a bit harder to do in a neutral way.
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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Mar 3 08:15:01 2011
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2011 - 08:15:01 EET