[PD] FM matrix with feedback

Sat Jan 9 15:44:06 CET 2016

First, is the FM matrix actually FM or PM? Most FM are actually PM (phase
modulation).

it's quite easy to do that, just have a [block~ 1] in the subpatch. There
are different options for the feedback, but I prefer delwrite~ and delread~
as cyrille said. Don't use vd~ as it introduces another sample delay!

I'm attaching a folder from my computer music tutorial in portuguese. This
folder contains updates that weren't released yet.

You can find the not updated and complete deal in here
https://sites.google.com/site/porres/pd

direct download link is:
https://sites.google.com/site/porres/Live%20Electronics%20%28EL%20Locus%20Solus%29%20-%20Porres.zip

the complete way to this folder is:

Parte II - Síntese
Basica/15.Modulacao.de.Fase-Frequencia/6.Feedback.Cross.Modulation

If you get all of if you can check also the DX7.pd example, which comes
next.

In the updated version I'm sending, I include a mean filter in the PM
feedback loop, because that's how it seems it is done in FM8 for example.
It reduces the chaos in the feedback.

cheers

2016-01-08 16:31 GMT-02:00 Matt Barber <brbrofsvl at gmail.com>:

> [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
>>
>>
>
> _______________________________________________
> 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/20160109/30b73230/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6.Feedback.Cross.Modulation.zip
Type: application/zip
Size: 45185 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160109/30b73230/attachment-0001.zip>