I understand the pitch to expose the enable/disable switches for every Part.  Right now the use case is primarily centered around programming.  

Just taking a (related) tangent here - to demonstrate I know where you're coming from: for the FM-X I suggested bringing back the OP1-8 enable/disable (ON/OFF) control.   This was a programming-facing suggestion to make FM-X "pull in" a feature that the DX7 had which made sense.  Allow for essentially "muting" any one or many operators without changing the level so when you turn off an operator, the level would stay as programmed such that when turning it back on the level would be preserved.  It's not a huge deal - today you just need to use level sliders to approximate this functionality - but it's incrementally better if, for programming, we could turn on/off operators.  Sort of similar to your suggestion (ignoring the integration with scenes).   This didn't make it very far.  Mostly because the general population has some difficulty visualizing things that help programming.  Not all - but many have problems knowing how to program the synth at any level so advocating for enhancements to the programming environment doesn't seem to get much traction.   This feature didn't make it.

Any time you link something to scenes - you have a chance to make this into something that can be used for more than a tool to better program and experiment.  My suggestion is perhaps think of some scenarios where this feature could be utilized to do something using scenes for realizing different sounds that couldn't be done otherwise.  In other words, to pitch this also as a sound design feature with examples.   I know anything added to scenes (no matter what it is) can be "exploited" - in a good way - to do interesting things.  

I'm strongly for adding more things to scenes.  I think there's other things I'd rather see added to scenes - but I'm not against anything in particular getting added.  My thought is that the goal should be that, eventually, every parameter has a place in the scene so that all parameters are able to be offset.  Including keyboard low/high note range, etc.  Including things that cause glitchy sounds or artifacts if you change them midstream.   Including things that may cause the arpeggios to go "crazy" (if that's going to happen).   Not saying there are artifacts in store here.   I think that along the way everything including controller enable/disable should have a home in scenes.

The initial goal is to find any 'low hanging fruit'  to let users take better advantage of (or to use in more ways) functionality that already exists.

I understand the pitch to expose the enable/disable switches for every Part.  Right now the use case is primarily centered around programming.  

Yes, and since those switches already exist it seems likely that the code is already designed to take their ON/OFF setting into account when executing.

As far as we can tell deleting a part does nothing more than set that parts 'Part Sw' to OFF. The data for that deleted part will live on forever until a new part is added in its place or until you use SysEx to turn the part switch to ON.

We consider exposing the switch itself to be the low hanging fruit. Allowing uses to alter the switch settings (and thus the part mix) in scene memory is what would take a development effort. And that effort would need to be evaluated/prioritized for its cost/benefit.

for the FM-X I suggested bringing back the OP1-8 enable/disable (ON/OFF) control.

There are no such operator (FM-X) /oscillator (AN-X) switches in the M models that we can find. If those were available in the DX7 there might have been some programming considerations that led to their demise. Turning a carrier OFF should be fairly straightforward. But turning off a particular modulator in a multi-modulator stack may have raised some issued.

Regardless the bias should be to let the user deal with the consequences of using the ON/OFF feature. As you have said there are often some hidden gems in doing things that hadn't been fully worked out in advance.

This was a programming-facing suggestion to make FM-X "pull in" a feature that the DX7 had which made sense.  Allow for essentially "muting" any one or many operators without changing the level so when you turn off an operator, the level would stay as programmed such that when turning it back on the level would be preserved.

At first blush that might be more appropriate for carriers than modulators but leave it up to the user to do it the way they want.

Another potential benefit is that an OFF could remove an operator from polyphony calculations.

Mostly because the general population has some difficulty visualizing things that help programming.

That is what peaked our curiosity with the sudden appearance of all of those switches that didn't exist before in the Data List. And the ones for AN-X filters (see new thread we created) don't appear to be complete as yet.

It gives credence to the idea that the development team is striving to make the internals more modular rather than have similar functionality hard-coded in different areas.

Not all - but many have problems knowing how to program the synth at any level so advocating for enhancements to the programming environment doesn't seem to get much traction.

That is the main reason to tag an idea as 'low hanging fruit' - something whose development is isolated/contained to a specific screen/module rather than having side effects all over the place.

Exposing an existing switch (forget the scene memory stuff for now) fits that - the switch exists, the code already takes the switch into account. All that is needed is a place on a UI screen to display the switch and code to toggle it. No possible 'leaks' into other areas of functionality and no possibility of breaking something that used to work.

Any time you link something to scenes - you have a chance to make this into something that can be used for more than a tool to better program and experiment.

True - but embodied in that is that the development/testing effort isn't trivial. New screens are needed. The data 'footprint' needs to be expanded. An expanded data footprint can affect latency issues with SSS or performance loading/transmitting and so on. 

My suggestion is perhaps think of some scenarios where this feature could be utilized to do something using scenes for realizing different sounds that couldn't be done otherwise.  In other words, to pitch this also as a sound design feature with examples.

That is the approach we tried to take with our recent idea #3193

https://yamahasynth.ideascale.com/c/yamahasynth/idea/184617

Montage M - Add dynamic 'Exchange Part' (e.g. swap parts 3 and 12) functionality to Scenes

The idea there is to be able to use parts 9-16, often totally unused, as a 'part warehouse' and use scenes to swap them in. That facilitates SSS without having to load an entire part into because parts 9-16 are already in memory - they just can't be used the same as parts 1-8 because they don't have keyboard control.

My thought is that the goal should be that, eventually, every parameter has a place in the scene so that all parameters are able to be offset.

Interesting that you say that. We aren't sure that many people know that is really what Smart Morph is doing under the covers.

Look at p.10 of the Montage Supplementary doc - it lists all of the FM-X parameters that are 'morphed'. There are 280 (8 sets of 35) parameters for the operators and another 69 for the common parms. Some 350 or so parms in all. 

The resulting 32x32 morph grid is, essentially, 1024 'scenes'. We have developed software for our own use that lets us program each of those grid cells in any manner we choose.

Only your finger, or the superknob can actually choose which cell to use at any given moment but a crude example would be if you imagine the morph grid to be a set of vertical/horizontal 'ribbons'. Swipe your finger from left to right (up to down) and you can switch to any of the 32 cells in that row/column and cause that cells 'scene' of parameters to be in play.

Morphing doesn't do 'offset'. It actually replaces the actual parameter value. You can see those values change in real-time if you load a Morph performance and start the super knob going. Then just migrate to the different screens and see the parms 'dance' in real time.