I would assume this one block delay could be avoided by „cut” and “undo” of the [catch~] object after creating new [throw~] objects.

Right? But how can you time it if they are in different abstractions?

Ingo

---

Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Björn Eriksson
Gesendet: Donnerstag, 29. September 2011 00:20
An: Lorenzo Sutton; pd-list@iem.at
Betreff: Re: [PD] throw~ / catch~ versus send~ / receive~

Thanks for the info and pointer! Was by that also getting aware about the possible added delay  "When you send a signal to a point that is earlier in the sorted list of tilde objects, the signal doesn't get there until the next cycle of DSP computation, one block later; so your signal will be delayed by one block (1.45 msec by default.)" 

Can be good to know!

/Björn

2011/9/28 Lorenzo Sutton <lsutton@libero.it>

Hi Björn,

On 28/09/2011 15:27, Björn Eriksson wrote:

[...]  what are the

differences between throw~ / catch~  and send~ / receive~ ?  For me they
seem to work equally well, either as "bus" sending or single audio
signal send.

>From the Pd Documentation [1]:

"There can be many throw~ objects associated with a single catch~, but a throw~ can't talk to more than one catch~.
...
Send~ just saves a signal which may then be receive~d any number of times; but a receive~ can only pick up one send~ at a time (but you can switch between send~s if you want.)"

Ciao,
Lorenzo

[1] http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s4.5

Maybe I am doing wrong when I´m summing audiosignals together into a
send~ object just by patching them together and should use the
throw~object instead, but just curious on why and how?//

Thankful for thoughts on this..

All the best,
Björn Eriksson

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