Hi all,

I'm a little stuck trying to use routeOSC within an abstraction, with one of the abstraction parameters as a routeOSC filter.

Basically each abstraction object is given a number in the parent patch, e.g. Microphone 1, so if I print $1 within the abstraction on loadbang, I get 1 in this case.

In the abstraction patch itself, I've got a routeOSC objects like so:

[routeOSC /microphones]
|
|
[routeOSC /$1]

I'm trying to have it match only the microphone related to a particular instance, but from what I'm seeing it doesn't seem to do what I want (it seems to only be matching /2 for whatever reason). Any ideas what I'm doing wrong or how to go about it? I'm fairly new to PD, so I'm not sure I've quite got my head around messages and dollar signs yet.

Thanks,

Alex.

Oops, I didn't realise I'd missed an 's'. Well spotted! Sadly that didn't seem to stop routeOSC rejecting the messages. Everything is now 'microphone', and the message looks good at both print objects. I even tried removing the 0/1 on the end of the message, and sending the message manually. Still rejected. The only way I can get it to match is to get rid of the $'s and use the actual strings. Could this be something weird with the routeOSC implementation?

Maybe,
try [OSCroute] instead. I know that it works for exactly what you are trying to achieve. Also, you could remove the second / from the message maybe.... /microphone1 and /microphone2 etc. is sufficient for the routing, although this should not be necessary.

Hmm. It seems OSCroute is rejecting the messages as well. I even tried making it /microphone$1 as you suggested. No dice. I have however just discovered something interesting. I wondered why it seemed to match for #2, so I created two more instances of Microphone, and now it's matching on #4, but not #2. This seems like some sort of bizarre scope issue, but surely $1 etc. are locally scoped for abstractions, or else they wouldn't be of much use, right?

I have done a bit of reading while you have been working, and it seems that routeOSC will not accept a float after the / when creating routeOSC dynamically. That is interesting.... that the last abstraction created will work.
Use [route /$2/$1]........... or in your new patch without the second / then just..... [route /$2$1].

Thanks for all your help. I'm getting rejection with route as well, except on #4. It seems like that's the core of the problem, and that all the routing stuff is probably fine. Whichever instance of Microphone is created last seems to be the one that works. I've re-read the chapter on encapsulation from Miller Puckett's PD book, plus the section on flossmanuals, and I can't see anything different from what I'm doing. I keep feeling like I'm going to have one of those elusive missing semicolon moments, only it never comes.

Hmm, time to sleep on it....
There will for sure be a way to do what you wish.... Just maybe not this way!
David.

Cool. Thanks again.

@nox-deleo
OK so I didn't sleep...........
[udpreceive xxxx] can only be used once (per port). Everything else was a red herring...... I have put it once in "microphones_on_off" and distributed it to the abstractions with [s(end) osc_messages]
working.zip
Open "microphones_on_off"......... put a number for the number of inputs you want and then bang the "create" button. The outlets I have created to (a) show you how to connect them automatically, and (b) immediately show that they have been created. Creating one single object with all of the switches contained within will make it much easier to connect to the outside world afterwards.
You will see your inputs created in "pd microphone_inputs" in the middle of the patch.... you can open it and see the individual input switches (your "Microphone" abstractions)
Now open testOSC and test away.........
Here is your patch now working......................your patch fixed.zip
David.

I did sleep, and it was like waking up and finding a big ol' present under the tree this morning. You the man! microphones_on_off is very cool. Full of shiny new things I've not seen before . Thanks a million David. You've been beyond helpful.