Sure, it's just that if you have this:
[bang (
| \
| \
[obj] [obj] [obj]
You can't be sure of the order of said bangs. This is a "bad" thing to do. If you implement your patch as an abstraction, because it won't be very detirministic, and (even if you want randomness) this can cause problems with the patches when they get nested so deep.
Instead, use something like this:
[bang (
|
[t b b b ]
| \
| \
[obj] [obj] [obj]
Which will ensure that you get the same order of execution (right to left) every time. This will save you much headaches if you have say, 5 abstractions nested inside and find that things just aren't working very tightly, especially if you are doing processes that run very quickly together.
Your patches seem to work fine, but this practice is agreed apon by all the pd-guru's I've seen talk about the matter on this list, so it would be great for you to communicate it to newbies who read your examples.
Trigger is _the_ most important object to learn early on, so you get proper patching techniques down and understand the "firing" order of your data.
Search the archives for fbar's posts on the matter, I think he has some working examples. Frank, if you're listening, would you kindly repost or send them privately to Andy?
~Kyle
On 5/16/06, padawan12 padawan12@obiwannabe.co.uk wrote:
Thanks for this Kyle. I need you to elaborate a little if you would. Can you provide an example of where it's done wrong and how it would be done strictly correctly? I've always found the typing of Pd most confusing and while I try to cultivate good and proper habits I tend to get stuck in my own methods of "what works" rather than what's technically perfect.
In what circumstances might the code be unpredictable? Are we talking differences in the way Mac/PC/Linux versions of Pd handle things, I do hope not! Are the reasons to do with race hazards? I've never seen any documentation that properly explains this I'm afraid. I don't want to have to rewite scores of examples so the earlier I grasp what you mean the better.
Many thanks indeed, Andy James Farnell
On Mon, 15 May 2006 17:03:30 -0700 "Kyle Klipowicz" kyleklip@gmail.com wrote:
The only concerns I have (sounding like Frank now) is that many of your bangs are patched without using the trigger object. I think that to keep the code clean and predictable, it would be a good strategy to implement triggers for all multiply connected events. Also, that would be nice to communicate to novice Pd users, so they start their coding habits early.
Other than that, awesome work!
~Kyle
On 5/15/06, padawan12 padawan12@obiwannabe.co.uk wrote:
Hi Kyle,
Thanks for your kind remarks. I just added "footsteps" and "switches" so that makes 12 I think. The finished book will contain about 40, but it will remain a free web resource whether O'Reilly take it or not. Please don't be shy to let me know any errors or bad points you find too, or any ideas you would like me to try and deal with.
All best regards, Andy James Farnell
On Sun, 14 May 2006 14:23:50 -0500 "Kyle Klipowicz" kyleklip@gmail.com wrote:
Oh wow! I just peeked at them, this is a great site! How many tutorials are there now? As a fan of foley art, I can greatly appreciate this knowledge, thank you!
~Kyle
On 5/14/06, padawan12 padawan12@obiwannabe.co.uk wrote:
Greetings,
I finished another tutorial in my collection for "Practical synthetic sound design". That makes 10, so now I think its time to welcome feedback on the subject style, how easy/hard they are to follow, if the examples work and make sense..
My target for September is 40-50 tutorials to make a full set which I hope will serve as the "practical" complement to Millers book dealing with the theory. These are early drafts and much will change to better structure them. There are no musical examples. It's never been my intention to cover the ground already mapped by Dodge and Jerse, Roads, and others. This work is aimed squarely at the games and film sound designer and attempts a non-mathematical approach.
I greatly appreciate your sincere and honest criticisms. Personal replies are preferred to list posts.
Right now they live here http://www.obiwannabe.co.uk/padawan12/onlinetutorials/html/tutorials_main.ht...
Cheers, Andy
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
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
Search the archives for fbar's posts on the matter, I think he has some working examples. Frank, if you're listening, would you kindly repost or send them privately to Andy?
I think you explained it very well. I attached a tiny little example to illustrate why relying on the order, connections were made, can go completely wrong.
In practice, the execution order of connections that "fan out" of a single outlet should be considered to be completely undefined. The manual mentions the creation order as a guideline, but this is a remark which should be removed IMO because it's more confusing than helpful: One cannot rely on the order of creation in real life.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Kyle Klipowicz