[PD] FM matrix with feedback

[Matt Barber]

[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 <dmedine at 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 <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>
>> 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>
>> 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
>
>
>
> _______________________________________________
> 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/171ef6a8/attachment.html>