[PD] FM matrix with feedback

David Medine dmedine at ucsd.edu
Fri Jan 8 17:53:37 CET 2016


This is not for the faint of heart (it is poorly organized and not 
documented at all), and there is no build environment set up for OSX or 
Windows, but I wrote a C language API that I rolled into a Pd extern 
which takes compiled C files that describe feedback networks with 
approximately 0 time delay. This is done by modeling the network with 
dynamical systems and solving numerically. I gave a talk about this at 
ICMC this year.

Using these tools I made a program that runs in Pd that has two 
oscillators that can frequency modulate and sync one another and 
themselves. It maintains the 64 sample block size and the CPU load is 
minimal. It can easily be extended to N oscillators.

I can send a copy of the paper to you directly if you are interested (I 
don't want to hit the whole list with a pdf). Here is the project on 
github -- please forgive my many sins, this is not yet ready for release 
and it shows. https://github.com/dmedine/timelab
-David

On 01/08/2016 03:00 AM, i go bananas wrote:
> > 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 
> <mailto: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 <mailto: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 <mailto: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/89efa2c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DEM_ICMC2015_corrected.pdf
Type: application/pdf
Size: 438175 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160108/89efa2c2/attachment-0001.pdf>


More information about the Pd-list mailing list