On 26 Jul 2007, at 15:24, Patrick Shirkey wrote: Yes, you can attach a callback to the GtkAdjustment that gets called when the user moves the slider, to end out OSC messages (if you want to do that). If you use liblo (counterplug http://liblo.sourceforge.net/) then you can attach callbacks to OSC paths and use the callback to set a new value on the appropriate Adjustment. I think someone even made a helper library over liblo and GTK that lets you directly bind OSC paths to GTK Adjustments. - Steve

On 26 Jul 2007, at 16:10, Patrick Shirkey wrote: Well, that's what jamin does. You need to be a server to receive commands, but you can be both. http://liblo.sourceforge.net/examples/example_server.c shows how to create a server that listens of a couple of the methods. - Steve

You can use something like generic_handler(), but it will match _any_ incoming message. The idea of LibLo is to create a callback for each message you want to handle. It will do the job of differentiating which callback gets called depending on the OSC address, and will also handle wildcard addressing for you. (I.e., all matching callbacks will get called.) Associate each fader with a callback, or alternatively create a generic_handler() type callback and use the "path" variable to differentiate. You could, for example, write a single callback, but associate multiple messages to the same callback. In the callback, use "path" to figure out which fader has been specified. It depends how dynamic your program is. If the number of faders is hard-coded, it may be simpler to have a callback for each one. Which port number you use is up to you. I suggest making it user-configurable. Keep in mind that OSC says _nothing_ about the underlying protocol used to carry it. That UDP ports are often used is only defacto convention. You could equally use TCP or anything else. However, supporting UDP ports is useful since that's what most other programs use. Don't know of one. Jack is of course a separate thing from OSC. I would think that needing to reserve specific ports for specific applications would be counter-productive. Like telling musicians what MIDI channels they should put their devices on. It's better to let them configure it. Hope this helps, Steve

Hi, Am Donnerstag, 26. Juli 2007 schrieb Stephen Sinclair: Do you mean "fader <index> <value>" or "/fader <some_blob> <value>". Both would work for separating gui/core but the second one makes it impossible to use other osc-apps (like pd/etc.)... Oh, another thing. If you use Qt4 for the Gui/Toolkit, there is ofqf (OSC for Qt4, http://www.arnoldarts.de/drupal/?q=node/573) which encapsulates osc over udp in QObjects without external libraries (except for libofqf:). Have a nice day, Arnold -- visit http://www.arnoldarts.de/ --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your administrator to do so...

On 7/27/07, Patrick Shirkey &lt;pshirkey(a)boosthardware.com&gt; wrote: Yay for plugs... ;) We have recently added a widget to phat for just this case. PhatRange. You can hook it up to monitor a variable or update it with osc. Plus the new fan sliders are damn sexy x composite things ;P. Loki

On Sat, Jul 28, 2007 at 11:24:36AM +1000, Loki Davison wrote: huh ? do you mean the PhatAdjustment ? -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

Patrick Shirkey wrote: osc specifies nothing here. on a bi-directional connection, the client can of course receive messages (here: osc-commands) from the server. however, osc is usually transmitted unidirectional over udp. so your application has to run a server. a client would be of little use mfga.sdr IOhannes