request: inlet for [receive] to set receive symbol

[porres]

this would free me from the dependency of using [r.mmb]

[porres]

this is particularly useful to create GUI abstractions that behave like other GUIs, where you can give it a 'receive' name via an input message from the inlet

[jaffasplaffa]

Just asked about this today. I hadn't seen that it was already requested, so I'll post here instead.

Would be great to have this :)

Maybe is can be made so it is also possible to use a "set name" and not only "symbol name", basically the same way as the tabread uses a "set" message to set a name dynamically. And maybe also add the same for the send object, so they use same methods. Send uses "symbol name" as it is now.

Cheers!

[Spacechild1]

Maybe is can be made so it is also possible to use a "set name" and not only "symbol name",

why add two ways to do the same thing?

basically the same way as the tabread uses a "set" message to set a name dynamically.

IMO, [receive] should match the semantics of [send] (i. e. use an inlet), and not that of unrelated objecs like [tabread]

[jaffasplaffa]

I think "set" makes more sense than "symbol", as it actually describes what it does.

And since the send object already uses "symbol", changing it to "set" would break backwards compatibility?

So that's why I suggested to add it, so it won't break anything.

But yeah, using "symbol" will also work, I guess, if thats the norm for that line of objects :)

[porres]

But yeah, using "symbol" will also work, I guess, if thats the norm for that line of objects :)

yeah, cause then they're consistent between each other, it'd be weird that [r] has "set" but [s] doesn't - and it'd be really hard to add a set method to the second inlet of [s]

[jaffasplaffa]

Yes, they need to be identical, I agree and also be backwards compatible.

But set just makes more sense than symbol, imo.

so symbol is probably the way to go, then it won't make too much of a fuzz :)