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: [email protected] [mailto:[email protected]] Im Auftrag von Björn Eriksson Gesendet: Donnerstag, 29. September 2011 00:20 An: Lorenzo Sutton; [email protected] 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 <[email protected]> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
