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

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