[linux-audio-dev] Midi/OSC help - Continuous controllers

[Olivier Guilyardi]

Hi Paul,

Paul Davis wrote:
>>  +----------------+                  +--------------+       +--------------+
>>  | input & output | <----- X ------> | GUI Toolkit  |       | Application  |
>>  |    devices     | <---- Midi ----> | (gtk, etc..) | <---> | (MVC or not) |
>>  |                | <-- Whatever --> |              |       |              |
>>  +----------------+                  +--------------+       +--------------+
>>
> 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.

My diagram was not clear enough. I did not mean that gtk should talk to the midi 
h/w in the same way it talks to the screen. The refresh rate you're talking 
about is one among many things in which a midi h/w device differ from a 
screen/keyboard set.

The thing is just that by coupling the midi input and the ui toolkit layer, one 
can take an interesting shortcut. More below.

> 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.

I agree, it' clean. Now, let me describe what I saw the last couple of days :

1 - a friend of mine showed me his brand new evolution uc33 midi controller. 
He's using that with a windows-based software called "Live". I was really 
suprised to see that this software use exactly what I proposed in this thread. 
First you enter a "capture-mode", you click on some GUI widget, then you rotate 
some knob, that's it : it's assigned. I promise I never saw a such thing when I 
had exactly the same idea.

2 - Tonight, I went to a concert of a jazz drummer, a friend of mine. He was 
using a macintosh coupled with a midi h/w controller. He spent more time playing 
with this computer than with his drumset, but nevermind... My point is : he was 
using both the midi controller, and the screen/keyboard/mouse set, just as my 
other friend above.

Now, here's what I consider to be a very practical consideration : there are 
many GUI enabled apps, which can't run headless. A usual way of using a midi h/w 
controller is as a add-on, not as a replacement for the screen. I'd personally 
like to use a such midi h/w as a standalone device, on stage, but nothing will 
forbid me to unplug the screen in this case...

By "midi-enabling" some toolkit widgets, _many_existing_ apps would suddenly 
become compatible with these dedicated controller hardware devices. I do agree 
you that the best would be for these apps to add some midi input support, as a 
separated "View".

But on the other side, what about the "capture-style" way of assigning knobs to 
widgets ? Don't you see how this is efficient ? In 1 second, what you touch on 
the controller is connected with what you see on your screen (WYTIWYS ;-). 
Still, of course, in this case you may say that these are two separated layers 
that artificially appear to be one... But what about a shortcut to couple these 
two layers, if they are to get so tight ?

I believe there could exist a library with which :
1 - you instantiate a core object (providing the alsa midi port as an arg)
2 - you "attach" to some widgets : sliders, spin buttons, etc.. (note that this 
is different from extending (bloating) widgets)
3 - you may call a function to enter the capture-mode
4 - 100 % of this capture-mode is encapsulated by the library : knobs-to-widgets 
assignations are handled transparently
5 - there is some way to retrieve these assignations to recall them later

--
   og