24 Jun
2005
24 Jun
'05
4 p.m.
+----------------+ +--------------+
+--------------+
| input & output | <----- X ------> | GUI Toolkit | | Application |
| devices | <---- Midi ----> | (gtk, etc..) | <---> | (MVC or not)
|
| | <-- Whatever --> | | | |
+----------------+ +--------------+ +--------------+
About configuration : there are tools to map keys to letters for a keyboard, so
there could be tools to map knobs to controllers in case of a midi box.
consider a box like the Mackie Control or for the cash-limited, the
Behringer BCF2000. it has 8 motorized faders and/or "endless"
"v-pots",
plus several switches. the faders/pots come in banks to allow more
flexibility.
the model you've given above is just unwieldy for this. the update
frequency required to get smooth fader motion (part of the "GUI" of the
MIDI h/w) is very different than is required for the screen GUI.
it should look like this:
+------------+ +----------+
| Screen GUI |<----------->| "bridge" |<--------+
+------------+ +----------+ |
+<-----> MODEL
+------------+ +----------+ |
| MIDI (G)UI |<----------->| "bridge" |<--------+
+------------+ +----------+
the "bridge" component is just some s/w that converts between whatever
the communication mechanisms are for the model/software and software/UI
links. for the screen GUI, its something written using some kind of GUI
toolkit; for the MIDI system its something that understands how to talk
MIDI as well as the specific control surface protocol.
this keeps the code nice and clean, allows you to add new
controllers/views without modifying the existing controllers/views, and
seems to me to be a no-brainer.
--p