If you want shorter feedbacks than 64 samples within a patch, there is
no way around reducing block size
i still have this itching doubt in that. i think what we're looking for is some real leap of imagination here. we are fine with having a block or 2 latency,,,so i'm imagining maybe there's some far out hack involving synchronised tabread~'s and delayed osc~'s, or something like that, which would somehow do it.
You may be able to optimize by
putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
yeah that seems the most likely approach now.
if cpu is a limit, i guess the only solution is to create an external.
this is probably the 2nd most likely solution.
thanks guys for your ideas and help.
On Fri, Jan 8, 2016 at 7:34 PM, Roman Haefeli reduzent@gmail.com wrote:
If you want shorter feedbacks than 64 samples within a patch, there is no way around reducing block size. You may be able to optimize by putting only the very necessary (for the feedback loop) objects into the re-blocked subpatch.
Then there are some classes that do internal sample-size feedbacks, like [rpole~] or [fexpr~]. While [fexpr~] is quite flexible, it may be even more expensive than a subpatch with blocksize=1 (at least that's what I remember when I compared two implementations, but this observation might have been specific to that kind of problem).
Roman
On Fri, 2016-01-08 at 18:42 +0900, i go bananas wrote:
Hi all, hope everyone's well.
We're trying to implement a 4-op FM matrix with feedback, copying a patch my friend made in reaktor using a block size of 1 (sorry, don't know the full details of that, but he says he can get 1 sample delay for the feedback)
Has anyone ever succeeded doing something like this in pd? I know about the order forcing using subpatches like in G.05.execution.order help patch, but that doesn't seem like it will work here, as we still get DSP loop errors when trying to connect the output of one osc~ back into the frequency input of the others.
I'm really looking for a solution that doesn't involve using blocksize of 1, and anyway, even doing that, still seems the only way to do feedback without getting DSP loop errors is with s~ / r~ pairs, which seem to only work at blocksize of 64 anyway?
I don't mind adding a bit of latency to the whole system if there's maybe a hack to do this with tables or something,,,but am really stuck here wondering what to do.
any ideas?
cheers, Matt _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list