Jens M Andreasen wrote: Thanks, you answered my main question. Is there any piece of code I could reuse out there, for such continuous midi controllers support ? Any clean code, whatever app it comes from, would be helpful. Btw, I thought gtk widgets extending SpinButtons or Sliders would be a great idea. One would simply drop the widgets in, and these would be adjustable with a midi continous controller, just like they are with a mouse or keyboard... -- og

Paul Coccoli wrote: Hmm, let me draw that : Mouse/keyboard ---> Gui <------> Controller <-------> Midi <--- hw controller | Model I've been using the MVC design in some other project, and maintaining it over several years, I realized that it forces me to take some redundant/long paths everytime I make a change, exactly like the following : the controller has to update the gui when it receives some event from the midi layer. It's a good thing to separate layers, but what about considering the hw controller like another input device, just like the mouse or keyboard ? See: Mouse/keyboard/hw controller ----> Gui <----> Engine I recognize that sticking the midi layer into gtk would forbid to run the app headless (you can still switch your monitor off ;-), or do some other ui, with curses, etc... But sometime, one prefer to go straight to the point, and anyway gtk is portable. There is a bottleneck : the controller assignement. What knob does what ? Imagine a widget which extends the GtkHScale slider, say GtkHScaleMidi. In addition to transparently receive midi events, it would also encapsulate a capture-style configuration feature. You hold the Ctrl key down, you move your mouse on the GtkHScaleMidi, then you move a knob on the controller. That's it : the knob starts talking to the gtk slider, and if you're rich and own a big Mackie thing, the gtk slider could even move motorized knobs. 1 - But the magic is : you just don't know that all of this happened. It's encapsulated in the widget. 2 - this widget could fire some "assigned" gtk event, when a given widget gets assigned to a given knob, for example to ask the user what range the knob should operate on. 3 - you already have a working app ? Just put GtkHScaleMidi in place of GtkHScale ... Later you can code something to remember the assignments, by calling the provided gtk_hscale_midi_get_assignment(). -- og

Hi Paul, Paul Davis wrote: I proposed an idea, Paul Coccoli discussed it, so I developed.. But I must confess I like to consider a hardware midi controller as a standalone UI, rather than plug it into the GUI. Actually, I just started from the following assumption : a midi hardware controller is a input device, among keyboard, mouse and others. The idea would be to "abstract" this input device from the developer point of view, just as the keyboard and mouse. I developed this idea into one direction, which may be wrong, but I still believe my assumption to be right. That was not my main point. Sorry if I wrote an error here. I just know that GTK runs on windows and OSX. I don't know the limitations of this portability. -- og

Paul Davis wrote: Okay, let me try to improve this... 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 --> | | | | +----------------+ +--------------+ +--------------+ 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. This is all theoritical, but can it be considered false ? -- og

Hi Paul, Paul Davis wrote: 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. 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

On Wed, Jun 29, 2005 at 10:46:55AM -0400, Paul Coccoli wrote: Yes, and you'd force the widgets to update for each message sent by a knob, even if there are 1000 such messages per second, which is absurd and could easily freeze the entire application. It's also not a general model. What if you want to link to GUIs, or two HW controllers ? The association should be done in the 'server' part of the model, i.e. that part which provides the interface to all controllers and viewers. In the MVC structure, a GUI is just a controller/viewer as any other. It does not play any central role. -- FA

On Thu, Jun 30, 2005 at 12:20:06PM +0200, Olivier Guilyardi wrote: Ok, we'll have multi-threaded widgets. How ? If you require say a minimum delta in order to update, it may never be reached unless it's so small that you will update for every event anyway. Some form of timeout will be necessary. Now we have multi-threaded widgets that are also aware of time. Will you want to create separate threads and timer events for each widget ? A complete MIDI decoder in each one ? Probably not, so there needs to be some centralised control. The original idea of making this transparent is far away at that point. I mean you have an app driven by a controller (no GUI), and you want to link in a second one. Your approach requires there is a GUI in the first place, and that defeats the purpose of having an external controller, for some people at least. I've tried this sort of thing on two separate occasions, only to find out that I had been wasting my time. That's academic, for some value of that word. It's not criticism, but since you take it as such, I'll stop here. Good luck ! -- FA

On Thu, Jun 30, 2005 at 02:57:51PM +0200, Olivier Guilyardi wrote: That's exactly the idea I want to warn you for. One of the cases where I tried to make the GUI the 'center of control' and ended up with a complete mess was for Aeolus. In terms of MIDI control this is probably much simpler than what you want to do for JackBeat. Simplicity can be misleading. You need virtually nothing to get race conditions where for example the values shown in the GUI, the controller, and the actual one used by the audio code get out of sync. Another problem I found is that when you deviate from the strict MVC model, you're likely to duplicate logic, and end up with parallel state machines. I don't wish that to my worst enemies. No harm done :-) -- FA

On Wed, Jun 29, 2005 at 01:44:18AM +0200, Olivier Guilyardi wrote: Doesn't ardour allow this type of binding midi CC's to mixer controls? How does all this differ from midikinesis? http://lac.zkm.de//2005/proceedings.shtml -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network(a)rfa.org.

Paul Davis wrote: Sorry, I should have checked Ardour. But anyway I see that you really now what you're talking about, since you've already implemented it using MVC. On the other side Peter Brinkmann seems to be your opponent of choice in regard to this topic, since he made Midikinesis (and presented it at LAC) : http://www.math.tu-berlin.de/~brinkman/software/midikinesis As I said in my previous mail, one of the great argument in favor of midi-enabled widgets is that it allows to use h/w controller with both audio and non-audio applications. But this is getting slightly out of topic. Thanks for discussing my ideas and for your constructive criticism. -- og

On Fri, Jun 24, 2005 at 07:13:36PM +0200, Olivier Guilyardi wrote: 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. -- FA

Jens M Andreasen wrote: Thanks to both of you ! I think I'm gonna set up some capture-style configuration, like : - you click on Tools/Midi capture - you move your mouse over some widget (a given track's pitch, for ex) - you move a knob on your hardware controller - the knob is assigned to the given widget I think I'll listen for different kind of events, of course SND_SEQ_EVENT_CONTROLLER, but also PITCHBEND, NOTEON, NOTEOFF, so that one can even change settings with a midi drumset or keyboard. Do you think it's ok if I listen to midi events in glib's main loop ? For example with g_timeout_add() ? Better spawn a thread ? -- og

Jens M Andreasen wrote: Thanks -- og

Salut Julien, julien2 wrote: That's a nice tool ! Although this is more about sending events than receiving them, I'll try and take a look at the code. Thanks -- og