[linux-audio-dev] MVC - multiple CV

Alfons Adriaensen fons.adriaensen at alcatel.be
Tue Oct 4 09:31:02 UTC 2005


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






More information about the Linux-audio-dev mailing list