Beware of NOT wiring enough.
Of course, we've all seen what beautifully unintelligible spiderweb artwork people are capable of spewing out when they don't patch with the courtesy of showing their ideas methodically. But an invisible web of sends and recieves can be just as misleading.
I like to use a combination, where there is a single [inlet] to a [route] that uses local [send]/[recieve] pairs within the abstraction. I really like this idea of Frank's to use one "master" send/recieve pair and then weed it all out with [route] objects: it makes it easier to remember what to type!
~Kyle
On 10/12/06, Phil Stone pkstone@ucdavis.edu wrote:
Pardon me for replying in this clumsy way, but I'm not sure how to maintain thread integrity on my replies, since I receive PD-list in digest mode. Since Kyle was kind enough to write me directly, I'm hoping replying to him and his cc of the list will preserve the thread. In reality, though, I'm replying to a few people at once here.
Kyle Klipowicz wrote:
I can already anticipate what some might suggest: try using a single inlet and then pipe that to [route] or [OSCroute].
Then you can use descriptive messaging to both a) provide better information about what data is going where, and b) cut down on having a zillion inlets at the top of your abstractions.
Using OSC style messaging is handy too--just look at RRadical for an example.
~Kyle
This does seem like a good idea, and Frank's follow-up is intriguing, too. My only objection to it is that you still have a lot of wiring that you wouldn't have with my second approach, i.e., you still have to patch the output of [route] or [OSCroute] to the various places the data is needed. Plus, you need to pack the sent information in one place on the parent patch -- another jumble of wires or an additional set of send-receives. I think symbolic routing is a good idea in general, though, so maybe these are not such important considerations.
carmen writes:
Now it occurs to me that I could eliminate the inlets entirely, and
just write to send/receive pairs >directly
how do you find out which instance to send to. are you accessing the
abstraction's $0 from outside the abstraction
One idea, which I've used successfully on another patch, is to add a parameter to the abstraction which is a message prefix.
So, if I called [a_grain~ env samp xyz] the third argument 'xyz' would be the message prefix (it could be anything one liked, even '$0' if you only needed to distinguish one set of messages for an abstraction). Senders in the parent patch would send to xyz-(whatever), as in [s xyz-pointerhop].
The abstraction has [receive] objects of the form [r $3-pointerhop]. Each instantiation of that abstraction will therefore only receive messages intended for it, and one can address as many copies as one likes.
What I like about this is the lack of wires. In the parent patch, there's no wiring (!). I just assign appropriate sends, with the correct prefix, to my sliders, number boxes, etc. In the abstraction(s), there's an appropriately named (with the $3 prefix) receive object sitting right next to whatever needs the message.
I do want to go to the next stage and learn how to persist presets, so Frank's tutorial is particularly appreciated. I'll probably adopt his system for its obvious advantages. I'm just trying to train myself to "think PD" in the most efficient way, in the meantime.
Thanks for the responses,
Phil Stone UC Davis
On 10/12/06, *Phil Stone* < pkstone@ucdavis.edu mailto:pkstone@ucdavis.edu> wrote:
I've been playing with Jamie Bullock's 'a_grain' lately (see http://www.puredata.org/Members/jb/a_grain%7E/view ), and in orderto
understand it better, I've been refactoring it. A_grain has 14 inputs to control various parameters; my first approach to cleaning it up was to put all the inlets, in the correct order,at
the top of the patch -- I then connected those inlets to 'send' objects with $0 variables, placing matching 'receive's close by where they are needed. This really cleaned up the wiring quite a bit, and made it easier to "read". Now it occurs to me that I could eliminate the inlets entirely, and just write to send/receive pairs directly (perhaps also passing in a "prefix" as an argument that is prepended to all receives inside the abstraction, which would allow multiple instantiations of the abstraction, with independent control of each). At the UI-level patch, I could use named senders (from number boxes, sliders, whatever) just hovering nearby the a_grain abstraction; no wires, no mess. I'm wondering what experienced PD architects consider the best practice here; if the second approach is better, I begin to question the advisability of wired inlets for more than two or three arguments. The left-to-right ordering of them, along with the rats-nest wiringcaused
by high numbers of inputs, seem to argue against them. The only downside I can see to the second method is that if it's not done neatly, i.e., the senders are placed indiscriminately and not necessarilynear
the abstraction they're sending to -- it could become very hard to understand/maintain the patch. I'll be interested to hear other PD user's thoughts on this. Phil Stone UC Davis _______________________________________________ PD-list@iem.at <mailto:PD-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO