Re: [linux-audio-dev] MVC - multiple CV

On Sun, Oct 09, 2005 at 05:42:08PM +0100, Chris Cannam wrote:

> DSSI explicitly requires this behaviour for the host sending updates to
> plugin UIs. That requirement was the subject of some discussion at the
> time (see http://lalists.stanford.edu/lad/2004/07/0263.html in which
> Fons takes the same side of the debate as at present and Steve Harris
> argues for the other side).

I remember that discussion, and indeed I still think the same.
The solution I adopted for Aeolus is like this:

- Each command (C->M) is tagged by an ID from the the originator,
  and this is copied in all resulting messages from M to all V.

- A controllor can use two IDs, one for 'transient' parameter values
  (e.g. a slider being dragged), and one for 'final' ones (the slider
  being released). It can then just ignore transient updates from
  itself. The logic required is trivially simple, and it solves all
  problems.

> Dave Robillard wrote:
> > Generally when
> > given the choice I'll choose complexity in the client over complexity
> > in the engine any day.
>
> This is exactly the opposite of what DSSI aims for. The principle
> (which may or may not be correct) is that the host only has to be
> written once, and a bit of pain in the implementation won't prevent
> people from doing it, whereas the plugin UIs have to be written many
> times by lots of people and should therefore be made simpler at the
> cost of extra complexity in the host.
>
> FWIW I think the arguments on both sides have quite a bit of merit.

The 'extra complexity' in the plugins consists of a simple check on
one value. It could easily be built into a development toolkit and
and plugin writers wouldn't even have to see it.

More generally, the decision of where and how some functionality should
be implemented must IMHO be guided by a *logical* analysis of the problem
at hand, and not by political reasons such as 'it must be as easy as
possible for the masses'. The latter, in my experience, just leads to
problems and dirty-hack solutions later, when things need to be scaled
up or generalised.

-- 
FA