Hi, I have been working for a while on a 4 op FM synth, but eventually I noticed I saw not able to get some sounds I expected to get despite any setting I had tried. I know feedback is essential and I have that implemented with send and receives, as well as a block~ 1 setting. Still I seem to be missing something.

I attached a simplified test patch, with just one operator fed onto another, the modulator is capable of feedback and the carrier is sent to the dac. I looked around and this video:

Anyone have an idea of what I'm missing? I included a 2op test patch.

Thanks
fmtest.pd

@randal [phasor~] produces a conventional sawtooth waveform.
There are some help files for FM in the Pd doc folder 3.audio.examples and you can replace [osc~] with [phasor~] where appropriate.
But you should read on in that folder...... particularly J07 which shows how to avoid a "cheap sound" due to foldover with [phasor~]
David.

@randal I hacked up your patch a little so I could run it to see what was going on, in particular I removed the algorithm switch from the voice and just took signal from the carrier. Is this not the result you were looking for?

Note that both oscillators are at the same pitch, and I took care to start them at the same time so they'd be in the same phase. I also think you might have accidentally deleted the feedback path for the modulating oscillator. [edit: I see now that you didn't, but the feedback outlet is post amp attenuation, so there is very little feedback. Additionally, you are using s~/r~ which introduces a 64 sample delay--consider using the technique in my next post]

I only have a passing knowledge of FM, but it seems like you have to keep the modulation index (in your case, op2 amp) really low to get the results you're looking for. I don't know how the DX modulation indexes are scaled. Also, if you're evaluting your results in time domain (i.e. looking at the wave shape) I think the phase between the oscillators is important. Adjusting the tuning of the oscillators while they're running will shift their phase relative to each other.

Yeah, the saw is even sharper if you feedback the modulator. Who knew? (not me). Check out the modulation and feedback amounts. Also play with the phase relationship between modulator and carrier.
FMsaw~.pd

@jameslo I am about to dl and check it out now. One thing though, I think I did have the modulator as the feedback operator, it's a bit hard to see because the feedback goes through inlets and outlets in the operator subpatch (the top one), and then the send and receives are outside that subpatch. Edit, you saw that. Yes having it post-attenuation and post-adsr was a change I just made, but it wasn't better before when I had it coming straigt from cos~. The thing is you are suposed to be able to get a decent saw just with the modulator so I wonder if it's something about how I was using block~ or the way I had the feedback routed outside the patch..

The switch to get the direct signal from the modulator is because as that video was demonstrating you are supposed to be able to get a saw just from the modulator alone with feedback, and a better saw from the carrier. Either way my patch didn't sound right.. I will check your patch out,,

Edit2: Yours definitely creates a saw perfectly. I noticed you defined a feedback buffer specifically instead of just using sends and receives, I think that or maybe something about the subpatch structure I had was meesing up my block size? I will have to look when I have more time later,,

@randal What I don't get is why the modulator gets squeggy when the FM feedback is increased beyond a certain amount, I'm curious if it has to do with the 1 sample feedback delay. I asked my friend who has a modular system to run that experiment for me, we'll see. I was also curious whether the spectral content was the same even as the modulator phase changes, so I adapted a test from the E09 audio example, and it looks like the AC spectra keep their shape even as they trade energy with the DC component. That's interesting (to me).
FMsaw2.pd .

Here's a Random Source Serge NTO module @ 100% FM feedback:

In my patch, the output of the modulator looks like a rounder version of the output I showed earlier. I wonder why there's such a difference?

@jameslo I wonder if that's much different from DX-style fm. I know linear fm is technically possible with analog circuitry if it's designed to implement the equivalent of negative frequencies. I'd imagine it would have different results to lookup table FM. MY tx81z is at the bottom of a big box, so I can't test

The feedback routing I had was based on the poly setup of a 4op patch, I forget where I heard previously that send and receive was the right way to implement feedback, but I'm pretty sure that's the problem. What I don't understand is why s~ and r~ don't seam to be affected by block~, although i'm not sure. Was using an Array object as a buffer something you've seen for the purpose before?

@randal I gave away both my TX81z's to a composer sometime in the '90s and immediately felt better

In my experience, s~ and r~ simply won't accept any block size other than 64, here's me talking to myself about it. Using [tabsend~] and [tabreceive~] in a [block~ 1 1 1] subpatch/abstraction is the only way I know of that implements a 1 sample audio feedback, I'd love to know if there are other ways. But anyway, yes, I agree that that's the substantive difference between your patch and mine (other than that feedback attenuation issue). You are reblocking inside the modulator subpatch if I recall, where it doesn't affect the s~/r~ feedback path.

@jameslo delwrite~, delread~ is quite sufficient.

@solipp Oh wow, thanks! I checked it out and it looks like you still have to declare the block size to be 1, but then you don't have to bother with declaring the buffer. I was a little (very, very little) concerned that specifying the read delay would be fiddly, but it looks like you can ask for 0 ms and it will give you a delay of 1 block.

EDIT: [delread~ myDelay 0] is a bad idea. I just ran into an instance where PD sorted the corresponding write to occur before the read (through no effort on my part) and so this expression didn't give me the 1 sample feedback I was expecting. I'm gonna fall back to tabsend~/tabreceive~.