As i suspected, i wasnt able to reproduce the simple feedback fm algorithm that is in the computer music tutorial book so i came here with hope that someone could help me patch a simple feedback fm algorithm in Pd or tell me what are the workarounds with feedback in Pd so i can build it myself.
Thanks in advance

I can't remember the feedback algorithm in the Computer Music Tutorial, and since that book is so thick, I'm not going to bother looking it up. Pro-tip: you should probably post the algorithm you are asking to implement.

I can tell you, though, that you won't be able to do feedback FM by modulating the frequency input of [osc~]. You have to do the phase modulation version of FM to do feedback. The reason is that if you feedback modulate the frequency value with a modulation index above 1, you are inevitably going to have a frequency of 0, which will stop the oscillator permanently. However, if you modulate the phase of a [phasor~] that reads a [cos~], the [phasor~] will never stop. Take a look at E08.phase.mod.pd, which is just a PM version of FM.

The other caveat is that you need to have a [block~ 1] to ensure that the feedback is accurate.

Just a heads up, I'm currently working on a FM tutorial that will cover all of this...

If you're doing phase modulation like the DX7, too much feedback will make a little oscillatory burst each period. You can reduce this by low pass filtering the feedback path with a simple moving average filter.

This was described in an old Yamaha patent, but I think it never appeared in any synth.

Thank you Maelstrom, yes that book is huuuuuuge sorry for not posting the algorithm before, here it is. I scanned it from the book since my attempts at reproducing it in pd are still completely useless...

Now that you mention the DX7 acrell, my intention is that once i understand how to build this basic feedback fm algorithm i could probably evolv that idea and start recreating the algorithms from the DX7 in a pd patch.

http://www.pdpatchrepo.info/hurleur/feedbackfm.JPG

Oh, I was actually a little bit wrong about filtering the feedback path. It is filtered in the DX7, as in y(t) = 0.5(x(t)+x(t-1)). But you could probably filter it more to permit stronger feedback without oscillation. A lot of different variants are covered in some of the patents.

There are also more ambitious things you can do than straightforward FM. See some of the asymmetric FM stuff here: https://ccrma.stanford.edu/software/snd/snd/fm.html

Hello!

Thanks acreil, ive used the straightforward FM technique before and i wanted to try something different this time just to be able to go through the Computer Music Tutorial Book.

I asked the same question on a different forum and someone finally could solve the problem of feeding the signal back without getting a "dsp loop error", so i came up with a version of the basic ffm algorithm picture that i attached earlier but im not so sure its FFM... what do you think...

http://www.pdpatchrepo.info/hurleur/FFM.pd

OK i added a filter stage before returning the signal and it seems to be doing the trick like you suggested....

http://www.pdpatchrepo.info/hurleur/FFM.pd

This is how I'd do it, and I think the way Yamaha implemented it (except they use a single gain control for both the output and feedback; it's less flexible).

http://www.pdpatchrepo.info/hurleur/fb_fm_test.pd

Your way sounds so much better, im not sure what fexpr and table is doing in your patch... Im starting to notice the math might be beyond my comprehension for what i want to do but im still going to take a chance and ask... would you be so kind to break it down for me?

The first thing is that PD ordinarily processes blocks of 64 samples, because it's faster that way. That means a feedback loop using [send~] and [return~] has a 64 sample delay, which you don't want in this case. So I'm making a subpatch and setting the block size to 1 with [block~ 1 1 1]. [send~] and [return~] only work with a block size of 64, so I'm using [tabsend~] and [tabreceive~] instead. You need to do this any time you're making a feedback loop with less than 64 samples delay.

[fexpr~] is just the loop filter, y[t] = 0.5(x[t]+x[t-1]), as I said previously.

So the end result is this:

y[t] = cos(2*pi*f*t + 0.5*g[t]*(y[t-1]+y[t-2]))

2*pi*f*t is just the [phasor~] input and g[t] is the feedback coefficient. That's really it; the math isn't that hard.

@acreil said:

[fexpr~] is just the loop filter, y[t] = 0.5(x[t]+x[t-1]), as I said previously.

[fexpr~] is known to be quite computationally expensive. To avoid using it, you could do it this way:

[rzero~ -1]
|
[*~ .5]

(Disclaimer: I haven't actually compared the two.)

By the way, acreil, why would it create a burst if the feedback is too high? I haven't heard about this before. Could you link the patent?

Here's the patent (4249447): http://www.google.com/patents?id=IeA3AAAAEBAJ&printsec=frontcover&dq=4249447&hl=en&sa=X&ei=7vK4T_m5LKOH6QHH2pTsCg&ved=0CDUQ6AEwAA

Fig. 7 shows the oscillatory burst and Fig. 8 shows the filter. There's some explanation in the text.

I used [fexpr~] because I was hoping that other types of filters would produce better results. But everything I've tried ends up being worse. I was hoping to use something that has a null at Fs/2 and Fs/4, but it doesn't seem to work any better. It's probably better to just oversample so that all of the oscillatory stuff is outside the audible range.

Oh, also note that the feedback coefficients in the patent would be in radians, so they should be 2*pi larger than in my PD patch, since [cos~] includes the 2*pi.

Thanks!

Thank you acreil, that makes complete sense now.

The main problem i had was understanding what [fexpr~] was doing, since i couldnt understand why would you put a mathematical expression as a filter. But i made a little research and found this paper called "a general filter design language with real-time parameter control in pd, max/msp, and jmax" (anyone can google it and download the pdf) and it explains the family of [expr] objects, and now it all makes complete sense. And as i suspected i do need a little bit more math...

Thanks again!

Howdy, I'm trying to understand and recreate in Pd how the Feedback modulation works in FM8 (from NI) and how it really is the same as in DX7. I'm actually also using SuperCollider, which provides a self modulating oscillator (SinOscFB), but it just burst and blows up in noise way before the FM8 does with the same modulation index. I've made an equivalent patch in Pd for SinOscFB. Now, I know that in Supercollider there is no filter in the feedback, and I was checking the patents where they described the usage of a mean filter in the feedback loop.

I tried the mean filter in the feedback loop, but it doesn't really sound closer to FM8's self modulating oscillator. FM8 is supposed to be a kind of perfect clone to DX7. I don't have a DX7, but I have FM8, so I'm using it as a guide to recreate DX7 patches in Pd.

So yeah, basically, the mean filter didn't seem to work and I wonder if anyone could help me out here

thanks

@porres Hi did you get anywhere with this? Im doing a similar project atm with fm8. I have managed to get what i think is very close to the modulation index (although my tests show it to be slightly different from what i have been able to achieve - see my screenshots on this thread: https://forum.pdpatchrepo.info/topic/12453/phase-modulation-fm8-emulation-troubles/5) I dont need what im making to be exact but id like to be able to reverse engineer some of my favourite patches in fm8 in pd.

I am now looking to implement feedback and was wondering what the best way to implement this was, i also saw this post
https://forum.pdpatchrepo.info/topic/10864/fm-feedback-hack
and was wondering if you'd come across it too and if you can offer any advice from your experiences ? Cheers

thanks
R

@RandLaneFly Your pet subject has had people scratching their heads for a long time now..... https://cycling74.com/forums/dx7-problem-feedback-generator
They discussed a duplicate modulator at the time.
And also a subpatch at blocksize 1 write/reading an array with [tabsend~] and [tabread~]
It does seem likely that once your modulator has calculated its values for a 64 block and fed them back the delay will cause additional complex modulation that is maybe what you see in your FM8 waveform and not in that from the DX7.
Were your spectra all sourced in the digital domain or was there some analogue involved? Some of it looks like analogue noise and some like digital clipping.
David.

@whale-av hi thanks for your reply. To clarify, i havent actually attempted any feedback in those screenshots of the spectrums - i was purely testing mod index formulas. All screenshots apart from the FM8 one are from pure data, using the formulas given to calculate mod index from various sources, so it's all in the digital domain.

I dont actually know if the formulas are 100% correct but they seem pretty close comparing with fm8. I'm a bit in the dark about the whole 64 block issue so i will need to do a bit of research into that.
Cheers

R

The feedback algorithm posted acreil is great when the filter is changed from the fexpr~ to maelstrom's
[rzero~ -1]
|
[*~ .5]

but what i've found as regards to sound quality is a [ lop~ 1000 ] works great too. I've spent alot of time with dsp but filters have always baffled me. so im not really sure whats going on there in theory, but i like the sound of the lop~ !!. anyway if you find this thread give the feedback with phase modulation a try it makes some amazing sounds.