[linux-audio-dev] Midi/OSC help - Continuous controllers

Olivier Guilyardi ml at xung.org
Wed Jun 22 12:13:11 EDT 2005


Paul Coccoli wrote:
>>Btw, I thought gtk widgets extending SpinButtons or Sliders would be a great
>>idea. One would simply drop the widgets in, and these would be adjustable with a
>>midi continous controller, just like they are with a mouse or keyboard...
> 
> 
> I think a better approach is something like Model-View-Controller,
> where the Model is your synth code, the View is your Gtk GUI, and the
> Controller is a piece of code that has (or is called by) your Gtk
> event handling functions and MIDI handling code.  Incoming MIDI CC
> changes are then reflected by your SpinButtons and Sliders (by calling
> a function to set their values/move their sliders to the current CC
> value).

Hmm, let me draw that :

    Mouse/keyboard ---> Gui <------> Controller <-------> Midi <--- hw controller
                                         |
                                       Model


I've been using the MVC design in some other project, and maintaining it over 
several years, I realized that it forces me to take some redundant/long paths 
everytime I make a change, exactly like the following : the controller has to 
update the gui when it receives some event from the midi layer.

It's a good thing to separate layers, but what about considering the hw 
controller like another input device, just like the mouse or keyboard ?

See:  Mouse/keyboard/hw controller ----> Gui <----> Engine

I recognize that sticking the midi layer into gtk would forbid to run the app 
headless (you can still switch your monitor off ;-), or do some other ui, with 
curses, etc... But sometime, one prefer to go straight to the point, and anyway 
gtk is portable.

> I would guess that is how most GUI softsynths are implemented.  I
> wouldn't want to mix Gtk and MIDI handling code, unless maybe by
> integrating it into the GLib main loop.

There is a bottleneck : the controller assignement. What knob does what ?

Imagine a widget which extends the GtkHScale slider, say GtkHScaleMidi. In 
addition to transparently receive midi events, it would also encapsulate a 
capture-style configuration feature.

You hold the Ctrl key down, you move your mouse on the GtkHScaleMidi, then you 
move a knob on the controller. That's it : the knob starts talking to the gtk 
slider, and if you're rich and own a big Mackie thing, the gtk slider could even 
move motorized knobs.

1 - But the magic is : you just don't know that all of this happened. It's 
encapsulated in the widget.

2 - this widget could fire some "assigned" gtk event, when a given widget gets 
assigned to a given knob, for example to ask the user what range the knob should 
operate on.

3 - you already have a working app ? Just put GtkHScaleMidi in place of 
GtkHScale ... Later you can code something to remember the assignments, by 
calling the provided gtk_hscale_midi_get_assignment().

--
   og


More information about the linux-audio-dev mailing list