@rph-r Yes, that will be a list...... and "messages" will be the selector followed by 'like' 'this' etc. as symbols.
[rawprint] is a useful external to analyse formats.
This should help...... concat.zip
Sending [symbol( into the right inlet of [concat] before passing the message will turn the whole message (including the selector) into a single symbol, keeping the spaces between the original atoms.
I am pretty sure that it was made by @jameslo...... but I could be mistaken...
The comma in your message will always be interpreted as "new message" though.

The MrPeach library has an external [str] which can manipulate different message
formats in many ways.
And the old cxc library from Pd extended..
cxc was updated for 64-bit Pd by Lucarda in 2018 (for windows and maybe for other os's)....
.....very useful for string manipulation in Pd.
David.

Because only messages beginning with a float as first atom are implicitely handled as lists by puredata.
If you suppress this first atom with [route], you get a message with 2 atoms, the first being treated as a selector, and the second as a float.
This message is handled as a message --like, for example, the message [ set 1( -- , not as a list.
You must prepend the "list" selector to further process it as a list : just insert a [list] object after the output of [route].

Mabye

[symbol]
|
[float]

does the trick?

Pobably it is not encoded as float but neither has no symbol selector.
A symbol without 'symbol' selector looks like a float but isn't.

(btw there is [int] but ints are floats in pd)

In this case I think we can safely use the [route] solution with the addition of two [list]s to restore the selector. Am I missing anything?

Edit: Yup was missing something, we can not route anythings which lack a selector. Knew I was forgetting something. A little cleaner than the 4 spigots, probably a little less efficient on the routing but quicker on the switching? But what happens with pointers? Not really sure how those work in pd.

dmux.pd

@beep.beep I would vote for @manuels [route] solution, although in the case you posted that deals only with bangs [select] will do the job.
And not just because I already thought [sel] would do the job.

It's simple, and so it is easy to read.
None of any incoming list on the left inlet is dropped, only the prepended selector.

There are problems with [route] and [select] type matching, but as the list will always start with the float selector from the right inlet it will be reliable.
Until it receives the selector at the right inlet the first message will pass to the left due to the initialisation of [list prepend 0] ...... matching [demux].... the zexy external.
That also stops a message such as [1 bang( from passing to the right outlet after creation.

But as I know you will all test it to destruction I await the reasons why it is a bad solution.
David.

@manuels Great idea, although as @oid mentioned, I'd be concerned about how selectors may be affected by [route]. So I guess all of these various solutions have boiled down the crucial [vdemux] requirements to:

• must guarantee only one output from specified outlet, regardless of subsequent [trigger] objects
• must pass messages to specified outlet with no changes to selector (or lack thereof)

@oid I really have no idea how many symbols my biggest patch generates. Tens of thousands? Nor would I know what symptoms to look out for if I was close to hitting Pd's limits in that way; my patch already slows to a crawl when all parts of it are switched on, but I imagine much of that is due to Tcl/Tk bottlenecks, and/or possibly a flood of message/network traffic bogging things down. Very interesting idea to put symbols in a list as a workaround... that's way over my head but if you think it'd work I believe you!

Also: not to get ahead of myself, but I'm also now realizing that this will be a problem for [mux] too...

...and since [receive] can't be reassigned on the fly as [send] can, seems like yet another approach is needed. Whew!

hi, i have an abstraction which has [s $0-selector] - and that's fine. but i've got abstractions inside the patch which, currently, receive [r selector] - and i'd like to get the $0-selector to be receivable there. how do i do this?

selector~ documentation explains that the index signal should be:

• 0 to shut off all signals
• 1 to choose the second inlet (because the first inlet is the index)
• 2 to choose the third inlet, etc.

>~ outputs 0 if false and 1 if true.

So the direct output of >~ does not match up to selector's expectation -- hence should not be expected to work, without some adjustment.

Therefore you will need to add 1 to the >~ result, before selector.

hjh

I am trying to recreate the cyclone custom kink module , which distorts the phase of the phasor
This is the implementation in reaktor primary
A comparitor compares the incoming phasor sig X ( range 0-1) against variable D .
When x > d , then green field algo , when X<D blue box algo .
The output of the comparator~ ( which is square wave ) should then open route the algo's to an audio rate selector ( just like reaktor °) , but this just isn't working .
The algo's are correct , could it be that the selector module is not selecting it's input at audio rate ?
Here's the patch
customkink.pd



Result ( in reaktor °)

Using the metro_pat abs posted here:

https://forum.puredata.info/topic/14011/metro_pat-a-metro-but-with-a-pattern-selector-for-all-patterns-given-a-beat-length/1

But eight of them all sending their bangs to an eight-track sampler I am working using it and and Akai Midimix, 8 track controller.