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 - 20:26:16 EEST
On Fri, Jul 16, 2004 at 05:21:15 +0200, Alfons Adriaensen wrote:
> > > - 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
>
> 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.
> > > - 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...
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.
> > 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.
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.
> > > - 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.
>
> 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.
> > > 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.
>
> 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.
> > 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 ?
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
This archive was generated by hypermail 2b28 : Fri Jul 16 2004 - 20:35:44 EEST