Hi Liam,Multiple arguments to [send] would be handy. But I think there is a deeper problem: Why do iemguis only let you bind a single receive and a single send symbol? What you seem to need is one *shared* receive symbol-- something like "$0-my-frontend-class"-- and one unique symbol-- like the ones you have in your example. But hiding that kind of complexity in an iemgui dialog is a bad idea (and is likely to create other problems). Anyway, you can always hook a [r $0--my-frontend-class] into the inlet of the iemgui, and maybe use gop abstraction wrappers to make it somewhat manageable. But then the question really is: why use hidden send/receive/init at _all_ in a language whose chief benefit is showing you how data flows? At least with [s] and [r] you see a stump and the symbol that continues the flow of data. Even in your example, you can easily have a bug where you misspelled one of the receive names in your iemgui, and you'd have to manually open a dialog in order to notice it.
My suggestion would be to use those iemgui settings only for prototyping small experiments, and use explicit wires, [s]/[r], and GOP abstractions to deal with larger patches. I think you'll end up with more manageable code that's less buggy.
Jonathan
On Thursday, March 10, 2016 9:46 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2016-03-05 14:55, Liam Goodacre wrote:
The only way I can see of using the right inlet to achieve a multiple send involves [list-drip] and one [float] object, which isn't very efficient.
why do you need it to be efficient. don't get me wrong, efficiency is always a good thing; but the use-case you gave is not something that will be executed each sample-block: you wouldn't see the color-change each 1.5ms anyhow. other use-cases (that do not involve GUI-objects) most likely can get away with a cleaner design. a pattern i regularily use is [route] and a special "all" selector (e.g. "*"), as in:
[r channelgain] | [route *] | | | [route $1] | +-----+ |/ |
and let "$1" be the unique ID of the object (e.g. "1" or "sub")
if performance is so important to you, a more efficient way is to use different receive-labels
[r channelgain-*] | | [r channelgain-$1] |/ |
(iirc, this is more efficient than a [send cg-1 cg-2 ...] could be.
It would also get more complicated if you wanted to send something other than floats
the examples above are agnostic of the actual messsages you send.
--you'd have to use [any] which isn't Vanilla.
no. but [list] is. it is very easy to mimicj [any] with [list prepend]+[list trim] (unless you need to distinguish between "list"s with a symbol as the first atom, and arbitrary messages (with any selector); it get's a bit more complicated then as you need to distinguish between those two cases, but it's still doable in a dozen or so vanilla objects.
You can already send to multiple locations using the [; message( method, but you have to spell the message out every time.
[list prepend set]+[list trim]?
in your case, however, i would just create a single messagebox that sends the color-message to all the receivers:
[colorme, graphicr, savingr, safety, ujr, am, em, bm, foo, bar( | [pack s $0] | [addsemi, add2 $2-$1 color, adddollar 5, adddollar 5, adddollar 3( | [ (
([loadbang] this, make sure the [set( the final messagebox before adding new receivers)
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list