edit: Oh duh, I can just change the name of the patch to not have spaces. I'd still like to know if spaces are legal and possible with [oscformat] though.

I'd still like to know if spaces are legal and possible with [oscformat] though.

I'm a bit surprised to see this, but in fact, according to the OSC spec 1.0, spaces are not allowed in OSC command paths.

https://ccrma.stanford.edu/groups/osc/spec-1_0.html#osc-address-spaces-and-osc-addresses

Each OSC Method and each OSC Container other than the root of the tree has a symbolic name, an ASCII string consiting of printable characters other than the following:

-character-	-name-	-ASCII code (decimal)-
’ ’	space	32
#	number sign	35
*	asterisk	42
,	comma	44
/	forward slash	47
?	question mark	63
[	open bracket	91
]	close bracket	93
{	open curly brace	123
}	close curly brace	125

So Pd has no obligation to support spaces here.

I suppose it depends on the software's OSC handler. SuperCollider doesn't complain (contrary to the OSC spec):

n = NetAddr.localAddr;  // send to myself

o = OSCFunc({ |msg|
    msg.postln;
    o.free;
}, '/test space');

n.sendMsg('/test space', 1);

prints: [ /test space, 1 ]

I did some other tests:

• "symbol patch 1" --> [list fromsymbol]: escape char 92 is not in the ASCII list.
• list "112 97 116 99 104 32 49" --> [list tosymbol]: resulting symbol prints with a backslash. I don't know if the backslash is stored internally, or if it's inserted only for the printed output. A quick look at the source code in x_list.c suggests that the backslash is not stored internally.
• list "112 97 116 99 104 32 49" --> [list tosymbol] --> [list prepend set] --> [list trim] --> [oscformat]: The printed bytes from oscformat do include char 92. But I couldn't see in the source code where the space is being escaped. (This long way around to build the "set" message is to be certain that there's no backslash in my input -- the backslash must be generated internally somewhere..)

So [oscformat] seems to be where the problem is happening -- but the OSC spec makes no promises that spaces will work, so there wouldn't be any justification to log a bug.

hjh

@jameslo There can be spaces in the address.... the [oscformat] help is full of them between symbols.

Between symbols is different from what I'm asking--I'm asking about within a symbol (i.e. "Container"). [oscformat patch 1] outputs "/patch/1" but what the Qlab OSC dictionary seems to imply it wants is ".../patch 1/...". From their documentation:
and the default name for the one uneditable audio patch you are allowed in the free version is "patch 1". (Did that sound like a complaint? In no way am I looking a gift horse in the mouth! Technically you have to buy a license to be able to adjust that level in the GUI, but for some reason it's adjustable via OSC and it works. I guess their license fee is a tax on non-hackers )

32 is space
47 is slash
I deduce the required end of the message from oscformat output

I think I'd have to also add some padding to the end to meet some message length requirement.

Yes I don't read the doc but I think the message should be a 8 bytes words multiple and ends with 44 0 0 0. So you need to add as many zero as required before this.

Note to self: must get a life

Edit: a more modern version: