Dan, After reading your reply to a separate thread, I took a look at your MrPeach to vanilla OSC patch here:
https://github.com/danomatika/BangYourHead/tree/master/6.Communication https://github.com/danomatika/BangYourHead/tree/master/6.Communication
I am trying to adapt your patch to use the TouchOSC app from my iPhone. However, I am running in to a road block. Everything works as expected until the output of [list trim]. At that point, I can print the data but unable to route the data further. The printed message seems fine; it is usually something like: 1 toggle1 1. (This message is the result of turning the first toggle on page 1 on.)
If I send this message “1 toggle1 1” to a [route 1], I expect the message toggle1 1 to come out of the first outlet of route, however, nothing comes out of the first outlet.
My patch looks like this:
[listen 8000( | | [netrecieve -u -b] | | [oscparse] | | [list trim] | | [route 1]
I’d like to have a [route 1 2 3 4] to separate the data coming from the various pages in the OSC app. From there, I’d like to further direct the data using [route fader1 fader 2 toggle1 toggle 2].
Thanks for any help, Mitch
On Sat, 2019-07-13 at 12:01 -0400, Mitchell Turner wrote:
If I send this message “1 toggle1 1” to a [route 1], I expect the message toggle1 1 to come out of the first outlet of route, however, nothing comes out of the first outlet.
There is a distinction in both worlds, Pd messages and OSC messages, between a two-element-list with float 1 and the symbols "toggle" on one hand and on the other a symbol containing "1 toggle". [route 1] catches only the former, while the latter is passed to the right outlet.
Make sure that you send OSC messages with two atoms, '1' and 'toggle' instead of one symbolic atom '1 toggle'.
Roman
I think the problem lies somewhere else. There is a fundamental issue with [oscparse]: it breaks the address pattern into its parts and forms a Pd list, but treats numbers as symbols.
In Mitchell's case, he might be sending an OSC message like "/1/toggle1 1", so [oscparse] outputs a list "1 toggle1 1". However, the first atom "1" in the list will be a symbol, so you can't route it with [route 1]. There's a workaround: split the list with [list split 1], pass the first atom through [f] (since Pd 0.48 it interprets symbols as floats) and join the two lists again with [list append].
@Miller: addresses like "/foo/1/bar/2" are very common and the output of [oscparse] can cause confusion. Would you agree that the number parts should be rather interpreted as floats? Would it be too late to change this? If we keep the current behavior, we should at least clearly document it (and show the workaround).
[unpackOSC] doesn't have this problem because the address parts are cleary symbols and you can route them with [routeOSC /1 /2 /3 /4], etc.
Christof
Gesendet: Samstag, 13. Juli 2019 um 18:28 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] OSC data from [list trim]
On Sat, 2019-07-13 at 12:01 -0400, Mitchell Turner wrote:
If I send this message “1 toggle1 1” to a [route 1], I expect the message toggle1 1 to come out of the first outlet of route, however, nothing comes out of the first outlet.
There is a distinction in both worlds, Pd messages and OSC messages, between a two-element-list with float 1 and the symbols "toggle" on one hand and on the other a symbol containing "1 toggle". [route 1] catches only the former, while the latter is passed to the right outlet.
Make sure that you send OSC messages with two atoms, '1' and 'toggle' instead of one symbolic atom '1 toggle'.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2019-07-13 at 18:46 +0200, Christof Ressi wrote:
I think the problem lies somewhere else. There is a fundamental issue with [oscparse]: it breaks the address pattern into its parts and forms a Pd list, but treats numbers as symbols.
Ah, thanks for pointing this out. From the original post it was (at least for me) not quite clear whether it was about the OSC atoms (the actual payload) or the OSC path.
Good to know that numeric path elements end up (actually: are preserved) as symbols in Pd after [oscparse].
Roman
oscformat splits the address as symbols (aka strings), so the “1” in your address is actually a symbol and not a float which is why it doesn’t match. route doesn’t allow mixed symbols or floats so you need to create an empty route object and send a “symbol 1” message i to its right inlet with a load bang. This explicitly matches to “1” as a symbol.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Jul 13, 2019, at 6:01 PM, Mitchell Turner mmturner2468@gmail.com wrote:
Dan, After reading your reply to a separate thread, I took a look at your MrPeach to vanilla OSC patch here:
https://github.com/danomatika/BangYourHead/tree/master/6.Communication
I am trying to adapt your patch to use the TouchOSC app from my iPhone. However, I am running in to a road block. Everything works as expected until the output of [list trim]. At that point, I can print the data but unable to route the data further. The printed message seems fine; it is usually something like: 1 toggle1 1. (This message is the result of turning the first toggle on page 1 on.)
If I send this message “1 toggle1 1” to a [route 1], I expect the message toggle1 1 to come out of the first outlet of route, however, nothing comes out of the first outlet.
My patch looks like this:
[listen 8000( | | [netrecieve -u -b] | | [oscparse] | | [list trim] | | [route 1]
I’d like to have a [route 1 2 3 4] to separate the data coming from the various pages in the OSC app. From there, I’d like to further direct the data using [route fader1 fader 2 toggle1 toggle 2].
Thanks for any help, Mitch
-
Christof Ressi -
Dan Wilcox -
Mitchell Turner -
Roman Haefeli