On Fri, Jun 24, 2005 at 07:13:36PM +0200, Olivier Guilyardi wrote:
> Assumption v0.2 : a midi hardware controller is a set of input and output
> devices, and is in its nature identical to the more conventional monitor,
> keyboard and mouse.
>
> And because I like ascii diagrams, here is where this assumption drives me :
>
> +----------------+ +--------------+ +--------------+
> | input & output | <----- X ------> | GUI Toolkit | | Application |
> | devices | <---- Midi ----> | (gtk, etc..) | <---> | (MVC or not) |
> | | <-- Whatever --> | | | |
> +----------------+ +--------------+ +--------------+
When you have multiple controllers (GUI, midi, OSC, ...) and viewers (GUI,
midi, OSC, ...) trying to make the GUI toolkit the central place where
everything comes together is asking for lots of trouble, in my experience.
The correct way (IMHO) of doing this would be something like:
_______
GUI <---> IF <----> | |
MIDI <---> IF <----> | MODEL |
OSC <---> IF <----> |_______|
where the 'IF' translate between the interface presented by the model
and whatever is at the other end. You could also add 'configuration'
as a client of the model.
The MODEL is the place where everything is combined. It should be
_the only thing_ that controls you application.
When one of the 'clients' sends a command, it is evaluated in the
model and the necessary feedback is sent to the clients, to keep
their 'display' up to date.
There are two possibilities here:
1. send feedback to all clients, including the one that sent the
command,
2. send feedback to all clients except the source of the command.
What clients prefer will depend on how they are working internally,
and I usually make feedback to the source an option for each client.
-- FAReceived on Sat Jun 25 00:15:10 2005
This archive was generated by hypermail 2.1.8 : Sat Jun 25 2005 - 00:15:11 EEST