Le 05/03/2016 14:55, Liam Goodacre a écrit :

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. It would also get more complicated if you wanted to send something other than floats--you'd have to use [any] which isn't Vanilla.

it depends how data is managed, for example in qlist all senders are in the same place, with text object the send name can be stored with data of any kind

You can already send to multiple locations using the [; message( method, but you have to spell the message out every time.

the message can be spelled everytime with set add addsemi addcoma and bang messages.

---

Subject: Re: [PD] multiple [send] arguments To: pd-list@lists.iem.at; liamg_uw@hotmail.com From: colet.patrice@free.fr Date: Sat, 5 Mar 2016 14:32:25 +0100

no need for multiple send object when you set dynamically the send message

Le 05/03/2016 12:04, Liam Goodacre a écrit :

If the [send] object could send to multiple locations at once (ie.
[send one two three] ), it would save a lot of work with
connections, as in the attached situation. Would other people like
to see this happen?


_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>  mailing list
UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list

In this situation i'd prepend the message with a destination name. Then
use [route] to filter those destination names in the receives.

I agree: in this particular case, the color message seems to go to lots of
similar gui objects. So better to make a $0-gui (or similar) send
variable. And if relevant, later filter it out as explained above.

yeah you could argue that there are many things that can be done more simply by expanding pd's code base.

for loops come to mind as the most obvious example. instead of using

[1024( | [until] | [f ] x [+ 1]

pd could just have a [for 1024] object.

bit it doesn't, because the is a way to do it without new objects.

this is good in my opinion. It means when you are first learning pd, you only have to learn a small number of objects.

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