9 Oct
2005
9 Oct
'05
7:35 p.m.
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:
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
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.