[linux-audio-dev] Midi/OSC help - Continuous controllers
Olivier Guilyardi
ml at xung.org
Wed Jun 22 16:13:11 UTC 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