[PD] multiple [send] arguments

[Jonathan Wilkes]

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 at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160310/5a905289/attachment.html>