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
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.
That is the best way? Hm, I'm surprised! 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? Anyway thanks for the advice Kim
On 1/30/07, Derek Holzer derek@umatic.nl wrote:
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?"
Hi again,,
Kim Taylor wrote:
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?
Of course it will affect the performance, because a blocksize 1 is very heavy on the CPU. I recommend doing this only in subpatches, with individual block~ objects, rather than for huge sections of your patch. Either your methods with delays, or a send/receive pair in that same subpatch (that's how I would do it personally), will give the same result. Perhaps the send/receive pair has slightly less overhead, but I couldn't tell you for sure.
That is the best way? Hm, I'm surprised!
The best way yes, but that doesn't mean it's nice. Welcome to the wonderful[ly warped] world of PD ;-) d.
I recommend doing this only in subpatches, with individual block~ objects, rather than for huge sections of your patch.
Unfortunately, as I said, the signal feedback loop occurs on the top layer of the program- I tried writing a delay line with the minimum length as an abstraction and completing the system loop with that, but Pd won't allow it, so therefore the top layer (and I'm guessing all the ones below it) needs to be blocksize 1. Effectively my whole program! Anyway, I'll give it a try it before slating it further. K
On 1/30/07, Derek Holzer derek@umatic.nl wrote:
Hi again,,
Kim Taylor wrote:
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?
Of course it will affect the performance, because a blocksize 1 is very heavy on the CPU. I recommend doing this only in subpatches, with individual block~ objects, rather than for huge sections of your patch. Either your methods with delays, or a send/receive pair in that same subpatch (that's how I would do it personally), will give the same result. Perhaps the send/receive pair has slightly less overhead, but I couldn't tell you for sure.
That is the best way? Hm, I'm surprised!
The best way yes, but that doesn't mean it's nice. Welcome to the wonderful[ly warped] world of PD ;-) d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 125: "Only a part, not the whole"
hello kim
On Tue, 2007-01-30 at 12:07 +0000, 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
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. 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... or am I missing the point? Thanks K
On Tue, 2007-01-30 at 12:55 +0000, 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
By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using?.... is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem.
Chuck
hi there, I edited a nice sample to play looped in od, but it clicks a lot, i dont know why... anyone ever had this problem and has any ideas on overcoming it?
cheers
alex
Charles Henry czhenry@gmail.com wrote: By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using?.... is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem.
Chuck
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Everyone is raving about the all-new Yahoo! Mail beta.
PORRES wrote:
hi there, I edited a nice sample to play looped in od, but it clicks a
lot, i dont know why... anyone ever had this problem and has any ideas on overcoming it?
What do you use for looping? [tabplay~ sample_array] or [tabread4~ sample_array]? If using the latter object, do you use [line], [line~] or [vline~] for reading the sample?
Please be more specific, maybe you can attach your patch.
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
actually i just adapted from B08.sampler.loop doc example (it uses tabread~)... which in fact alerts about discontinuity problems, and I was wondering if there was another way around... cheers
Thomas Mayer thomas@dergrossebruder.org wrote: PORRES wrote:
hi there, I edited a nice sample to play looped in od, but it clicks a
lot, i dont know why... anyone ever had this problem and has any ideas on overcoming it?
What do you use for looping? [tabplay~ sample_array] or [tabread4~ sample_array]? If using the latter object, do you use [line], [line~] or [vline~] for reading the sample?
Please be more specific, maybe you can attach your patch.
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
PORRES wrote:
actually i just adapted from B08.sampler.loop doc example (it uses tabread~)... which in fact alerts about discontinuity problems, and I was wondering if there was another way around... cheers
Have a look at B09.sampler.loop.smooth for an easy way to avoid this behaviour. If you want other envelopes, there are other means to build those, e.g. using [envgen].
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
the problem with B09 is that it cuts too much information from the sample... I need it to be constantly loud when looping around! Got it?
Thanks a bunch. Cheers Alex
Thomas Mayer thomas@dergrossebruder.org wrote: PORRES wrote:
actually i just adapted from B08.sampler.loop doc example (it uses tabread~)... which in fact alerts about discontinuity problems, and I was wondering if there was another way around... cheers
Have a look at B09.sampler.loop.smooth for an easy way to avoid this behaviour. If you want other envelopes, there are other means to build those, e.g. using [envgen].
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Don't get soaked. Take a quick peak at the forecast with theYahoo! Search weather shortcut.
PORRES wrote:
the problem with B09 is that it cuts too much information from the sample... I need it to be constantly loud when looping around! Got it?
If you have the zexy externals installed, then you can try using [>~ 0.001] after the [cos~] object in B09. The output will be 1, if greater than 0.001, 0 for smaller values. So, basically, it will cut off small portions of the beginning and end of the samples.
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
Either that, or you could even create your own table with the desired envelope and send the phasor~ output to a tabread4~ that reads it , instead of using cos~ shenanigans.
~kyle
On 1/30/07, Thomas Mayer thomas@dergrossebruder.org wrote:
PORRES wrote:
the problem with B09 is that it cuts too much information from the sample... I need it to be constantly loud when looping around! Got it?
If you have the zexy externals installed, then you can try using [>~ 0.001] after the [cos~] object in B09. The output will be 1, if greater than 0.001, 0 for smaller values. So, basically, it will cut off small portions of the beginning and end of the samples.
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi there, I tried the object from zexy, and it did cut a tiny bit of the end, anyway, that actually creates a harder clicking, as for enveloping it, I wonder if I dont have to envelope it at all, because I want to loop it and keep it constantly loud... like a sinthesiser wave form table.
cheers alex
Kyle Klipowicz kyleklip@gmail.com wrote: Either that, or you could even create your own table with the desired envelope and send the phasor~ output to a tabread4~ that reads it , instead of using cos~ shenanigans.
~kyle
On 1/30/07, Thomas Mayer wrote:
PORRES wrote:
the problem with B09 is that it cuts too much information from the sample... I need it to be constantly loud when looping around! Got it?
If you have the zexy externals installed, then you can try using [>~ 0.001] after the [cos~] object in B09. The output will be 1, if greater than 0.001, 0 for smaller values. So, basically, it will cut off small portions of the beginning and end of the samples.
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
one option is to write an external that deals with this section of the patch...
On 30/01/07, Kim Taylor kimoni@gmail.com 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
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 peterworth2@googlemail.com wrote:
one option is to write an external that deals with this section of the patch...
On 30/01/07, Kim Taylor kimoni@gmail.com 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
Oops, I thought that this was the thread talking about the looping sampler! Sorry!
Hahaha.
~Kyle
On 1/30/07, Kyle Klipowicz kyleklip@gmail.com wrote:
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 peterworth2@googlemail.com wrote:
one option is to write an external that deals with this section of the patch...
On 30/01/07, Kim Taylor kimoni@gmail.com 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)))oOOOOOO
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
By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using?.... is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem.
The structure I am implementing is basically a modified model of the structure shown on this page - http://ccrma.stanford.edu/~jos/swgt/Rigidly_Terminated_Ideal_String.html
I have this model working (by using a delay with length 0 and blocksize set to 1), if you're interested it's here http://www-users.york.ac.uk/~kt503/PD/kt1-d_DWG-a.zip (unzip to folder, open 1-Ddwg-2g.pd)
However I now need to integrate this with other modules on a higher level (this is just a simple component). The idea is that the delay line is bi-directional, and at the terminations they always form loops, so as far as I can see it can't be implemented without it... K
Hallo, Kim Taylor hat gesagt: // Kim Taylor wrote:
The structure I am implementing is basically a modified model of the structure shown on this page - http://ccrma.stanford.edu/~jos/swgt/Rigidly_Terminated_Ideal_String.html
I have this model working (by using a delay with length 0 and blocksize set to 1), if you're interested it's here http://www-users.york.ac.uk/~kt503/PD/kt1-d_DWG-a.zip (unzip to folder, open 1-Ddwg-2g.pd)
Are you sure you packed the right patches? There's not a single [block~] used in that archive according to "grep block *.pd".
Anyway for this kind of "recirculating delayline" your lowest delay time is one block in Pd because of the feedback. See Miller's T&T book for a longer explanation.
However I now need to integrate this with other modules on a higher level (this is just a simple component).
You probably want to use more "$0-" variables for send/receive and delay names then. I would recommend to make it a habit to *always* use variables prepended with "$0-" and only skip the $0- if you really want global access deliberately. Personally I'm even using UPPERCASE names for these.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Yeah, you're going to need to need to go with the small blocksize to realise this in vanilla Pd. But a blocksize of one isn't absolutely necessary, you'll probably get away with 8 or 16 for the frequency ranges of typical plucked/hammered strings. Also, the patch is extremely simple, so I wouldn't worry about the expense too much. Just wrap it in an abstraction/subpatch so that the rest of your patch can run with a standard 64 block.
Take care not to get caught out by the creation order gotchya for [s~]-[r~] pairs :) Check the archives on this. As Frank pointed out recently on a similar topic the minimum delay loop time with this is actually zero, so an extra [z] wouldn't hurt.
Andy
On Tue, 30 Jan 2007 19:24:12 +0000 "Kim Taylor" kimoni@gmail.com wrote:
By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using?.... is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem.
The structure I am implementing is basically a modified model of the structure shown on this page - http://ccrma.stanford.edu/~jos/swgt/Rigidly_Terminated_Ideal_String.html
I have this model working (by using a delay with length 0 and blocksize set to 1), if you're interested it's here http://www-users.york.ac.uk/~kt503/PD/kt1-d_DWG-a.zip (unzip to folder, open 1-Ddwg-2g.pd)
However I now need to integrate this with other modules on a higher level (this is just a simple component). The idea is that the delay line is bi-directional, and at the terminations they always form loops, so as far as I can see it can't be implemented without it... K
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, you're going to need to need to go with the small blocksize to realise this in vanilla Pd. But a blocksize of one isn't absolutely necessary, you'll probably get away with 8 or 16 for the frequency ranges of typical plucked/hammered strings.
Very true... blocksize 2 will give me a range of 22KHz, 4 will give me 11KHz, which might well be more than enough for the ranges of stringed instruments- time to research!! Thanks I hadn't thought of that
-K
Also, the patch is extremely simple, so I wouldn't worry about the expense too much. Just wrap it in an abstraction/subpatch so that the rest of your patch can run with a standard 64 block.
Ok, here's an improvement http://www-users.york.ac.uk/~kt503/PD/kt_PluckedString_23Jan.zip
Take care not to get caught out by the creation order gotchya for [s~]-[r~] pairs :) Check the archives on this. As Frank pointed out recently on a similar topic the minimum delay loop time with this is actually zero, so an extra [z] wouldn't hurt.
Andy
On Tue, 30 Jan 2007 19:24:12 +0000 "Kim Taylor" kimoni@gmail.com wrote:
By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using?.... is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem.
The structure I am implementing is basically a modified model of the structure shown on this page - http://ccrma.stanford.edu/~jos/swgt/Rigidly_Terminated_Ideal_String.html
I have this model working (by using a delay with length 0 and blocksize set to 1), if you're interested it's here http://www-users.york.ac.uk/~kt503/PD/kt1-d_DWG-a.zip (unzip to folder, open 1-Ddwg-2g.pd)
However I now need to integrate this with other modules on a higher level (this is just a simple component). The idea is that the delay line is bi-directional, and at the terminations they always form loops, so as far as I can see it can't be implemented without it... K
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 31/01/2007, at 13.53, Kim Taylor wrote:
Ok, here's an improvement http://www-users.york.ac.uk/~kt503/PD/kt_PluckedString_23Jan.zip
Thanks for sharing this, it's much fun to play with - and potentially
learn from, i might add.
-
Charles Henry -
Derek Holzer -
Frank Barknecht -
Kim Taylor -
Kyle Klipowicz -
padawan12 -
Peter Worth -
PORRES -
Roman Haefeli -
Steffen -
Thomas Mayer