Re: [linux-audio-dev] DSSI (Disposable Soft Synth Interface) 0.4

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] DSSI (Disposable Soft Synth Interface) 0.4
From: Alfons Adriaensen (fons.adriaensen_AT_alcatel.be)
Date: Fri Jul 16 2004 - 18:21:15 EEST


On Fri, Jul 16, 2004 at 02:18:16PM +0100, Steve Harris 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.

This is certainly true for things like a slider. But there are a simple
solutions:

- changes are sent to all V, with an identifier of the C that requested
  them. So a UI can ignore the echos to its own commands if it wants, OR
 
- For e.g. a slider that is being dragged, the UI can ignore all echoed
  values while the drag lasts (but keep the most recent to use when the
  drag ends).
  

> > - 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.

> > - 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.

It *does*, if messages are kept in order. This may suggest that UDP is not
the best choice.
  

> > 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 ?

> 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 ?

-- 
FA


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jul 16 2004 - 18:33:25 EEST