16 Jul
2004
16 Jul
'04
3:36 p.m.
On Fri, Jul 16, 2004 at 05:21:15 +0200, Alfons Adriaensen wrote:
A simple button, such as the stop buttons in Aeolus.
In the first design, the buttons would light up whenever the GUI was thinking
a stop was 'ON'. As more functions (presets, grouped changes, MIDI) were added,
the logic to control this became quite complicated, and in fact the GUI thread
had to maintain a complete copy of the logic that was already present and
necessary in the audio thread.
Now the button lights are controlled by messages from the audio engine, and
by nothing else - it's much much simpler.
I see, but the DSSI case is a bit different because any such logic for
single controls must be purely in the UI, as the plugin part has no way of
updating its own input controls (its LADSPA essentially).
The equivalent would be if the plugin has a set of output controls that it
sets (to reflect engine driven complex changes), and those reflected the
true state of the controls. In this situation the current DSSI scheme will
work just fine, as the ins and outs will have seperate messages and ty
will be sent to the UI and the UI wouldn't change its widgets in response
to user action, but in response to the plugin->host->UI message.
I disagree. It makes the host logic slightly more complex and the UI logic
slightly simpler. I think thats a win. The UI can treat all updates events
exactly the same way, and it requires no explicit support.
Its also very simple in the host:
receive UI update
if its ok
apply it
else
change to it OK value
tell UI
You need that if in any case to trap and handle the "bad" value. Its also
an extreme corner case. Also note that I've not yet seen a LADSPA or DSSI
host that does this.
DSSI doesnt support that. You can only control the plugin. If you step
outside it then your going beyound what reasonable in a plugin API IMHO.
It *does*, if messages are kept in order. This may suggest that UDP is not
the best choice.
You still have this race as most protocols are full duplex, if it were a
half duplex comms then it might be OK, but still only if you only have one
UI.
I agree that TCP would be better (for other reasons), but not many OSC
implementations support it, its tricky, and I dont want to limit people to
a small set of implementations. Maybe a later version could require it.
The DSSI API does distinguish between the different OSC transports, so
adding TCP support would be easy.
How does the host distinguish between an 'external' command and one that
came from the UI, if both arrive by UDP message ?
It can tell from the message. The address path is different.
That analogy is not relevent. I have implemented a DSSI UI and I can
assure you that, in the general case, its easier not to have your own
updates echoed back. Three others have implmentation experience too, they
can speak for themselves. If you really want the update to handle some
corner case in a UI then you can just send the message to yourself :)
- Steve
- 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 > - 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.
This requires extra logic: if a command is accepted, the state change
is sent to all except the originator. If it is not executed, the current
state must be sent to the requester. It's much simpler to broadcast all
changes to everybody. One mechanism to rule them all... and I'm
not sure how it would make sense in LADSPA.
Not all commands are ultimately executed by the plugins. Think of connections
in a softh synth: they are executed by the host, and it could make sense to
refuse them. - 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.
Imagine this list, but you don't receive your own posts... Would it be
easier to follow ? Or to implement ?