Subject: Re: [linux-audio-dev] DSSI (Disposable Soft Synth Interface) 0.4
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Fri Jul 16 2004 - 16:18:16 EEST
On Fri, Jul 16, 2004 at 02:11:45 +0200, Alfons Adriaensen wrote:
> On Fri, Jul 16, 2004 at 12:52:28PM +0100, Chris Cannam wrote:
>
> > I'd like to announce a new version (numbered 0.4) of the DSSI synth
> > plugin API proposal.
>
> >From the RFC:
>
> > The host does not send updates to the UI for port changes that the
> > UI itself initiated; likewise the UI must not send port changes back
> > to the host that the host itself initiated.
>
> While the second part of this surely makes sense, I'm not so sure
> about the first. In MCV terms, the UI is both a C and a V. With the
> definition above, the host assumes that both parts 'know each other'.
> This may be the case for a UI, but in general this will not always
> be true. Even in the case where it is, the following should be
> considered:
If you take the opposit approach and echo all the UI initiated changes back
to all parties then it becomes very hard to write a UI that doesnt glitch
unpleasently during gradual changes. You /could/ tag re-echoed changes
when thier sent back to the UI, but its a bit messy and unnecessary. the
only advantage it could give is if you timestamp the host messages against
when it applied the change, and that requires ntp support, and some
complex OSC stuff to do.
> - The design of the UI is probably simplified by separating the C and V
> functions.
I disagree (in this case). The UI /is/ both C and V, the case where you have
a single control that has both independent C and V is extremly rare -
infact I cant think of a case where it happens in audio software and I'm
not sure how it would make sense in LADSPA.
> - In some cases, the host may refuse to do what the UI asks for, so the
> UI should not simply assume that it knows the new state after a command.
If that is the case then the host just sends the correction as a normal
change. The UI control will flick to the real position, but thats
acceptable I think. Its not a common occurance.
> - If the UI has its own internal path to update V from the actions taken
> by C, events may arrive at V out of order, for example:
>
> 1. the host sets parameter P to value X, and sends a message that
> it has done so.
> 2. the UI sets P to Y, and displays Y.
> 3. the message from 1. arrives, the UI now displays X while the
> actual value is Y.
Yes, this is a genuine problem. It is very hard to solve though, and
simply echoing all changes to all parties doesn't help.
> More generally, not reporting the results of external commands makes
> any extension to multiple C or V impossible.
*External* commands are send to the UI (for this reason), its just local
commands are not echoed back. Maybe thats not clearly expressed. I belive
that this is standard practice in MVC systems, but I could be wrong.
The situation should be that changes are sent to all parties, except the
originator, and there may be multiple UIs, at the hosts discression.
- Steve
This archive was generated by hypermail 2b28 : Fri Jul 16 2004 - 16:23:46 EEST