22 Jun
2005
22 Jun
'05
2:13 p.m.
Paul Coccoli wrote:
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.
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). 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