Hello,
I'd like to share this patch for a 4-voice, 3-operator synth which is based on the phase modulation type of FM. It features 9 types of waveforms (similar to those found on old fm synths), 4-stage envelopes (level/time, even though the labels say "rate") and has a modulation matrix including feedback.

A while ago I came across this patch for doing accurate FM feedback, which sounds a lot better then doing it with [s~] and [r~] https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm/7

However, when using it in conjunction with a second (or third) modulator, it sounds rather bad unless the modulator is also working at block~ 1, and I wanted to find a way to do it which allowed to change algorithm without re-patching the whole thing. I'm not sure if the way I've done it here is overkill or just nonsense, but it sounds ok to me and allows for the three oscillators to modulate each other (kind of how the FM8 matrix works, I think).

It works in pd vanilla 0.47-1. A lot of the stuff that’s in it was taken from this forum so thanks everyone for your inputs.

PM-3 v1.0.zip

Any feedback is more than welcome! (no pun intended)

@djpersonalspace Hi, the main mod matrix is inside [pd DSP], then click on the [clone] object, [PMops $1] and then [tables $0]. This is an abstraction file (tables.pd) that receives the phases for all operators, so they can be updated with a 1 sample precision. This abstraction is inside the [clone] object, so of course each voice of the synth uses a different instance of the tables abstraction.

I settled on 4 voices and 3 operators because anything more than that seems too heavy on my cpu, but if you follow the same principle you can keep adding tabsends, tabreceives and tables for the new operators to the abstraction. If you need more voices, just change the number 4 in the [clone] and [poly] objects inside [pd DSP].

Hope this helps, it's been a while since I made this and I remember that this method of doing the modulation matrix wasn't intuitive to me either at the time.

Awesome, that's great. I will have a look and see if I can figure it out. I'm a bit of a noob to both PD and FM synthisers to be honest but I felt like the best way to find out how they work is to try and make one haha. So here is the patch I have started if you want to take a look, no worries if not. It is very simple so far and basically I have the operators running in a sub patch, and both directly modulating a carrier. I wasnt sure if there was some kind of magic with sends and the $ signs I could have done to make them all able to modulate each other..

Like I say im a total noob so all new to me. Keen to learn though! Thanks for your help and I will check out what you mentioned.

Thanks again

fm experimenting_3.pd

@djpersonalspace Thanks for sharing the patch you're working on. I should point out that your patch uses "real" FM, which means that you directly modulate the frequency of an osc~, whereas my patch (like most implementations of FM) uses what is called "phase modulation", where you modulate the phase lookup of a sine wave instead. This is a key difference to understand if you are trying to implement multi-operator FM.
For the basics on this, have a look at help > browser > pure data > 3.audio.examples > E08.phase.mod.pd

This is what my mod matrix is doing in the patch, there is one table which holds the phase of each operator, and every time some other operator is sent to modulate it by some amount (aka the modulation index), the output of this modulator is added to the table along with all the others that are set to modulate it. I think that once you understand the difference between FM and PM this becomes clearer.

You could do all this in a simpler way with s~, r~, throw~ and catch~. The reason I'm doing all this madness with tables here is because I wanted to have feedback as well for each operator, and in order to do so the phases need to be updated sample by sample, whereas s~ and r~ objects only work in chunks of 64 samples. That doesn't sound right when you try it.

I did think that might have been the case. I am out of my depth with this stuff, but I saw you mentioned phase above and I had heard before that the DX7 by Yamaha, for example, uses phase modulation synthesis so I figured that might have been the case. I know nothing about it, however, so will need to do some research there. Thanks so much for sharing your patch though and for the help you have provided. Am I right in saying that the FM8 by Native Instruments uses phase modulation synthesis then, as opposed to "real FM" ? And also that you can only make the operators feedback into themselves if you use PM?

@djpersonalspace Yes, you are right FM8 used phase modulation. And yes, I'm pretty sure feedback is only possible in PM and not FM, either way it's definitely the way to go if you are using multiple operators and non-fixed algorithms.

You are welcome, I hope you can get something out of this patch. I think this way of doing phase modulation is the best sounding I've heard, but it's very cpu heavy.

Hi great patch, this is way over my knowledge. I'm trying to dissect your patch on PMop.pd and tables.pd to use tabreceive and tabsend with phase modulation,
my catch and try solution is working bad when i start to create several routing algorithms https://forum.pdpatchrepo.info/topic/12256/fm-routing-algorithms
Do you have a more simpler version to at least learn the inner working of two oscillators with phase modulation with tables?
Thanks

@zxcvbs Hi, yes I realise the patch is very counterintuitive, I'll do my best to try and explain what's going on. Let's forget about polyphony and consider one voice.
The PMops abstraction is the single voice, inside it are the three operators (PMop, both badly named sorry) and the tables subpatch. The basic structure of each operator could be reduced to the simple:

but the +~ object, instead of receiving the phase from a fixed modulator, it receives it from a table. Each operator has its own table, so operator 1 receives the phase from tabreceive~ $0-phase1 which is connected to +~.
At the same time (to populate those tables), the output from cos~ of each operator is sent to all tables, how much of the signal goes to each is decided in the modulation matrix.
The reason I decided for this arrangement is because this way each operator can send its phase to any operator, including itself (feedback). As explained in the first post, feedback has to be done with the operator working at block~ 1 in order to sound good, but if an operator receives the feedback every sample (block~ 1) but to that you add the phase of the other modulators every 64 samples (the default block size), the result sounds bad. This is the reason I used this mess of tables, to have an FM-8 style modulation matrix.
If you want to implement hard-coded algorithms, the same thing can be done without tables, patching each algorithm in its own abstraction or subpatch and switch between them as @whale-av suggested in your thread. Plus I see none of your algorithms have feedback, so they don't even need to run at block~ 1, and therefore the approach with tables is really not necessary.
Hope this clarifies things a bit.

@weightless said:

atch is very counterintuitive, I'll do my best to try and explain what's going on. Let's forget about polyphony and consider one voice.
The PMops abstraction is the single voice, inside it are the three operators (PMop, both badly named sorry) and the tables subpatch. The basic st

hi, i really thank you for the help i'm working on that fm project will expand on this, when i finish that patch. Do you have any resources to learn about fft, block, window, oversampling manipulation, be it with pure data or other sound design programming tools, so i can transfer that knowledge? the manuals i saw, are great but doesn't expand that deeper.

@weightless Hey great patch, this seems to be the only solution i can find to be able to do feedback for phase modulation, which is what im trying to achieve at the moment. Really awesome work! Thanks for explaining all that too, really helps to understand. I understand the concept behind the method but Im having a bit of trouble wrapping my head round the maths and the code. Just wondering if I could ask a few questions

I can follow the process from the note past where the ratio is set, then there's offset, I take it that's like the offset in fm8, given in hz? Also, why use clip in these situations? Then I notice you use an object called pphasor instead of phasor, but it has no help patch I assume this is from an external? Ive installed a bunch but i am not sure which this is from, does this negate the need for a cos~ object? Im a bit lost for the next little bit regarding the wrap_ and *~ and the tabread4~ to be honest.
But I take it after that it's sending out the phases to the tables, what is the purpose of the line being formed and sent into the right inlet?
If you could give me any info that would be great, I understand ive asked a lot of questions though! The maths at the table patch is over my head also, are there any resources you can recommend to learn more about this kind of stuff?

Thanks
R

@RandLaneFly Hi, I'll do my best to give you some replies:

• yes, offset just adds a fixed frequency in hertz regardless of the ratio or the note played. It's useful if you want to use an operator as an LFO;
• I used clip because the patch can receive values from external messages from the parent patch, the clip avoids unwanted values whatever you send to it. It's got to do with the GUI of the patch rather than with the synth itself;
• here is pphasor~.pd, it's just a phasor with sample accurate phase reset to be able to sync the operators accurately. I adapted it from some old patch I found, but I can't remember what I've changed to be honest. It only replaces phasor~ so you'd still need cos~ afterwards;
• about wrap~ and cos~: in a normal situation, where you do phase modulation with phasor and cos~, you don't need wrap~ because cos~ already wraps whatever phase it receives, even if it's outside the 0..1 range. In this case, instead of cos~, I used a table to store the waveform. Two reasons for this: 1) I wanted to be able to change the resolution of the sine and 2) I wanted to be able to use other waveforms other than a sine wave. Having said that, if your phase (after being scrambled around by all the modulators acting on it) has to address a table, you need it to be within the range of that table, otherwise you would be addressing points that are outside of the table (which would result in silence). This is why the phase is wrap~ped to the 0..1 range, and then multiplied by the length of the table in samples (4096 in this case);
• I don't understand what you mean by:

@RandLaneFly said:

But I take it after that it's sending out the phases to the tables, what is the purpose of the line being formed and sent into the right inlet?

The tabread4~ object is your output waveform for this specific operator you're looking at. Afterwards it's multiplied by the envelope (received on the right inlet of the *~ object), and then it's sent to the output (aka, what you hear) and to the phase tables.

• If by "the math in the table patch" you mean the fexpr~ object, that is exactly the same as found in the thread I mentioned in the first post. It averages the last two samples in order to filter very high, harsh frequencies in the feedback path. It's possible that FM8 uses a different filter, which would result in a different sound, but I have no way of knowing that.

I'm afraid the only resource I used for making this mess of a patch was that single thread about feedback, and then I expanded it for multiple operators. I very much like how it sounds, but it's incredibly expansive with polyphony, and on my computer 3 operators seem to be the limit, I wanted to try six but could never manage.