On 6/21/05, Olivier Guilyardi <ml(a)xung.org> wrote: Answered in your other thread. I think a better approach is something like Model-View-Controller, where the Model is your synth code, the View is your Gtk GUI, and the Controller is a piece of code that has (or is called by) your Gtk event handling functions and MIDI handling code. Incoming MIDI CC changes are then reflected by your SpinButtons and Sliders (by calling a function to set their values/move their sliders to the current CC value). I would guess that is how most GUI softsynths are implemented. I wouldn't want to mix Gtk and MIDI handling code, unless maybe by integrating it into the GLib main loop.

and then day, someone says "Can we control this with OSC?" and your second diagram becomes a curse rather than a blessing. the people who came up with MVC were not gods, but they were smart. MVC is the way it is for a reason, or for several reasons. portable to what? OS X ... i think not, at least not for the better definitions of portable. --p

the problem is that its also an output device, for some midi h/w. add this into the situation, and you start to realize that the midi h/w is actually a "GUI" just like the one on the screen. forcing one GUI to be mediated by another seems odd. --p

consider a box like the Mackie Control or for the cash-limited, the Behringer BCF2000. it has 8 motorized faders and/or "endless" "v-pots", plus several switches. the faders/pots come in banks to allow more flexibility. 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. 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. --p

On 6/28/05, Olivier Guilyardi &lt;ml(a)xung.org&gt; wrote: I think everyone would agree this is a Good Thing. I don't see what this has to do with anything. Never mind headless; it might be useful to run without X (hence no GUI) on older PCs. I see no reason why this couldn't be done with an MVC-like architecture: 1. Your (MVC) Controller enters "capture mode" 2. you move a slider in your GUI whichs sends a message to the MVC Controller 3. you turn a knob on your MIDI controller, which sends a message to the MVC controller 4. MVC controller binds the two But I should shut up because I've never done the above. You seem to really like this idea. Why don't you just do it and see if it works well? I have an unfounded hunch that it won't, since you usually want your GUI running in a lower priority thread.

Alfons Adriaensen wrote: Needs checking indeed... Spawning an additionnal thread may be required. The reason why I don't "just do it" is because discussing implementations ideas before coding has been of great benefit to me in the past, especially here in LAD... Why ? I can cache/compare values before asking the widget to update. Two controllers (mtk: midi toolkit) : c1 = midibind_new(); c2 = midibind_new(); That would open two input midi ports (and maybe create two threads). Then you could attach to whatever widget you like : mtk_attach_gtk_hscale (c1, gui1->hscale); mtk_attach_gtk_vscale (c2, gui1->vscale); mtk_attach_gtk_hscale (c2, gui2->hscale); ... I know what you mean. But I tend to keep my distances with such academic considerations. Thanks for your input and criticism. -- og

Alfons Adriaensen wrote: I need to investigate this question, I don't have clear ideas on the subject, currently. No complete decoder in each widget. First you create a core object which encapsulate a decoder, with midibind_new(), then you attach this object to some widgets with the midibind_attach_...() range of functions. I'm even wondering if this could not be compatible in some way with the MVC pattern. I recognize that MVC is very useful to big applications, but it's not so important for small ones IMHO. Small does not mean limited : thanks JACK, today we can think about audio applications in the UNIX tradition of connecting (piping) small apps together. This is the background to 99% of my linux audio ideas. We misunderstood. I did not mean to be cynical or the like. I posted in here to get some feedback for my ideas. I _wish_ to be criticized, in a constructive manner. That's what you did and I do thank you for this, as well as others. English is not my mother-tongue, and I may not have expressed myself correctly. Sorry if that's the case. I meant : thanks for your constructive criticism. -- og

Sorry, I meant : midibind_attach_gtk_hscale (c1, gui1->hscale); midibind_attach_gtk_vscale (c2, gui1->vscale); midibind_attach_gtk_hscale (c2, gui2->hscale); ... -- og

indeed, it does. and as other posters have noted, the method used is to have the GUI as an intermediary only for the binding: when you start the binding process, its done using a GUI (View/Controller) object, and so when the MIDI data arrives, the GUI hands off the MIDI data to the Model object represented by the GUI object. the binding is made between Model objects and MIDI, not GUI objects and MIDI, even though it is initiated at the GUI leve. subsequent MIDI data (corresponding to what was bound) is sent directly to the Model, not the GUI (View/Controller). The GUI is updated when/if the Model changes state in response to the incoming MIDI. --p

Eric Dantan Rzewnicki wrote: Sorry, I did not check that... 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

Olivier Guilyardi &lt;ml(a)xung.org&gt; writes: It at least would hurt users like me. If I already have an alternative input/output device like a MIDI controller, I do not want to have to run a GUI as well, since I actually wouldnt even see it. In my mind, the application should be the engine/model, and all views/controllers should be independent of each other. Having to go through the bloat of running GTK or something similar is just silly if what someone wants is to just send/receive MIDI data. -- CYa, Mario

On Tue, 2005-06-21 at 21:54 -0400, Paul Coccoli wrote: I use that one too, but think that the inner switch is perhaps a little too simplistic to be fully helpful, with missing velocity, aftertouch, pgmchange and so. After spending some time ploughing through header files, my adaption of the switch now looks like this: //*///////////////////////////////////////////////////*// switch (ev->type) { case SND_SEQ_EVENT_CONTROLLER: mx44_control( mx44, ev->data.control.channel, ev->data.control.param, ev->data.control.value ); break; case SND_SEQ_EVENT_PITCHBEND: mx44_pitchbend( mx44, ev->data.control.channel, ev->data.control.value, 0x3F ); // ALSA has +/- pitchbend! break; case SND_SEQ_EVENT_NOTEON: mx44_noteon( mx44, ev->data.note.channel, ev->data.note.note, ev->data.note.velocity ); break; case SND_SEQ_EVENT_NOTEOFF: mx44_noteoff( mx44, ev->data.note.channel, ev->data.note.note, ev->data.note.velocity ); break; case SND_SEQ_EVENT_PORT_SUBSCRIBED: fprintf(stderr,"Subscribed: send: %d:%d dest: %d:%d\n", ev->data.connect.sender.client, ev->data.connect.sender.port, ev->data.connect.dest.client, ev->data.connect.dest.port); break; case SND_SEQ_EVENT_PGMCHANGE: mx44_pgmchange( mx44, ev->data.control.channel, ev->data.control.value ); if(mx44->isGraphic) setwidgets(mx44->tmpPatch, ev->data.control.channel, ev->data.control.value); break; case SND_SEQ_EVENT_SENSING: // FIXME: // // This is apparently active sensing. // If we get it once and then loose it, // we should shut up! // break; case SND_SEQ_EVENT_CHANPRESS: mx44_chanpress( mx44, ev->data.control.channel, ev->data.control.value ); break; default: fprintf(stderr,"Unknown SND_SEQ_EVENT_#%d\n",ev->type); } //*///////////////////////////////////////////////////*// Perhaps Matthias could extend seqdemo.c to include these additions? mvh // Jens M Andreasen PS: The call to pitchbend() looks funny because it was written to accept the raw LSB/MSB bytes from /dev/midi. You would probably just use the single cooked value as given by ALSA. --

On Wed, 2005-06-22 at 17:18 +0200, Olivier Guilyardi wrote: You will like to have some control of the priorities for widget redraw versus midi RT response. So, a thread it is. --

Le Mercredi 22 Juin 2005 21:25, Olivier Guilyardi a écrit : hi Olivier, Doug Garmon developed this : http://home.earthlink.net/~gmoonlit/raton/raton.html maybe the code can help you... cheers julien