[PD] DSP loops
Hi again all I'm having a bit of trouble putting my program together. I'm trying to implement a series of object blocks that form the synthesis framework, up until now everything's been ok. My problem is that on the top level of the program, I'm trying to connect the blocks together, but the configurations I desire involve feedback and result in error: DSP loop detected (some tilde objects not scheduled) I know send~ and receive~ can be used to overcome this, also throw~ and catch~ if I'm not mistaken. However I can't use these as they result in a fixed length time-delay. Normally this wouldn't matter so much, however as my synthesis technique relies almost fundamentally on very small delays (I'm implementing digital waveguide synthesis) this fixed delay time makes a huge difference. I'm not terribly experienced with Pd, has anyone been in a similar situation and care to share some experience? The only way I can think of overcoming the DSP loop problem is to use a delread~ and delwrite~ to complete the loop, setting the delay time to 0 and setting the level sampling block size to 1. However this seems a very roundabout way of doing it and not ideal, especially for the top level of the program! Cheers Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP loops
Hi Kim, Kim Taylor wrote: The only way I can think of overcoming the DSP loop problem is to use a delread~ and delwrite~ to complete the loop, setting the delay time to 0 and setting the level sampling block size to 1. Because of PD's structure, it is exactly that delay which is necessary. Computers are dumb animals, and need to be told to do things in certain orders of operation, and not everything at once ;-) Frustrating, but necessary. Implementing the shortest block size possible and sending your feedback through that is just about the only workaround, so you're on the right track already. d. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 202: Back up a few steps. What else could you have done? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP loops
hello kim On Tue, 2007-01-30 at 12:07 +, Kim Taylor wrote: That is the best way? Hm, I'm surprised! yes, it is. what did you expect? of course, when working with recursion, there has to be a result already before computing the next iteration. that is not a matter of pd, but of pure logic. Ok, I'll get to work then- It means the layer with the system topology needs to have its sampling block forced to 1. Mightn't this affect performance? especially for a large program? yes, it does. either you set the block-size to 1 or you could use [fexpr~ ] or any other object that allows recursion ([rpole~], [rzero~], [biquad~] and the like), which might not do exactly, what you want. so [block~ 1] might still be the best choice. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP loops
On Tue, 2007-01-30 at 12:55 +, Kim Taylor wrote: Roman, either you set the block-size to 1 or you could use [fexpr~ ] or any other object that allows recursion ([rpole~], [rzero~], [biquad~] and the like), which might not do exactly, what you want. so [block~ 1] might still be the best choice. When you say they allow recursion, I don't understand how they can be used to overcome the DSP loop problem. actually, they don't overcome the dsp loop problem. they get one block of audio samples for computation, compute something (it doesn't matter, if the object internally uses '1' as a block-size) and spit the result to the outlet, again in a block of samples. of course, this recursion happens only internally, within the object. As I understand it these functions work recursively- in the case of the filters rpole~ and rzero~ by using the values associated with previous sampling intervals- but on a higher level their addition to the signal chain doesn't allow for recursive behaviour... yes, true. or am I missing the point? no. it possibly was a bit confusing from my side to bring [rzero~] and such in. it depends on what you want to achieve. if it's something filterlike, they might would have helped. also, if you can pack your whole program into one [fexpr~ ], that would possibly be an alternative, too (though [expr]/[expr~]/[fepxr~] are known to be slow). if nothing of this is better, then using [block~ 1] is the best, though not nice. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP loops
one option is to write an external that deals with this section of the patch... On 30/01/07, Kim Taylor [EMAIL PROTECTED] wrote: Hi again all I'm having a bit of trouble putting my program together. I'm trying to implement a series of object blocks that form the synthesis framework, up until now everything's been ok. My problem is that on the top level of the program, I'm trying to connect the blocks together, but the configurations I desire involve feedback and result in error: DSP loop detected (some tilde objects not scheduled) I know send~ and receive~ can be used to overcome this, also throw~ and catch~ if I'm not mistaken. However I can't use these as they result in a fixed length time-delay. Normally this wouldn't matter so much, however as my synthesis technique relies almost fundamentally on very small delays (I'm implementing digital waveguide synthesis) this fixed delay time makes a huge difference. I'm not terribly experienced with Pd, has anyone been in a similar situation and care to share some experience? The only way I can think of overcoming the DSP loop problem is to use a delread~ and delwrite~ to complete the loop, setting the delay time to 0 and setting the level sampling block size to 1. However this seems a very roundabout way of doing it and not ideal, especially for the top level of the program! Cheers Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP loops
Hey, Kim, I liked your patch, it has some very nice sound to it, and I like being able to pan through the pluck/transducer location to hear all the harmonics. That's really cool. Now the way I see it, you could implement this as a sort of ping-pong delay with the separate damping filters and *build-in* pd's own 64-sample block delay time into the delay lines (subtract off the approx ~1.5 ms for 64-samples). This would mean that you have a minimum delay time of ~1.5 ms for the forward and backwards travelling waves (and consequently limits your fundamental freq--so, if you need higher frequencies, that's when you would need to reduce the blocksize). Then, you just have to include a couple of taps on each delay line to take the results and sum them together. I'll have another look at it later, and see if I can modify it. Chuck ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP loops
That sounds a bit like over kill. Why not try to create a different envelope generator, if the one based on the cosine doesn't suit you? ~Kyle On 1/30/07, Peter Worth [EMAIL PROTECTED] wrote: one option is to write an external that deals with this section of the patch... On 30/01/07, Kim Taylor [EMAIL PROTECTED] wrote: Hi again all I'm having a bit of trouble putting my program together. I'm trying to implement a series of object blocks that form the synthesis framework, up until now everything's been ok. My problem is that on the top level of the program, I'm trying to connect the blocks together, but the configurations I desire involve feedback and result in error: DSP loop detected (some tilde objects not scheduled) I know send~ and receive~ can be used to overcome this, also throw~ and catch~ if I'm not mistaken. However I can't use these as they result in a fixed length time-delay. Normally this wouldn't matter so much, however as my synthesis technique relies almost fundamentally on very small delays (I'm implementing digital waveguide synthesis) this fixed delay time makes a huge difference. I'm not terribly experienced with Pd, has anyone been in a similar situation and care to share some experience? The only way I can think of overcoming the DSP loop problem is to use a delread~ and delwrite~ to complete the loop, setting the delay time to 0 and setting the level sampling block size to 1. However this seems a very roundabout way of doing it and not ideal, especially for the top level of the program! Cheers Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ 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)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
