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