Touch OSC -Strings in OSC messages

[micpool]

So this week I am getting to grips with Touch OSC and LEMUR controllers with Qlab

Does anyone know how to include strings in OSC Addresses from Touch OSC

for instance

a Qlab OSC cue with the following OSC message

/workspace/*/new "video"

creates a new video cue

but putting that on a button in Touch OSC doesn't work

I know the OSC link is functioning and the syntax is almost correct because a button with

/workspace/*/playbackPosition/next

works, although it is sending the address twice once when the button is depressed and once on release (any ideas on this welcome as well)

The great thing about LEMUR is the sync between the editor on the mac and the app on the iPad is continuous, so whatever you do in the editor appears straight away on the iPad without having to do the Touch OSC clunky sync nonsense every time. And you can define which changes in a control value will cause a message  to be sent

However,  LEMUR won't even accept the 

/workspace/*/new "video" syntax

it just deletes everything after new.

(it will send single commands on key presses though,  by only sending the message when the button value goes from 0 to positive.(one of 5 selectable options)

Thanks

Mic

[nizer]

I use toggles buttons instead of push buttons to prevent the double address issue.

[Drew Schmidt]

I like to use OSCulator to bridge this gap. It allows you to re-write an address, part of that being the ability to type-cast a variable. So you can pull in arg[0], drop down the argument menu, and select "as string" to ensure that what you sent was a string. This is also a nice way to monitor the incoming addresses. I haven't tried this, but OSCulator has a free trial so you could just test it out. And it's pretty cheap to buy.

OSCulator is also the other way (aside from toggle buttons instead of push buttons) to prevent the double tap. You can specify that an address is only sent if the number is increasing (0 -> 1 is a press down, 1 -> 0 is a release) rather than every single event.

[micpool]

Thanks for your replies.

I have to say all this is very disappointing in the context of the claims made for OSC as a universal solution. Is the format just too open? Does it only really work if you are in control of the implementation of the control surface software and the application it controls?

It seems a bit crazy that  APIs can require strings,  but the most popular control surfaces can't send them.

The fact that a lot of control surface software doesn't differentiate between a button down and button up, but sends the message on every state change seems to be a rerun of the MIDI note off/Midi Note on Vel 0 confusion. At least LEMUR does allow this to be sorted by filtering the state changes.

Mic

[Chris Ashworth]

 Is the format just too open?

Personally, I’d say there’s a pretty decent argument to be made that this is true.

Of course, we can work to improve the flexibility of our API, and its ability to talk to other programs. But there’s something nice about the constraints and simplicity of MIDI, ain’t there?

-C

[sam kusnetz]

I think a big issue here is that TouchOSC assumes you want to send a numerical value for every key press. I believe that's a design flaw in the program, based on the assumption that you're using it just like you would use a MIDI note on/note off situation.

I'm not at my computer now, but it's possible that you can set TouchOSC to send "0" on both press and release, and that can help in some situations.

When using OSC in situations where the host application makes no assumptions (eg. Max/MSP, or Python, or some other programming situation) this sort of problem doesn't exist.

Best
Sam

--
Sam Kusnetz
Figure 53 Field Operative
(mobile)

[Andy Lang]

On Tue, Feb 17, 2015 at 10:53 AM, micpool <m...@micpool.com> wrote:
> The fact that a lot of control surface software doesn't differentiate
> between a button down and button up, but sends the message on every state
> change seems to be a rerun of the MIDI note off/Midi Note on Vel 0
> confusion. At least LEMUR does allow this to be sorted by filtering the
> state changes.

That's actually not quite what's happening. The address is being sent
for every press/release, with a different argument, 0 for release and
1 for press, as a general default.

But, on QLab's end, QLab is using the address without an argument to
trigger a command. So it's just ignoring the argument altogether.
Since it only cares about the address, it sees both messages as the
same. An argument-less message is within the specifications for OSC,
so it's most arguably a flaw that Touch OSC doesn't allow an address
to be sent without an argument, as well as only on the press.

Hope that clarifies, rather than further muddying the waters!

-Andy

[micpool]

So, I have got OSC packet sniffing happening with wireshark and I have managed to get LEMUR to output what looks like a perfectly valid message containing a string in double quotation marks with this:

decl theoutstring='/new '+arraytostring({34})+'video'+arraytostring({34});

oscout (1,theoutstring,1);

But it still doesn't do anything.

If I capture the OSC string in Qlab and cut and paste it into an OSC cue as a custom message it works fine.

Other OSC stuff that doesn't contain quotation marks, like /load and /go work, it just seems to be the stuff that needs strings that's problematic

I have attached a text file of the packets from wireshark and marked the OSC that works and the packets that don't

Any ideas?

Mic

PS Although quite complicated compared to Touch  OSC, LEMUR seems to have the potential to provide solutions for a lot of remote control requirements over OSC and MIDI as it has its own C like  script language. It's main advantage is the mac  editor runs in sync with the iPad app so as soon as you program something or add a module to the editor, it's immediately available for use on the iPad. 

And it has an HTML5 based canvas object so you can include animations and all sort of mad stuff on your remote, (although I suspect it will take a little while longer before  I attempt anything like the stuff in this article)

http://createdigitalmusic.com/2014/03/let-ipad-look-like-anything-sequence-anything-lemur-5/

[Chris Ashworth]

Hi Mic,

I think I pressed send in replying to your email to support at the same moment you pressed send on your to the list, but to repeat it here:

The quotation marks themselves are not expected in the OSC messages. We use a custom human-readable translation of an OSC message in our GUI, which uses quotation marks to force the contents to be a string OSC argument, so when you paste those commands into QLab it is translating them into an OSC message that doesn’t contain the quotes.

-C

On February 19, 2015 at 9:45:19 AM, micpool (m...@micpool.com) wrote:

So, I have got OSC packet sniffing happening with wireshark and I have managed to get LEMUR to output what looks like a perfectly valid message containing a string in double quotation marks with this:

decl theoutstring='/new '+arraytostring({34})+'video'+arraytostring({34});

oscout (1,theoutstring,1);

But it still doesn't do anything.

If I capture the OSC string in Qlab and cut and paste it into an OSC cue as a custom message it works fine.

Other OSC stuff that doesn't contain quotation marks, like /load and /go work, it just seems to be the stuff that needs strings that's problematic

I have attached a text file of the packets from wireshark and marked the OSC that works and the packets that don't

Any ideas?

Mic

PS Although quite complicated compared to Touch  OSC, LEMUR seems to have the potential to provide solutions for a lot of remote control requirements over OSC and MIDI as it has its own C like  script language. It's main advantage is the mac  editor runs in sync with the iPad app so as soon as you program something or add a module to the editor, it's immediately available for use on the iPad. 

And it has an HTML5 based canvas object so you can include animations and all sort of mad stuff on your remote, (although I suspect it will take a little while longer before  I attempt anything like the stuff in this article)

http://createdigitalmusic.com/2014/03/let-ipad-look-like-anything-sequence-anything-lemur-5/

[micpool]

Thanks Chris

You are right. The quotation marks were the source of my confusion.

I now know that in any application any quotation marks (either single or double, depending on the app) in the text representations are purely for the use of the app in determining how to format the actual OSC datagram. In the case of Qlab the quote marks around a string in an OSC message are just to  tell Qlab that this is a string argument and that Qlab should format the OSC output to indicate this. The quote marks don't form any  part of the OSC message.and 'are for internal use only'

So in LEMUR, to make a button send an OSC message  to make a new video cue, the script for the button is:

oscout (1,'/new','video');  --the 1 at the beginning is just the number of the OSC port for Qlab in my setup.

again the single quotes here are just for LEMUR to use in formatting the message. In the case of an argument with a string this will end up in the datagram with the relevant null characters padding preceded by ,s

Here is the output from Qlab sending a new video cue message  from one machine to another across a network  as sniffed by wireshark.

No.     Time           Source                Destination           Protocol Length Info

     86 12.021176000   10.0.1.31             10.0.1.24             OSC      62     

Open Sound Control Protocol

    Message: /new ,s

        Header

            Path: /new

            Format: ,s

        String: video

0000  7c d1 c3 88 1a ba a8 20 66 19 47 8f 08 00 45 00   |...... f.G...E.

0010  00 30 1f 28 00 00 40 11 45 5f 0a 00 01 1f 0a 00   .0.(..@.E_......

0020  01 18 fe 96 cf 08 00 1c 10 b8 2f 6e 65 77 00 00   ........../new..

0030  00 00 2c 73 00 00 76 69 64 65 6f 00 00 00         ..,s..video…

All the relevant parts, the 00 null padding, the message starting with / the argument type specifier in this case ,s for string   and the argument string are all clearly visible.

On Thursday, February 19, 2015 at 2:52:36 PM UTC, Christopher Ashworth wrote:

Hi Mic,