On Fri, Jul 18, 2003 at 10:20:02PM -0700, Matthew Allen wrote:
Sorry about the complexity.
No problem at all! The basic feedback was understandable (I *think*) and I've already learned some things I didn't know from your patch (canvases), which is good (and I'm going to be studying it some more).
I am attaching 2 new files (as simple as possible illustrating the point).
Ahem ... that's very friendly of you, except that they didn't make it to my inbox somehow ;)
I think it is normal PD behavior just to turn off the audio stream when you try and connect a straight audio feedback loop (which is why i was suprised you were getting PD to crash, I didnt really think it was a bad loop). NoWorks.pd is basically a straight feedback loop, it just stops producing audio when I connect it.
Right - like I said, when I was preparing a simpler example patch that had the feedback loop in the main patch instead of in a subpatch connected to an outlet~, I also got silence instead of a crash. Which I guess indicates a newbie problem with understanding FM or something ;)
Works.pd is even more interesting. Not using z~ or a delay (straight connections with z~ doesn't seem to work either) instead I am using a throw~/catch~ pair.
throw~ and catch~ I've never heard of until today - I'll take a look at them. What I specifically don't understand is what the difference is between a throw~/catch~ setup and a simple send~ / receive~
And this seems to work. In fact any time I try doing a feedback loop with connections I get the audio shutting off, but if I use a throw~ or send~ i am fine. My assumption here is that both of the remote sending objects have a 1 sample delay?
Well, if they did z~ 1 should work as well. As it stands, z~ gives silence and throw/catch and send/receive work (see attached example patch). Strange ... it's almost as if PD doesn't like an uninterrupted feedback connection but thinks it's ok when there's no direct connection or something.
Oh well ... I've now got three alternatives to make it work (delay, send/receive, throw/catch) so that should be enough to "don't do that then"
either way it should help you come up with an acceptable solution to you problem.
-----Original Message----- From: matthijs@devdsp.net To: Matthew Allen Cc: 'pd-list@iem.kug.ac.at ' Sent: 7/18/2003 1:13 PM Subject: Re: [PD] FM problems
On Fri, Jul 18, 2003 at 09:49:38AM -0700, Matthew Allen wrote:
To the original poster I have attached my work in progress 3-op FM
synth.
Its uses z~ to give the users the ability to feedback any of the
operators
to any other operator (including self feedback). You'll need Zexy of
course
and IEMlibs for the interface.
Thanks a lot - it's *way* too complex for my meagre skills to comprehend, but I'll definitely study it.
But I think I messed up somewhere else as well, because when I was preparing a simple example patch to share with the list that was basically nothing more than the output of a phasor~ and the output of an osc~ added together feeding into cos~ and the output of that manipulating the frequency of the osc~ object, PD no longer segfaulted. Nor did it output sound, but at least this shows there's something else going on.
My Apologies to Miller for stealing the basics from his docs, and also
to
Native instruments for stealing their idea for the Operator matrix. I
have
been programming fm synths since the SY77 came out and I was amazed
when I
first saw this implemented. It just makes sense.
The patch itself is still in pre-alpha. The synthesis works, I'm just working on an interface. Use the bang in the upper left to send note
and
velocity info (unless you have a midi keyboard, then just play the keyboard). I have some random pitch stuff going on so don't thik that
that
is broken, just look in [PD FM_Pitch]. Make sure and set both the feedback/output matrix and the envelopes under them.
m.
-- take care,
Matthijs de Jonge http://devdsp.net - news and resources for computer musicians
Scanned on 18 Jul 2003 20:13:15 Scanning by http://erado.com