16 Jul
2004
16 Jul
'04
11:28 a.m.
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:
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.
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: - 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