Eric Dantan Rzewnicki wrote:
On Wed, Jun 29, 2005 at 01:44:18AM +0200, Olivier Guilyardi wrote:
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.
Doesn't ardour allow this type of binding midi CC's to mixer controls?
Sorry, I did not check that...
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
How does all this differ from midikinesis?
http://lac.zkm.de//2005/proceedings.shtml
Wow, that's exactly what I'm talking about... Thanks for this great pointer !
Ref :
http://www.math.tu-berlin.de/~brinkman/software/midikinesis/midikinesis.pdf
Reading this document, I remembered something I forgot to mention : binding GUI
components and midi events adds fancy knobs support to many graphical
application, audio but also drawing (the gimp ?), etc...
Now, my approach is slighty different : I'd bind GTK widgets, and let QT, FLTK,
etc.. for later. Peter did think about this, but prefered a low-level X
approach, measuring its limitations and adding workarounds.
So, to your question "How does all this differ from midikinesis?", I answer :
I'd bind the widget to the midi events, in a almost completely transparent
manner, where Peter chose to record/playback X events which I dislike.
Peter states that from a practical point of view, his Midikinesis software
solves a Linux specific problem, so that OS portability is not a key issue. To
this, I want to add that many graphical application under Linux are around with
GTK. Say half of what I personnaly use. So, to me, "Toolkit portability" is a
secondary issue...
Instead of my library idea above, the straightforward way of extending widgets
now again seems relevent to me. I'm now starting to think that a GtkHScaleMidi
widget (among a few others) could be a great addition to GTK....
Thanks again for proving LAD I'm not crazy ;-)
--
og
