Is there any equivalent to [poly] but for that support symbols?
I would like to route many osc messages list starting with a symbol names, not an ID... and having the same multichannel features and voice stealing.

not that I know of, can you translate them into a 'note number' with some kind of lookup? (not that pd vanilla is great for maps..)
I guess you could use a big [select] or something to do that

@60hz Not that I know...
I think you will need to build a patch based on [route] ....... so [route dummy] so that you can change its symbol.
Then as an abstraction in [clone] with a method of communication between clones for voice stealing.
It's an interesting challenge.
Maybe someone that can read C can post how it is done in the [poly] binary?
David.

Thanks @seb-harmonik.ar

I will try with a [text define] and [text search]... but I need to have the list of all words... I would prefer to have a mecanism so that new words could be automatically added as parser and ID stealing like [poly] is doing with numbers...

this is something that is really missing in pd

@60hz That's why I thought [route dummy] as you can change the symbol "dummy" to anything that arrives. You would have to [spigot] that once it has its value until your voice stealing logic allows it to be changed.
Actually in [poly] it is only preserved once and is then available if voice stealing is allowed.
I don't think it matters which voice is stolen....... just one that has already output "symbol 0" maybe.....
David.

oh thanks @whale-av I didn't saw you message. i will try that way but I think Already did something like this before and had a logic issue.

And it looks that what I finally need is something a bit different than [poly]... because I need to route the 4 last leading names of my list as an route ID, not redistribute them like poly... hmmm

@60hz What format is your list and how do want the output to vary?
A variation based on what parameters?
David.

The list is like "name 0 0 0 0" where float numbers carry continuous changing parameters sent using osc.
The name vary from like 20 different ones... so I am trying to keep the last 4 active ones and route them to 4 sound generators using [route 1 2 3 4] for example.

The difficulty is keeping track of an ID and the id is a symbol...

Since it is osc the list can have some new messages during time:

Arene 0.2 1 0 0.5
Musee 0.2 1 0 0.4
Arene 0.22 1 0 0.55
Musee 0.1 1.2 0 0.5

@60hz Can you not do that with [route Arene Musee dog cat ... etc.] and send the output... the list of floats where you wish from each outlet of route.

I don't know why you need to keep track of the symbol id's, but they could be added back to the float lists once they drop out of the route...... using [list prepend Arene] etc.
Then you can re-filter the data as you wish.

Is this position data from fiducial markers?
David.

I try to keep no more than 4 or 8 abstractions running at the same time, since they are quite cpu intensive...

Dynamic patching is too experimental to use I think and will add lot of click when create/disconnect etc... (I don"t think it's a good idea to run a dynamic instance of a sound generator on osc messages at all...)

I have something working now and used clones, but I gave up on voice stealing. So I have 24 version of my abstractions with sound generators running in parallel :/ I would prefer a way to have less instances since I think I won't activate more than 4 or 8 of them at once.

@60hz Maybe you could [fudiformat] the name and hash its encoding?

I suck at standard CS numeric algorithms, but you get the idea. Plus I'm confused whether you need to assign voices based on the leading symbol or the trailing 4 numbers.

Edit: wait, you only need to keep track of 4 to 8 voices? Dang, just manage things in [text] using search and don't worry about it.

@60hz If the OSC messages are coherent (on a curve or a straight line) then you will get a good result with devoted sound generators, but if they are jittery (too much noise) then they will be less useful for sound generation.... or anything else for that matter.
Yes..... if you are wanting to swop out generators based on the data then you will need to keep them all all running and pan between their outputs or you will have clicks.
You could use [switch~] to turn their dsp processing on and off, and fade their output in and out with [line] and [* ~] before activating [switch~]....... and that will save you loads of cpu.
There are ways to smooth the data if needs be.
David.

@jameslo said:

Edit: wait, you only need to keep track of 4 to 8 voices? Dang, just manage things in [text] using search and don't worry about it.

Thanks @jameslo Yes, that's exactly what I am doing now, I get an ID from my list of leading symbol and route it to [clone 24 generators ... ]. It is not the best since if there is an updated messafge later, my list will be obscolete but it works. I need to see how it behave tomorow with OSC messages running...because I am worried about the parsing, since I am doing some process after all that and the pd order of executions need to be perfect.

You could use [switch~] to turn their dsp processing on and off, and fade their output in and out with [line] and [* ~] before activating [switch~]....... and that will save you loads of cpu.

Oh yes, I forgot about it thanks @whale-av WIll try tomorrow !

Joining a bit late here. But this discussion just reminded me of two abstractions that I created in the last days. Maybe they might be relevant (otherwise sorry for the noise).

This one will change the leading symbol or number of an incoming message to a sequential number starting from 0:
sequential_remessage.pd

The other one I used to create consistent numbers from a symbol to generate colors for symbols (using the checksum as seed) - I tried to recreate the adler-32 checksum algorithm here (same approach as @jameslo mentioned above with the hash):
checksum.pd

@60hz Voice stealing is not all that difficult to have. Here is 90% of [poly] reworked for symbols and those OSC messages of yours, would be simpler to build this around [poly] but I just simplified an abstraction I already have. The few things it lacks is the ability to turn voice stealing off, changing the number of voices on the fly and an all off, all of which are easy enough to add. Just fire it up with the desired number of voices as an argument. Oh, I also skipped having it bump voices up the list on retrigger/changes since I don't know how retrigger works in your patch and when or if a voice should be bumped up, on retrigger, or on certain changes, or all changes, simple enough to add as well.
spoly.pd

Edit, General clean up of messiness and fixed a bug. And I forgot that I changed the [outlet] to a print for testing, fixed.

Wow, thank you @ben.wes and @oid!

This forum is really full of incredible and helpful people

I will test this tomorrow, today I already fixed many things and all my pd patches are really behaving well so I am confidant about this last osc step!

@oid The tagging is working but It needs to send all messages once in order to work properly.

@60hz If I understood your needs correctly, it should be working? What is your input, what is your desired output and what do you get out?

@ben.wes said:

sequential_remessage.pd

I think this one is already nice because It works well for giving any input message starting with a name, a new ID to feed [clone].

my list is
Arene 0.2 1 0 0.5
Musee 0.2 1 0 0.4
...

what is your desired output and what do you get out?

I am trying to add a [poly] behaviour to the tag ID object, so I have no more than N channel playing at same time with voice stealing.
But with @whale-av advice about using [switch~], I can load many abstractions in clone and activate only active ones.

@60hz Ohh, I forgot to have it send out voice# 0 for the stolen voice so it actually turns off the old voice? Is that the issue? Very simple to fix if that is the case, just a [$1 0( added in. If that is not the issue then we seem to be experiencing a failure in communication. Fixed that and updated the original post.