[PD] FM matrix with feedback

[i go bananas]

> 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 at 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160108/c06f425f/attachment.html>