I don't think that there is a simper configuration than the one that I'm using. Each GUI object has its own send and receive channel and they can all be re-coloured on command. But I wasn't looking for a solution to a problem (the solution is elementary), I was thinking of ways in which the program could be made more efficient. I understand that [send] and [receive] were designed in order to ease the cable-spaghetti that tends to take over the canvas on larger patches. Well, they would ease it even more if [send] could send to any number of channels specified in the creation argument. I would imagine that the coding would be trivial, and it wouldn't have any effect on backwards compatibility. Anyways, just a thought!
To: colet.patr...@free.fr; hard....@gmail.com Date: Thu, 10 Mar 2016 10:36:50 +0000 From: jmmmp...@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] mcompaultiple [send] arguments 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. _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
