[rpole~] can be a good option depending on the kind of flexibility you need. Why the distaste for [block~] size of 1 if it works?
Do you have some pseudocode or a block diagram? That would make it easier to give advice. On Fri, Jan 8, 2016 at 11:53 AM, David Medine <dmed...@ucsd.edu> wrote: > 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 <reduz...@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> >> 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> >> http://lists.puredata.info/listinfo/pd-list >> >> > > > _______________________________________________pd-l...@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 > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list