1 Jun
2010
1 Jun
'10
2:27 p.m.
Hi everyone,
a Jackbeat user is currently trying to use TouchOSC, an iPhone app, as a
controller, and there is a need to translate in/out OSC messages.
I have looked at TouchOSC messages, and the translation is nothing like
straightforward. There is a so-called BeatMachine[1] controller in TouchOSC,
which looks like a drum machine, but in the messages that it sends:
1. the track order is reversed, the first track being at the bootom
2. the indexes are one-based in TouchOSC, and zero-based in Jackbeat
3. the track/beat position is transmitted as a path element instead of a value
The fact that some translation is needed between OSC units is quite normal to
me, but I would like to try and follow some wide-spread practices, if any, maybe
refactoring the Jackbeat OSC dialect, to make such translation easier.
I originally looked at some Monome messages docs[2], and that's the reason for
2. and 3. above. The point 1. seems absolutely odd to me however.
Now, there's another thing: currently Jackbeat features quite a few OSC
methods/commands but little OSC events[3]. This forbids using search an external
controller as some kind of UI replacement. For instance, volume sliders can be
controlled, but no event is sent when they change. One of the reason for this
lack is that I was unsure about the right protocol to choose..
So, in TouchOSC, input and output messages seem to always be symmetrical, which
looks like a clever and intuitive design to me. For instance, a slider both
sends and receives messages at /1/fader1 (example). And you just can't setup a
different prefix for in and out.
Once again, this isn't the way Monome is doing it: it sends /40h/press, and
receives at /40h/led.
So I'm a bit confused. What would be ideal is to follow some kind of practices
and/or standard, so that, in many cases, translation is only a matter of
changing OSC prefixes. And if that's not realistic, then I would like to avoid
some of the inconsistencies listed above with tools as TouchOSC and such.
Is there any such standard or common/recommended practices?
Cheers,
[1] http://hexler.net/pub/touchosc/touchosc-manual-v1-1.pdf
[2] http://docs.monome.org/doku.php?id=tech:protocol:osc
[3] http://jackbeat.samalyse.org/wiki/BasicUsage#OSCInterface
--
Olivier
1 Jun
1 Jun
8:51 p.m.
Ill just say my 2 cents regarding point number 1:
1. the track order is reversed, the first track being at the bootom
It seems that's the way with most physical controllers too, I've got an Akai
LPD8,
and "bottom-left" counts from pad 1, upwards. See the following image of an
Akai 16 pad:
http://www.jmsinfo.com/images/Akai_MPD18_MIDI_USB_Drumpad.jpg
I'm not sure how your program works internally as to what the best solution
is to
solving this problem.
In my WIP project* *I've used LibLO for OSC, and create a function in my
Sampler class which
takes an *int* parameter as for which pad to play. This seems a pretty clean
solution to me,
however as I say, I havent looked at your sources as to what's the best
implementation.
HTH, -Harry
10:01 p.m.
On 06/01/2010 08:51 PM, Harry Van Haaren wrote:
Ill just say my 2 cents regarding point number 1:
1. the track order is reversed, the first track being at the bootom
It seems that's the way with most physical controllers too, I've got an
Akai LPD8,
and "bottom-left" counts from pad 1, upwards. See the following image of
an Akai 16 pad:
http://www.jmsinfo.com/images/Akai_MPD18_MIDI_USB_Drumpad.jpg
Okay, thanks for this info.
I'm not sure how your program works internally as to what the best
solution is to
solving this problem.
In my WIP project/ /I've used LibLO for OSC, and create a function in my
Sampler class which
takes an *int* parameter as for which pad to play. This seems a pretty
clean solution to me,
however as I say, I havent looked at your sources as to what's the best
implementation.
Really, my question isn't about the implementation. I am asking about OSC
protocol best design practices, in general. This is not Jackbeat specific at all
to me.
What about the in/out symmetry that I mentioned? Should the track position go
into the path or be passed as a value? Should indexes be zero-based? Etc..
To be honest, I am very confused about the idea that OSC is some kind of MIDI
successor. The MIDI protocol is a rather defined, with notes, CC, etc..
Whereas OSC just looks like a generic RPC mechanism, thus requiring some
development knowledge or custom-made tools.
--
Olivier
10:35 p.m.
To be honest, Ill agree with you there that the OSC details seem a little
more vague (or "expandable"... whatever we call it).
I found looking at what Ardour done to handle its OSC stuff useful, but im
not sure that's the "PC" way to do it... Ardour guys..?
On the other hand, because its so much more understandable to use, I could
set up my own OSC message translator
in minutes, while if I was trying to suss out MIDI CC's & Program changes,
Id be pulling hair out of my head. That may be
specific to me though, I'm don't have that much experience with Hardware
MIDI stuff.
In Response to Olivier's:
To be honest, I am very confused about the idea that
OSC is some kind of
MIDI
successor. The MIDI protocol is a rather defined, with notes, CC, etc..
2 Jun
2 Jun
12:51 a.m.
On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi <list(a)samalyse.com> wrote:
Whereas OSC just looks like a generic RPC mechanism,
thus requiring some
development knowledge or custom-made tools.
this is exactly correct.
there is no established way to send an OSC message to an arbitrary
receiver and reliably accomplish anything at all. there is no standard
message set to ask the receiver to play a note, stop playing a note.
ditto for transport control, and just about everything else you could
imagine. in short there are no standards.
the only thing that does exist is a "meta-standard" to query the OSC
namespace, and arguably another meta-standard to get the current value
of any readable target within the namespace.
as you have surmized, in its current state OSC cannot possibly be
considered as a replacement for MIDI as a generic communication
protocol for musical-related tasks. what it does to is to provide a
common transport mechanism and a standard namespace convention (the
lowly '/'), and the agreement to use text messages which makes adding
certain capabilities to a pair of receivers and transmitters just a
bit simpler than it otherwise would be.
--p
1:04 p.m.
On 06/02/2010 12:51 AM, Paul Davis wrote:
On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
This relates to I was just thinking about before reading your mail. I was
telling myself that OSC is a bit like XML, which is a meta-language, thus a
specification that allows to write languages. For example, RSS can be considered
a such language.
Whereas OSC just looks like a generic RPC
mechanism, thus requiring some
development knowledge or custom-made tools.
this is exactly correct.
there is no established way to send an OSC message to an arbitrary
receiver and reliably accomplish anything at all. there is no standard
message set to ask the receiver to play a note, stop playing a note.
ditto for transport control, and just about everything else you could
imagine. in short there are no standards.
the only thing that does exist is a "meta-standard" to query the OSC
namespace, and arguably another meta-standard to get the current value
of any readable target within the namespace. as you have surmized, in its current state OSC cannot
possibly be
considered as a replacement for MIDI as a generic communication
protocol for musical-related tasks. what it does to is to provide a
common transport mechanism and a standard namespace convention (the
lowly '/'), and the agreement to use text messages which makes adding
certain capabilities to a pair of receivers and transmitters just a
bit simpler than it otherwise would be.
Well, maybe that it's not OSC that must evolve, just as XML is fine where it
stands. But there could be a higher-level specification, (as RSS in my example),
which programs and devices could choose to follow.
I'm thinking about some quite open standard. Not something which is very strict,
but certain rules, or better said recommendations, which try to bring some
coherence into the OSC (audio) world. Some very simple primitives could be:
1. in/out symmetry, eg: send and receive from/to /path/volume %f
2. put "coordinates", such as track index in the path, not as a value
3. always use zero (or one, whatever) based indexes
4. maybe some range specification for level controls
5. some recommendation for encoding notes
6. etc...
Anyway, before a such specification/standard exists, I suppose I have to look
around, and draw my own conclusions..
Therefore, it's currently a matter of "practices".. So, if anyone who has a
good
knowledge of these can shred some light on the specific issues that I mention,
I'll be glad to read about it.
--
Olivier
1 Jun
1 Jun
9:55 p.m.
It's interesting that you mention the Monome. There has been
discussion about how the OSC stuff is structured and there are a few
efforts to improve it. I went and dug up this thread:
http://www.vidvox.net/phpBB2/viewtopic.php?p=14786 . It talks about
how the Monome protocol is a bit non-standard and may provide a few of
the "best practices" that you're looking for.
-w
On Tue, Jun 1, 2010 at 5:27 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
Hi everyone,
a Jackbeat user is currently trying to use TouchOSC, an iPhone app, as a
controller, and there is a need to translate in/out OSC messages.
I have looked at TouchOSC messages, and the translation is nothing like
straightforward. There is a so-called BeatMachine[1] controller in TouchOSC,
which looks like a drum machine, but in the messages that it sends:
1. the track order is reversed, the first track being at the bootom
2. the indexes are one-based in TouchOSC, and zero-based in Jackbeat
3. the track/beat position is transmitted as a path element instead of a value
The fact that some translation is needed between OSC units is quite normal to
me, but I would like to try and follow some wide-spread practices, if any, maybe
refactoring the Jackbeat OSC dialect, to make such translation easier.
I originally looked at some Monome messages docs[2], and that's the reason for
2. and 3. above. The point 1. seems absolutely odd to me however.
Now, there's another thing: currently Jackbeat features quite a few OSC
methods/commands but little OSC events[3]. This forbids using search an external
controller as some kind of UI replacement. For instance, volume sliders can be
controlled, but no event is sent when they change. One of the reason for this
lack is that I was unsure about the right protocol to choose..
So, in TouchOSC, input and output messages seem to always be symmetrical, which
looks like a clever and intuitive design to me. For instance, a slider both
sends and receives messages at /1/fader1 (example). And you just can't setup a
different prefix for in and out.
Once again, this isn't the way Monome is doing it: it sends /40h/press, and
receives at /40h/led.
So I'm a bit confused. What would be ideal is to follow some kind of practices
and/or standard, so that, in many cases, translation is only a matter of
changing OSC prefixes. And if that's not realistic, then I would like to avoid
some of the inconsistencies listed above with tools as TouchOSC and such.
Is there any such standard or common/recommended practices?
Cheers,
[1] http://hexler.net/pub/touchosc/touchosc-manual-v1-1.pdf
[2] http://docs.monome.org/doku.php?id=tech:protocol:osc
[3] http://jackbeat.samalyse.org/wiki/BasicUsage#OSCInterface
--
Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
10:43 p.m.
On 06/01/2010 09:55 PM, Will Light wrote:
It's interesting that you mention the Monome.
There has been
discussion about how the OSC stuff is structured and there are a few
efforts to improve it. I went and dug up this thread:
http://www.vidvox.net/phpBB2/viewtopic.php?p=14786 . It talks about
how the Monome protocol is a bit non-standard and may provide a few of
the "best practices" that you're looking for.
Thanks for this link. Indeed they seem to think about encoding the grid position
into the path.
dlublin says:
"Right now the monome sends a list of arbitrary data to "/128/press" to
describe
a button at a physical location and its state.
However, it would make a lot more sense if instead it would simply send a single
value to "/128/press/x/y/", where the col and row information are encoded
directly into a unique address path- this second method would work with even the
most primitive implementation for receiving OSC values, without any need for an
API."
That makes sense to me.
Nevertheless, they seem to be missing the in/out symmetry idea, which I find
very interesting.
--
Olivier
5419
days inactive
5420
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Harry Van Haaren -
Olivier Guilyardi -
Paul Davis -
Will Light