3 Oct
2005
3 Oct
'05
8:07 p.m.
Hi all,
working on the strict MVC-fication of Aeolus (a precondition
for its OSC-fication), I'm again confronted with a problem
that has been discussed a number of times on this list.
It has been stated that the model should send updates to
all clients except the one that originated a parameter change.
While this will work if all communication is synchronous,
it will go wrong easily when there are delays, e.g. over
a network.
Imagine an M and to CV clients, A and B. There are two
transmission paths: A -> M -> B, and B- > M -> A. If the
two ever intersect in time, the originator of the final
value used by M will end up displaying the other one.
So the only solution seems to echo parameter updates to
all clients, including the one that requested them. In that
way (and assuming messages remain in order), all clients
will have the value used by M. If messages do not remain
in order, the solution is to have a serial number set by
M on each update and included in all messages. Finally,
if the communication is unreliable as well, M should
broadcast periodic updates of its state, or at least
of those parts that have recently changed.
Of course this may create some problems, e.g. when a GUI
client's slider is being dragged, and it receives 'old'
update values while this is happening. The solution seems
to be simple: while dragging, ignore all updates but keep
the most recent one. Execute this one when the slider is
released. It may be a good idea to extend the 'ignore state'
by a small time (e.g. 0.1 s) after release.
Another approach would be have an originating client id in
each message, and some mark to indicate the final request
(upon release). Then, while dragging, ignore other clients,
and always only act on marked messages from yourself.
Anyone having any experience with this ?
--
FA
3 Oct
3 Oct
9:58 p.m.
It has been stated that the model should send updates
to
all clients except the one that originated a parameter change.
never seen that stated. i consider that the CV never considers changes
to have been carried out just because it asked. anything else is not
really MVC. maybe the change requested by CV is not possible for M at
this time.
so the real signal flow is (with time on the vertical axis, increasing
going down.
request
C(n)----------------> M
.
.
. notification
M ----------------> all V(n)
Another approach would be have an originating client
id in
each message, and some mark to indicate the final request
(upon release). Then, while dragging, ignore other clients,
and always only act on marked messages from yourself.
ardour uses this approach, but i have been phasing it out slowly in
favor of the "pure" MVC model shown above. i use a generic void*
"src" argument for changes, so that any object requesting a change
passes "itself"; when changes occur, the "src" is passed along, and
the
object that initiated can ignore "its own" changes.
but, as i said, i am trying to phase this out in favor of a model where
there are no changes to the View until the Model sends a notification.
this is not easy to do, especially not with most GUI toolkit control
widgets like faders/sliders/knobs. for them, the approach i use is:
void handle_model_state_change()
{
change_my_view_state_value (the_model_state->value);
}
void change_my_view_state_value (float newval)
{
if (my_view_state->value != newval) {
my_view_state->value = newval;
send_change_to_model (my_view_state->value);
}
}
this causes one extra "cycle" in any state change, but ensures absolute
agreement between V(C) and M. notice that C and (indirectly) M can both
use change_my_view_state() to achieve their goals.
--p
4 Oct
4 Oct
7:31 a.m.
On Mon, Oct 03, 2005 at 07:59:59PM -0400, Paul Davis wrote:
i consider that the CV never considers changes
to have been carried out just because it asked. anything else is not
really MVC. maybe the change requested by CV is not possible for M at
this time.
Good point. So this means that when M refuses a new value, it should
respond by sending the current value at least to the originator of the
request. In some cases (e.g. a slider) the C and V elements are the same
(the slider's knob), which amounts to an implicit assumption by CV that
its request will be accepted. So a slap on its hands by M is the only
way to correct such hubris.
void handle_model_state_change()
{
change_my_view_state_value (the_model_state->value);
}
void change_my_view_state_value (float newval)
{
if (my_view_state->value != newval) {
my_view_state->value = newval;
send_change_to_model (my_view_state->value);
}
}
this causes one extra "cycle" in any state change, but ensures absolute
agreement between V(C) and M. notice that C and (indirectly) M can both
use change_my_view_state() to achieve their goals.
Interesting. I'll have to go through some mental exercise to convince myself
that this will never cause infinite cycles.
Dave Robillard wrote:
After much fiddling around with ugly schemes to not
send replies to
certain clients in Om, I just echoed back /everything/ to all registered
clients, and left it up to the client to deal with it. The comm layer
is much simpler and understandable because of it.
... Generally when given the choice I'll choose complexity in the client
over complexity in the engine any day.
Thanks to both of you for your response. So at least two experienced
developers agree that updates should go to *all* clients, and that a client
can be expected to handle this gracefully. Since that was my position from
the start, I'll join the club :-)
--
FA
9 Oct
9 Oct
2:40 p.m.
[I replied to this at the time, but I think my reply ended up in the
moderation black hole for some reason I don't quite understand]
On Tuesday 04 Oct 2005 00:59, Paul Davis 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).
Dave Robillard wrote:
It has been
stated that the model should send updates to
all clients except the one that originated a parameter change.
never seen that stated. 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.
One irony is that at the time of the above discussion, it would actually
have been impossible for any DSSI host that used liblo to properly
implement the requirement because liblo had no way to commnuicate the
origin of an incoming message. We didn't notice that until a couple of
months later when we discovered the reference host didn't work right.
It's fixed now.
but, as i said, i am trying to phase this out in favor
of a model
where there are no changes to the View until the Model sends a
notification. this is not easy to do
and impossible where the view is a hardware fader, presumably -- as a
DSSI UI could be.
Chris
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. 
10 Oct
10 Oct
3:35 a.m.
On Sun, 2005-09-10 at 17:42 +0100, Chris Cannam wrote:
Dave Robillard wrote:
I don't see the plugin/host split being the same situation as the
engine/UI split at all, really.
If anything, DSSI plugins themselves have the same issue - complexity in
the plugin (engine) vs complexity in the GUI (client). DSSI just has
the convenience of skirting the issue by making hosts deal with (part
of) it. Hosts don't have it so easy. :)
I couldn't agree more that complexity belongs in the host over the
plugin though.
-DR-
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.
3 Oct
3 Oct
10:29 p.m.
On Tue, 2005-04-10 at 00:12 +0200, fons adriaensen wrote:
Hi all,
working on the strict MVC-fication of Aeolus (a precondition
for its OSC-fication), I'm again confronted with a problem
that has been discussed a number of times on this list.
It has been stated that the model should send updates to
all clients except the one that originated a parameter change.
While this will work if all communication is synchronous,
it will go wrong easily when there are delays, e.g. over
a network.
Imagine an M and to CV clients, A and B. There are two
transmission paths: A -> M -> B, and B- > M -> A. If the
two ever intersect in time, the originator of the final
value used by M will end up displaying the other one.
So the only solution seems to echo parameter updates to
all clients, including the one that requested them. In that
way (and assuming messages remain in order), all clients
will have the value used by M. If messages do not remain
in order, the solution is to have a serial number set by
M on each update and included in all messages. Finally,
if the communication is unreliable as well, M should
broadcast periodic updates of its state, or at least
of those parts that have recently changed.
After much fiddling around with ugly schemes to not send replies to
certain clients in Om, I just echoed back /everything/ to all registered
clients, and left it up to the client to deal with it. The comm layer
is much simpler and understandable because of it.
Of course this may create some problems, e.g. when a
GUI
client's slider is being dragged, and it receives 'old'
update values while this is happening. The solution seems
to be simple: while dragging, ignore all updates but keep
the most recent one. Execute this one when the slider is
released. It may be a good idea to extend the 'ignore state'
by a small time (e.g. 0.1 s) after release.
This is what I do in my gtk client. I need to do the small time delay
thing still though, as there is a problem with dragging and releasing a
slider very quickly (it jumps a bit afterwards). I'm not sure this is
the best solution, but it's worked well enough so far. Generally when
given the choice I'll choose complexity in the client over complexity in
the engine any day. YMMV.
It's not a very fun problem by any means.. I guess sending everything to
everyone is less efficient in terms of network load, but it's simpler at
least.
-DR-
7037
days inactive
7044
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Chris Cannam -
Dave Robillard -
fons adriaensen -
Paul Davis