8 Feb
2013
8 Feb
'13
2:48 a.m.
On Fri, Feb 08, 2013 at 07:58:02AM +1100, Patrick Shirkey wrote:
On Fri, February 8, 2013 7:01 am, Bill Gribble wrote:
tl; dr: Can't you run it with ssh -X?
Otherwise you have to write a little user interface that dispatches
the OSC commands with arguments to tickle the corresponding functions
in JAMin.
If you want a bit of a GUI you'll make up creating
a bunch of widgets for each type of control.
In other words, sounds to me like duplicating a lot of what Jamin
already does.
I'm also considering adding OSC control to Nama although I'm
a little peevish as Nama users already has a protocol for
remote control: ssh! With ssh -X I even had the Tk GUI
running remotely. I recall there is a protocol to compress X
network traffic as well.
If I do implement OSC control for Nama, it should map fairly
directly to Nama's existing command language, so the
language parser will to dispatch the command inputs I get in
the OSC format over the socket. It might be nice if
something could be made to work with a short hack. :-)
On Fri, 2013-02-08 at 06:46 +1100, Patrick
Shirkey wrote:
How does one achieve that set of steps with Linux software? Is there a
generic OSC control app for Linux that will communicate with any OSC
enabled app?
Liblo comes with "oscsend", a command line tool to send an OSC message
to a specified listener. That's good for testing. Also "oscdump", a
server that just echoes incoming OSC requests to stdout. A very useful
pair.
The way I implemented learning is to add a default handler to my created
OSC server, take the next incoming message, pick the "path" out of it,
and then add a handler for THAT in place of the default. It's possible
to get in a race if you are trying to learn with lots of OSC data flying
around but that's the user's issue :)
I think OSC was designed with the idea that the servers would define the
"name space" of paths and you would build a client map to send controls
to the proper destination. It looks more like it's really working the
other direction, where the clients/controllers define the paths they are
going to send, and the server is responsible for learning the mappings.
The reason I'm asking is for controlling jamin remotely. JAMin already has
OSC functionality after all Steve Harris wrote liblo ;-) It was
quite a nice feeling to click "Learn", wiggle a fader on my
iphone TouchOSC app, and watch the fader in my Linux app start to
move!
My problem is figuring out how to test JAMin to make
sure I haven't broken
anything with any of my recent updates. Specifically I added a "Daemon" or
"Headless" mode and I would like to check that the controls are all still
working. In addition it would be nice to be able to control the JAMin
daemon from a remote machine. So the the two issues are how to connect to
a server app and also how to do that from a remote machine.
it looks like oscsend is going to be the way to go for now.
I'm tempted to spend some time on a python/clutter generic osc controller
app but if you have already started on that it might not be necessary. I'm
also thinking of adding support for OSC send to JAMin (if it is not
already there) so it can be a remote controller for the JAMin daemon. Call
it "controller" mode...
I'll be interested to see how generic your solution is.
cheers,
Joel
--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Joel Roth