A related article to manage the lack of element control in scenes:

https://www.yamahasynth.com/ask-a-question/scenes-don-t-work-with-elements

A related article to manage the lack of element control in scenes:

https://www.yamahasynth.com/ask-a-question/scenes-don-t-work-with-elements

Thx, interesting! Yeah, that definitely doesn't help with what I am looking to do.
I'm looking to make better use our of each PART, not spread the Element waveforms out to different PARTs, nor spread volume control of Elements to various AssignKnobs. The only Assignable parameters that could possibly work to 'simulate' what I am proposing in my 'Idea' are Volumes of particular Elements to be assigned to different AssignKnobs, AssgnSwit's, etc. Which not only burns up Polyphony because even though I might have the Volume up on only 1 Element at a time (saving the AssignKnobs' position via Scenes), all the other elements are still playing & taking up Polyphony/processing (you just can't hear them), but it ties up numerous physical assign buttons/knobs for this single purpose. My ask it to 'gain' new functionality, flexibility & variety, not use existing functionality to simulate it at a great cost to resources.

I would think it would be much easier for Yamaha to engineer control of Elements' ON/OFF SW for a PART via 'Scenes', than to allow PARTs 9-16 to be KBD CTRL enabled..!? Because currently PARTs 9-16 are not even capable of KBD CTRL so it would be a Huge change to engineer, but a PART's Elements already have ON/OFF SW's, which could more easily be added as an Assignable Parameter &/or just have their state saved/changed per Scene.

@J — thanks for finding that thread. It does address what you can do now (it’s not my place to say if Element condition being stored in Scenes is possible) but the current firmware addresses Element activity - articulation control, morphing between active Elements, and linking the control via the control matrix to the Super Knob which can be memorized.

Weighed in any firmware change would be the usefulness. The XA CONTROL where you have several methods of changing active Elements via AsSwitches, key touch, or automated... you can change Elements using the morphing method (which is one of my personal favorites) as in the Brass Swells — which offers a solution to the issue of samples being able to change timbre in real-time under the musician’s Control.
Orchestral horns played with low breath pressure have a dramatically different timbre than when played mp, or mf, or f, or ff etc. that harmonic content change is accomplished by allowing the performer to morph smoothly through the different Elements... fading in and then out each to transition the sound. It’s not necessary to retrigger the Note-on, nor is it some kind of synthy filter opening (fine for synthy things but unsatisfying on orchestral brass — at least compared to morphing through various Element samples).

So in keeping with the theme of *what you can accomplish now* — Elements can be transitioned elegantly as part of ‘performing’ the instrument emulation. Other methods of Element Control also exist - morphing can include jumping to a certain condition... importantly you want these to be sonically invisible in most cases... or at least that should be a consideration. I certainly wouldn’t want an Element Mute snapshot to interrupt audio (if you see what I mean).

Extra Credit:
See article on Orchestral Brass Swell
This is the type of Element Control that is truly musically useful allowing a performing technique previously unavailable... you get to control the swell up and back to fit your music... quite an improvement over a pre-recorded swell (hope it fits).

... not spread the Element waveforms out to different PARTs

The link provided applies to applications where you "compress" elements into less PARTs than you started with (not "spreading out" - which implies using more PARTs).

Element levels, as controller matrix offsets, can be applied to any number of specific elements. And you can set the same source controller to "turn off" an element while simultaneously "turning on" another element. You can use a user curve such that you have 8 different combinations of "on/off" settings for each of the elements.

So you can set:
superknob=0-15 Element 1 (E1) OFF, E2=ON, E3=ON, E4=OFF, E5=OFF, E6=ON, E7=ON, E8=OFF
superknob=16-31 E1=ON, E2=ON, E3=ON, E4=ON, E5=OFF, E6=OFF, E7=OFF, E8=OFF
superknob=32-47 E1=OFF, E2=OFF, E3=OFF, E4=OFF, E5=ON, E6=OFF, E7=OFF, E8=OFF
... and so on to cover 8 different superknob ranges for different arbitrary element "on" "off" settings. Keep in mind, E1=OFF is just shorthand for Element 1 has the level turned all the way down due to element level offsets. And E2=ON is shorthand for Element 2 has the level set to the desired audible level due to element level offsets.

The goal isn't to have superknob as useful for manual control. It's only intended, in this usage, to be "driven" (turned, set) by the scene setting superknob to specific values. Use "step" curves instead of "linear" type so that specific values can be "dialed in" for each range. In order to get all of the combinations, you would use multiple destinations (8 of them) in the above example. Each element would have a single "ON" switch in the control matrix with the rest off. This "Element Sw" doesn't mean the element itself is on or off. It means the element will be offset by the user curve (Elem SW=ON) or not (Elem SW=OFF).

It's not elegant. It's not a walk in the park. But you can, I believe, accomplish what you're asking for in the original request by consuming destination resources and also "taking over" superknob so it must be dedicated to this feature. As long as those two constraints are OK - then you have the facility, through a lot of programming, to accomplish your initial goal.

I'm not dumping on your idea. I'm only presenting that there is a way to arrive at the outcome you're requesting by doing a lot of work and living with the resources consumed.

The benefit of your idea is that superknob will not be "tied up" for this feature and also it would be easier to program.

I'm not going to get into what's easier or harder to do for the engineers. That's for them to decide. Regardless of how many lines of code it takes or how many hours it takes to complete the feature - there is also the consideration that if 10 users ask for one feature (an "easy" one) and 100,000 ask for another (a "harder" one) - the "easy" one may not make it past go due to losing the "need" evaluation. Ideascale was the right route to take - so we'll see how that goes. There's a lot of competing ideas for scene improvements. Scenes are certainly a powerful tool and the buttons are more worn out on my keyboard than nearly any other controller (that's the colorful way of saying I use them a lot).

I'd like to see maybe 16 user parameters (maybe 8 of the non-element type where there's only 1 parameter affected at a time and 8 element type where element switches are supported) - or just flexible to adapt to the different types if that's just as "easy". And these user parameters can be anything - including what's not in the controller matrix destinations. A way of expanding destinations to cover something custom any user wants - but doesn't grow the size of destinations possibilities to cover everything (at once). 16 user items is still finite. And the same system used for scenes where there's a "user" memory tab that can include either these 16 same parameters - or a 2nd set of scene specific user parameters.

Circling back to the element on/off through scenes by levering superknob: unfortunately, I cannot send a Soundmondo example of what I outlined above. This is because user curves are not supported by Soundmondo and this is one of those times where user curves is heavily leveraged. That's part of the "hard part" of this suggestion and it may be nice to see a concrete example of how this looks.

The solution would be to save an X7L file with a single Performance as this should bring in the user curves. Let me know if this would be of any value since it would take a while to show a larger example. There are 32 maximum user curves so this supports 4 PARTs fully stacked and fully controlled. Less needed if individual elements can be grouped together. Like PART 1 elements 1-4 should always be "ON" or "OFF" together. I would only demonstrate 2 PARTs. This is enough to show the technique. You still only have 8 scene buttons - so there are only that many states that can be achieved - which is a similar constraint in your original idea as well.

It's not elegant. It's not a walk in the park. But you can, I believe, accomplish what you're asking for in the original request by consuming destination resources and also "taking over" superknob so it must be dedicated to this feature. As long as those two constraints are OK - then you have the facility, through a lot of programming, to accomplish your initial goal.

Taking over the SuperKnob is kind of a deal breaker. This method would hinder doing other things that involve using the SuperKnob.

Keep in mind, E1=OFF is just shorthand for Element 1 has the level turned all the way down due to element level offsets. And E2=ON is shorthand for Element 2 has the level set to the desired audible level due to element level offsets.

Also, if I am understanding correctly, this doesn't actually turn the Elements' ON/OFF SW (Green button on the screen), it just adjusts the Volumes of each Element, correct!?
If so, that is the other big deal breaker, because all 8 Element waveforms will be using up Polyphony...

Right, elements are not turned off. As the section you quoted mentions. E#=OFF is shorthand for the element's level is at zero.

And, as you mention, there is an implication to polyphony. So this is not going to play nice with polyphony. I didn't list that as a limitation because, frankly, I wasn't thinking about polyphony at the time. But that's a true and big limitation of the system today. At the element level we only have XA control as a means to stop notes from triggering.

Superknob can be managed by using "common/audio" level assignable knobs. Something mentioned in the link provided.