Do all of the operators, internally, execute identically whether they are acting as a modulator or a carrier?

Each Operator include a Pitch and an EG (Envelope Generator). Those Operators that are Carriers can be heard, those Operators that are Modulators influence the tone/timbre of the Operator it is set to modify.

Don’t make it harder than it should be. If a Carrier has an immediate attack, but the Modulator has a slower attack, you can expect the sound to begin with one timbre and that timbre will change when the Modulator’s slower attack starts to influence the Carrier. (Changing their roles could be catastrophic to generating a sound).

If the Carrier has an envelope that continues to sound while the KeyOn is maintained (a sustain type EG), if a Modulator assigned to influence that Carrier, by contrast, has a very short, quick EG attack and sudden decay back to an Output Index of 0, a good deal shorter than its Carrier, this Modulator will contribute to the burst of energy that make the tone of the attack. It might contribute to the attack noise, only.

Therefore: If the Modulator’s Level returns to 0 before the Carrier’s Level returns to 0, you can assume the Modulator is focused on the timbre of the Attack portion of the resulting sound.

If the Modulator has a slower EG attack than the Carrier it is involved in influencing, then you can anticipate that the timbre will change over time if the KeyOn is maintained long enough for the Modulator to come into play.

So, no. Each Operator has its own EG that determines the Output Level of that single Operator. If you move that Op from a Modulator role to a Carrier role, the numbers that control its travel are the same but (so what) the role is now completely different, some of those settings may now exist serendipitously.

If you have a program with two Carriers each would have a sound envelope of its own. An instrument with a notorious double attack (like a harpsichord) would have at least two Carriers with EGs that have slightly different Attack EGs to create that double effect. So obviously they can have different envelopes.

If you offset the Attack using a parameter that is for the entire Part, then each Operator’s EG is offset, in turn. You have options to direct EG offsets to specific Operators and you can use different combination of functions to offset. Attack&Decay, Attack&Release, etc., etc. See the “Control Assign” Destinations.

My current assumption is that the output of an operator is the same no matter whether it is in a moderator position or a carrier position
and that the ONLY difference is that a moderator does NOT feed the tone generator whereas a carrier does.

Is that assumption correct?

All Operators (with Operator Level) feed the Tone Generator.
Carriers effect loudness
Modulators effect tone/timbre
Both feed the Tone Generator and both are manifest in the resulting sound.

The Modulator that in one (Algorithm) position is responsible for a percussive knock during attack, if suddenly changed to a Carrier would be radically different. It would bring its very short EG along with it and would not play the same role in the total resulting sound.

If you tune the Modulator’s pitch high compared to the pitch of the target Carrier, in order to make the click of a mallet strike, or tuned even higher to get the high pitched plink of a FenderRhodes Tine, that Modulator’s tuning and duration profile might be totally shocking when basking in the light of suddenly now being a Carrier…

Although all Operators receive the same KeyOn and Velocity information from the Keyboard, each can individually interpret that information. And each can do different things with that information.

In fact, you could say: It makes a profound difference if you change the Operator position from Modulator to Carrier (or vice versa)!!! Profound!

Extra Credit:
If you hit and hold a note, that note will follow the EG as you have programmed it.
If you hit and quit (let go of a note) before it completes the designed EG settings (Time/Level), realize that it is then that the EG is altered immediately at KeyOff.

An EG will jump from wherever it is (however far it has proceeded) to the Release Time programming (skipping the Time/Level settings in between).

If an envelope, when played and held, takes 20 seconds to complete (thru to Decay 2 Level), if you were to instead play a stacatto Note event, it will jump from wherever it is in its travel to the Release Time setting the moment the KeyOff message is received.

FM Programming

The op 3 is a modulator so it doesn't seem like it is really going to do much. Is it possible that op 3 and 4 really didn't contribute to the
Marimba sound on the DX7 and are essentially left over 'junk' that never got removed?

This is the heart of your inquiry. Operator 3 and 4 contribute to the Attack portion of the marimba. The mallet strike articulation.

Overview: There are two audio generating stacks here. Stacked above Op6 and Op8.
_Mute Op6
This lets you hear a very basis M:C stack (7:8) - this is the body of the sound without the clarity of the attack articulation. Yes it sounds marimba-like, but we need the other stack to add the definition of the mallet strikes and to enrich the tone.

The stack above Op6 gives us that definition.
Mute the Op8 stack and activate Op6

How to explore:
The Op8 Carrier can be Muted - this will allow us to concentrate on just the stack containing 3, 4, 5 and 6.

The M:C (7:8) stack is tuned 5.00 to 1.00
The M:C (5:6) branch is tuned 7.00 to 1.00

If you play just just Op 7:8 and Op 5:6 you have a decent marimba tone.

But without Op3 and Op4 modulating the 5:6 branch, you miss the articulation of the mallet strike.

Mute the Op8 stack
Mute Op5
This means only Op6 (Carrier) being Modulated by Op3 and Op4.

Toggle Operator 4 On and Off to hear its contribution.
If you are having trouble hearing Op3 contribution make the following changes to Op3 to exaggerate its influence on Op4.

With Op4 active:
_Raise Op3 Level = 99
_Lower the Velocity/Level influence to +0 (this way you don’t have to hit the key hard to get the response (the Velocity/Level setting being positive means Op3’s contribution was velocity dependent).
_Raise Op3 Attack Level and Decay1 Level slowly from 78 toward 99 and listen to the quality of the Attack change the higher you raise the Output (Modulation Index)… it has some extra (what FM programmers call) “stuff”… it ‘overdrives’ it to create noise that adds a ruff character to the attack transient. (It adds some fuzzy-ness, like a radio off the station slightly, noise, character…)

Op3 truly is adding detail to Op4 which is adding the mallet character to the marimba basic tone generated by Op5:Op6.

The programmer set it to 78 to reduce the overdriven quality.
And the total time this ‘noise’ exists is very short… it disappears almost immediately.
They also made it variable via velocity… more “stuff” the hard the key is struck.

Final word: nobody (and I mean, nobody) programs the Times and Levels of their Operators for how they will work when you change their positions (like you did from a Modulator to a Carrier). That’s not how it works (for most folks).

From a Modulator, where it was responsible for creating a very quick burst of percussive energy, to being a Carrier where its role now requires a completely different set of EG settings to make musical sense. Op3 switched to function as a Carrier ‘comes and goes’ extremely fast, rendering what other Operators (presumably also) now in other roles, to behave differently or not seem to behave at all. If Op3 which has an EG of a stick hit becomes a Carrier all sound must take place during the time Op3 is audible. Any sustaining EGs would be restricted by the Carrier’s duration. Adjust your expectations.

You are assuming the act of changing the Time/Level EG configuration from a Modulator to a Carrier — basically, making the envelope audible — is helpful in some way.

And it maybe helpful, initially, to think of all envelopes in terms, of shaping loudness, but if you actually know what to listen for, that exercise is completely unnecessary.

If you recognize that as a Modulator, the thing you want to listen for is how it influences and shapes the timbre change. When its EG settings differ from those of the target Operator, you can expect to hear that difference! (That’s what you want to train your ear to listen for).

In an AWM2 (sampled-based) engine, there are separate EGs for controlling Amplitude and for controlling Timbre/Tone … when programming the Time/Level movement of your Filter, you do so listening to its effect on the timbre… you don’t first create the envelope settings in the AEG to see (hear) how they sound. You know what you expect the Filter to do, and you become confident in going directly to it, adjusting it. To create an evolving sweep you would know to set the EG of the Filter differently from that of the AMP EG. You don’t make a template that mimics the Amp EG first, you work with the two features independently because you know (and believe) one is for loudness change, the other for timbre change.

Eventually, the FM-X definitions of Carrier shape (audible directly as loudness) and Modulator shape (acts like a Filter, shapes tone) become second nature, believable and meaningful… this is when copying the EG from a Modulator to a Carrier to help recognize its movement/function becomes (perhaps) less like a good thing to do.

You want to get to the point where you expect to hear a very quick transient simply by looking at the Time/Level graphic (like Op3), you should expect to hear a very quick transient and therefore something that changes in the stack it is in. Knowing what to expect when you adjust the parameters of a Modulator is the skill you want to hone. If starting out, making all envelopes nails you can approach hitting them with your hammer… but once you get an idea of how the EG settings work… you want to move directly to targeting exactly what you want to modify.

Op3 going to Op4 and switching Op4 temporarily to be a Carrier — not sure it gets you much, Op4 was developed to be modifier, not the carrier of the pitch.

You are assuming the act of changing the Time/Level EG configuration from a Modulator to a Carrier — basically, making the envelope audible — is helpful in some way.

EXACTLY spot on!

That is the ONLY reason I moved the op 3 modulator to a carrier position - so I could try to HEAR what it was doing and how long it took to do it. But for that to be even minimally useful (as you suggest it is) requires that it act 100% the same in shaping the signal and producing the output.

I haven't found a description anywhere on how to go about analyzing an existing algorithm-based sound so I am trying to find he best way to do a 'deep dive' and came up with:

1. examine each operator in a stack in isolation from the top down
2. then examine each pair of operators in a stack together from the top down
3. then examine an entire stack in isolation by muting the other carriers
4. then examine pairs of stacks to hear the influence each has on the overall sound

I'm sure that method has some 'gotchas' but I'm not aware of a better way to go about it.

but if you actually know what to listen for, that exercise is completely unnecessary.

LOL! That's the part I need the most work on - learning what to listen for. That is why I was trying to use the component-base approach I just outlined above.
Toggle Operator 4 On and Off to hear its contribution.

If you are having trouble hearing Op3 contribution make the following changes to Op3 to exaggerate its influence on Op4.

BINGO! Thanks for that - that is exactly my biggest issue - how to isolate/magnify the contribution a single component, or a pair/stack of components, are making. That 'how to explore' section is just what I was trying to figure out.

If you recognize that as a Modulator, the thing you want to listen for is how it influences and shapes the timbre change. When its EG settings differ from those of the target Operator, you can expect to hear that difference! (That’s what you want to train your ear to listen for).

Are you perhaps suggesting that all that is needed are steps 3 and 4 above? Take each stack one at a time?

The 'scary' part is that 'modulator feeding modulator' part since you can't hear what either one is actually doing. It's hard enough, when starting out, to tell what ONE modulator is doing without being able to hear it. But how does one go about figuring out what the result of a string of 2, 3 or 4 modulators is going to be? Especially given that they can all have different envelopes with different timings?

The other side of the coin, when you are designing a sound, what are the indicators that you need multiple carriers instead of one or multiple modulators in a stack instead of just one.
An instrument with a notorious double attack (like a harpsichord) would have at least two Carriers with

EGs that have slightly different Attack EGs to create that double effect

Is it safe to assume that your 40 years of experience was of some help in your reaching that conclusion?

Your copying of Operator 3 (a modulator) down into Operator 2 (a carrier) so you can hear it is a good idea

That is what I was hoping. To be clear I wasn't doing it as part of creating a new sound - only to try to hear what it was doing. And those extremely long attack and release times just seemed so out of place for a MARIMBA/mallet sound. Still seems to me the attack won't even have a change to get going if you don't hold the key down and I don't think mallet players do, or even can do, that.

and, yes, all Operators will be the same in terms of all time functions regardless of position in a algorithm and/or function as Modulator or Carrier.

But since this sound was ported from the DX7 it raises the questions of whether the level and time values on a Modx envelope are evaluated using the same/similar curves (linear, exponential, log) as on the DX7.

Whoever did the conversion (or created the tool to do the conversion) had to take that into account I presume. I'm thinking that the Release of 98 is just to make it large enough so that it never really releases rather than determine a 'correct' value like 54 versus 56.

However... 3 is modulating 4, and this combined Operator is then modulating Carrier 6.

Yes - so how you figure out what the 3-4 combination is doing if you don't know what 3 by itself and 4 by itself are doing. Which is why I was looking for a way to examine 3 and 4 individually. Useful or not that is why I took that approach.

would be isolating 3 and 4 as a solo experience, with 4 temporarily acting as a Carrier so you could hear exactly what it's doing before it modifies 6 via modulation.

I agree - and it would be nice if more front panel and touchscreen operations could be done using SysEx.

Right now I have to mute each operator one at a time. But if I could use SysEx I could create macros on my computer to automate doing that.

Another thing that will drive you nuts is that the attack times are VERY sensitively exponential/log based.

And are they the same on a Modx as they were on the DX7? That is what I was referring to above.

The conversion of some of those DX7 sounds must have had some challenges. The operator numbers in the algorithms are different even if the algorithm pattern is the same. That is one of the easier things to deal with.

Any value below about 32 is quite short, and they get MUCH longer past this, at an exponential rate that makes the middle values somewhere between about 33 and 44 and quite finicky in this range

Agreed - Sometimes a change of 10-15 won't even be noticeable. But in that really tight range, which can be different for different things, if you want to use a knob or sequence to modify the value you have to be careful not to change the value too much in either direction. I bet that has caused a few surprises.

Operator 3's behavior cannot be isolated unless feedback is not used. In alg 15, OP3 is the single operator that can have feedback applied and no other operator can do this.

Alg 1 and Alg 55 are the only ones with carriers that are allow feedback. So to support the entirety of what OP3 (alg 15) could possibly do, it would be necessary to switch to Alg1 or Alg 55 and use OP1 which is a carrier that also has feedback.

Feedback shouldn't have a huge impact in the timing of things - but will have an impact if looking at a spectrum analyzer.

I'm not addressing the merits of this approach - only practical limitations of using this approach.

The M:C (7:8) stack is tuned 5.00 to 1.00
The M:C (5:6) branch is tuned 7.00 to 1.00

We seem to have two different versions

7:8 is 3.00 to 0.50
5:6 is 5.00 to 0.50

_Raise Op3 Level = 99

It is 99 by default in my version

_Raise Op3 Attack Level and Decay1 Level slowly from 78 toward 99 and listen to the quality of the Attack change the higher you raise the Output (Modulation Index)

I don't hear any change.

If I lower only attack level I also don't hear any change until below 25 when there is an added 'bell' sound.

You said raise attack and decay1 from 78 to 99 to hear a change. But the test I did using op 3 as a carrier where it would make sound showed this:

If I copy op 3 to op 1 and then SOLO op 1 holding down a key it takes several seconds before I hear a sound and when the key is released the sound continues for quite some time.

That is why I ask if an operator worked differently as a carrier making a sound than as a moderator.

That attack of 78 meant it took several seconds before you could notice ANY change. And the release of 78 meant that any sound you did hear would last a VERY long time.

For a percussive strike a key isn't held down long enough for you to hear anything when op 3 is an op 1 carrier. So to have an effect in the Marimba sound an attack of 78 must be useful or why would it have been added?

So my 'test a modulator as a carrier' experiment only seems to have make things more confusing.

Operator 3's behavior cannot be isolated unless feedback is not used.
In alg 15, OP3 is the single operator that can have feedback applied and no other operator can do this.

Alg 15 has a feedback setting of 0 (0-7) and there is no OFF value available.

So to support the entirety of what OP3 (alg 15) could possibly do, it would be necessary to switch to Alg1 or Alg 55 and use OP1 which is a carrier that also has feedback.

Thanks for that. For this current issue the goal is understand what alg 15 is doing for the DX7 MARIMBA sound and feedback isn't used.

My biggest issue for this deep dive is trying to figure out the best way to know what each operator is actually contributing to the sound.

The first thought was to take each operator one at a time to see if I could tell what it was doing. So far, that isn't working out so well.

There must be SOME criteria that tell a sound designer that they need to add another modulator or another carrier to the mix.

There must be SOME criteria that tell a sound designer that they need to add another modulator or another carrier to the mix.

Synth Programming: Manny’s FM-Xpert

Source: DX7 Product Manual

Feedback is available in every algorithm.
Notice that every algorithm includes one FEEDBACK path. The feedback is usually "wrapped around" a single operator, with a few exceptions noted below. The feed-back returns a portion of the operators output back to an additional input on the same operator except in algorithms #4 & #6, where the feedback is returned to the top modulator on the "stack". In effect, the operator is modulating itself when feedback is used. While the feedback paths are part of every algorithm, feedback is not used in every voice; an editing function permits the amount of feedback to be set to any of 8 values from none (0) to a maximum (7).

Often, the only difference between two algorithms is the location of the feedback loop. This is true with algorithms #3 and #4, and with algorithms illustrated. If you were to switch between either of the two algorithms in a pair with the feedback level at 0, there would be no difference in the sound, whereas with the feedback at a higher setting, the sound could differ significantly.

Note that algorithm references above do not apply to MODX(+)/Montage. There's an equivalent but these are for the DX7.

Ignoring algorithms and at least for this parameter, the description should be accurate for MODX/Montage too.

Not spam

I don't see similar language in any of the Modx Docs.

I keep getting surprised to find better explanations of things in the older docs than in the newer ones. You almost have to review the old docs first in order to understand the newer stuff.

Sure hope the docs for the new Montage M have fleshed things out - at least for the new stuff being added.
Naturally you want them to spend their money to get the product right but some things just need better explanations.

Even if the same family there are some things you just can't assume. An example is the AEG, PEG and FEG parameters for level and time.

Do the same values mean the same thing and have the same effect on the Modx and current Montage? Maybe the timings for calculations are different because of bus or processor speed. If so that could affect the way various operators in an algorithm sync up with each other. Or rounding issues if one model uses a different math package or precision.

It doesn't take much to make a difference.

I've always said to review old docs to get a different spin on the same old thing. Lots of times the older docs are more descriptive or show more about the internals or just are worded in a way that makes more sense to some. It's like anything else - multiple references are good for learning/researching.

Since so many things are the same - you can look at Motif (and older) documentation to help understand the current gen.

The next gen will be highly leveraged so most if not all of the Montage/MODX parameters will map directly to the next gen. Little has changed in terms of this although with the possibility of increased resolution - some things may change.

All the way back in 1987 - thumbing through this doc you'll see a lot of the same DNA that's in today's synth.

https://www.polynominal.com/yamaha-tx16w/yamaha-tx16w-manual.pdf

And you'll also notice more details in terms of absolute frequencies, etc.

I'll usually go through older docs if I feel like the newer docs left something out. Doesn't necessarily have to be a synthesizer.