Hmm, let me draw that :
Mouse/keyboard ---> Gui <------> Controller <-------> Midi <--- hw
control
ler
|
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
and then day, someone says "Can we control this with OSC?" and your
second diagram becomes a curse rather than a blessing.
the people who came up with MVC were not gods, but they were
smart. MVC is the way it is for a reason, or for several reasons.
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.
portable to what? OS X ... i think not, at least not for the better
definitions of portable.
--p