In Max/MSP, you can set a message's content by sending it to the right inlet. In pd, at present, [prepend set] and sending that to the left inlet works, but the console warns that [prepend] is considered deprecated, and that one should use [list prepend] instead. Then you have to use [list trim] to remove the 'list' from the start.

If a pd user wants to store a message, and then send it with a bang, in Max/MSP this is done via a single object. With pd, and with prepend being deprecated, and list requiring trim, what can be done easily with a single message in Max/MSP now requires a message and two objects, and wiring them together.

Is there some reason why storing and forwarding messages this way is considered bad practice? And what should I be doing? (I'm porting some Max patches to pd at the moment.)

And out of curiosity, how hard would it be to modify pd so that messages have a right inlet which functions as a shortcut for ([list prepend set] -> [list trim] -> first inlet of message)?

Well, pd's messages are weird. I haven't looked, but I kinda assume the code is inefficient as using a single message is slower than using a [list prepend ] -- [list trim ] combo.

This bears repeating because it is the opposite of what you would probably intuit.

Messages are slower than the list objects.

This might change, as the list objects are new compared to messages, but the code for messages probably has to sanitize a lot more inputs than the list objects...
Also fyi, the prepend and append objects are part of the cyclone library and are not part of vanilla.

The reason why you would use the list objects rather than messages really just comes down to pd's semi-explicit typing. Some objects need to know what kind of input is coming so they need a selector like list, symbol, float, set, etc. Other objects just interpret whats coming at them so they don't need a selector.

Also, in regards to editing pd's messages. I'm pretty sure that is entirely in c, so you would have to fork pd and recompile it with your changes.

Since messages are one of the original things in pd, I bet its tangled up in a lot of other code... but it might not be hard. If it were me though, I'd just try get used to the [list prepend ] -- [list trim ] combo, as you can have mutating messages with just a list object.

Really the only things I use messages for anymore are loadbanging things before audio starts, and string manipulation. With strings, I use it rarely too; I tend to just use [list fromsymbol ] --- logic --- [list tosymbol ].

It looks like more clutter, and it can be weird when you have an object that needs a selector or doesn't, but its faster than plain messages. You can store big messages too, like [list prepend set $0-sine ] -- [list trim ] will set a tabread object.

edit:: you can do anything the zl objects can do with the list objects and some logic. Try making something recursive. Careful not to crash pd though. The list-abs library has some premade patches, some are bulkier than I would use, so you can trim them down to your liking.

@Monetus While you are watching and on this subject Monetus...... how can I get rid of the symbol selector, and thereby route symbols. When implicit they are routable..... when explicit they are not. Vanilla is driving me crazy! I only seem to be able to do so by packing it with a float.... but it is back like a bad penny when un-packed.
David.

Hmm.. @whale-av. You could route out all the other selectors you have. Or play around with some form of type checking..

@whale-av [list trim] gets rid of the symbol selector too! Took me years to figure that out.

@Monteus It's true that you can do all of the [zl] things with [list-abs], but these solutions tend to be mega-slow. Beautifully recursive though it is, [list-dip] is no match for cyclone's [iter].

@LiamG said:

@whale-av [list trim] gets rid of the symbol selector too! Took me years to figure that out.

Woah, I've been trying to figure out for the longest why my state-saving abstractions forget that symbols are symbols. This never occurred to me. Now I can probably fix them, thanks!

@LiamG @Monetus Thank you both..... very useful. I think I must have tried [list trim] and some others as well....... and of course the "symbol" tag turned out to be a red herring.
I also thought that "whitespace" might no longer be 32, and tried all the others.

It turned out that [list tosymbol] will create symbols "containing" spaces...?!?!
Stumped me totally for days. Space as a separator had been impressed in my brain.
It's all very new and time consuming....... and I really miss [rawprint] on these occasions.
David.