ANDREW: I'm not sure your workarounds to things you've presumed, on the basis of that which you're not sure of, aren't just solutions to straw men of your own making for reasons that I'm not sure about.

Am I incorrect in assuming that your goal (in being able to switch elements in and out via scenes) would be to better facilitate combining X sounds within Y amount of polyphony? That was the impression I got from the paragraphs of yours that I quoted, which both dealt with polypyhony. If I misunderstood, and you weren't postulating a way to provide more efficient use of polyphony, please clarify what it is you're trying to accomplish, what problem switching elements via scenes would solve for you (which should have been so obvious to a product manager!).

If I'm right, though, and I did accurately summarize what you were asking for in that post, then my suggestion of a "better (simpler and more flexible) way to accomplish" that goal isn't a "workaround," it is the basic way the board already

You're not right, and it's not right to attempt to resolve to a single goal for something this generically empowering. As Jason pointed out, there's several very good reasons, just logically, for providing Scene saving of "Oscillator" state when each "Oscillator" is contributing to polyphony usage.

And he's only touched the tip of that logical iceberg.

Rather than waste time reasoning out more obvious logics, consider that there's also 8x8x8 creative justifications to provide this facility, which both Darryl and Fernando have been somewhat explicit about, in varying contexts.

Further, it's also so obviously the right empowerment choice for creative freedom in a polyphonically restricted environment, at the point of polyphony count-up, that I don't understand why you'd attempt to find a single goal as a rationalisation for arguing against something that's otherwise so incredibly reasonable, and inherently flush with self evidently logical reasons to provide it.

As I say, any Product Manager would have it at the top of their list of things to provide end users, just on its reasoned merits, before we get to the creative ones.

ANDREW: You're not right, and it's not right to attempt to resolve to a single goal for something this generically empowering. As Jason pointed out, there's several very good reasons, just logically, for providing Scene saving of "Oscillator" state when each "Oscillator" is contributing to polyphony usage.

And he's only touched the tip of that logical iceberg.

Rather than waste time reasoning out more obvious logics, consider that there's also 8x8x8 creative justifications to provide this facility, which both Darryl and Fernando have been somewhat explicit about, in varying contexts.

Further, it's also so obviously the right empowerment choice for creative freedom in a polyphonically restricted environment, at the point of polyphony count-up, that I don't understand why you'd attempt to find a single goal as a rationalisation for arguing against something that's otherwise so incredibly reasonable, and inherently flush with self evidently logical reasons to provide it.

As I say, any Product Manager would have it at the top of their list of things to provide end users, just on its reasoned merits, before we get to the creative ones.

Sorry, I still don't get it. I understand there could be situations whete it could be useful to store element on/off state in scenes, I already said so in post #38 (sorted oldest to newest). But your post #32 (which I was responding to) was all about how important this would be for polyphony (which you've touched on again in this latest post), that's the part I'm not seeing.

ANDREW: You're not right, and it's not right to attempt to resolve to a single goal for something this generically empowering. As Jason pointed out, there's several very good reasons, just logically, for providing Scene saving of "Oscillator" state when each "Oscillator" is contributing to polyphony usage.

And he's only touched the tip of that logical iceberg.

Rather than waste time reasoning out more obvious logics, consider that there's also 8x8x8 creative justifications to provide this facility, which both Darryl and Fernando have been somewhat explicit about, in varying contexts.

Further, it's also so obviously the right empowerment choice for creative freedom in a polyphonically restricted environment, at the point of polyphony count-up, that I don't understand why you'd attempt to find a single goal as a rationalisation for arguing against something that's otherwise so incredibly reasonable, and inherently flush with self evidently logical reasons to provide it.

As I say, any Product Manager would have it at the top of their list of things to provide end users, just on its reasoned merits, before we get to the creative ones.

Sorry, I still don't get it. I understand there could be situations whete it could be useful to store element on/off state in scenes, I already said so in post #38 (sorted oldest to newest). But your post #32 (which I was responding to) was all about how important this would be for polyphony (which you've touched on again in this latest post), that's the part I'm not seeing.

Don't just read what I've written, read what Jason's written, carefully. He's succinct, but nailed 3 very good reasons that are just some of about a dozen good answers to your question.

And there's no UNDO!???

DARRYL - the democrat, said:
There's a great idea. Add that one to Ideascale and I'll be the first to Up Vote it for you!
You get enough votes and traction on that one, and with people from the Voicing team being on this forum, they may just push something like that high up on the list for future features...

Not even Chomsky shares your degree of religious devotion to democratic ideals.

I think there's been some requests for clarifications - and I had a long detailed response that I erased. Rather than chase that rabbit - I think if there's any topic someone wants to explore maybe open up a new thread on that topic. This one reads like a daytime soap (at times) and I'd more enjoy taking deeper dives without as much drama. I usually follow tangents - but tangents still touch the circumference.

I think there's been some requests for clarifications - and I had a long detailed response that I erased. Rather than chase that rabbit - I think if there's any topic someone wants to explore maybe open up a new thread on that topic. This one reads like a daytime soap (at times) and I'd more enjoy taking deeper dives without as much drama. I usually follow tangents - but tangents still touch the circumference.

Here's your (conservatively) three good reasonings highlighted. I might make the case that this is more than that.

"For me this isn't so much about polyphony. It's about the limited resource of 8 Parts.

Certainly I am aware of the "ball and chain" of parameters that connect from the Part common level to elements - what you lose by moving an element from its own Part into some Part to "share" space with other elements. Insertion effects is one thing - but there's plenty of other items. Still, I have situations where (my) programming choices would be facilitated by stuffing elements into Parts shared with other elements and have a way to switch these stuffed elements in/out so I end up with more than 8 Parts under keyboard control.

Doubling the amount of Parts available to keyboard control (another request) would be an "easier" way to get to the same place for me. Programming would be simplified. I don't know if there are other constraints that make this request fall flat.

And - although one can use level to "mute" elements - this is where the polyphony problem comes in because volume/level reduced elements pile onto the polyphony count unnecessarily if the goal is to have random access to switching some elements on/off.

The assignable switches don't work because for XA control and using the local control surface we have two buttons that peanut-butter spread across all Parts and not sufficient states of these buttons to accomplish the task in most cases."

JASON: I think there's been some requests for clarifications - and I had a long detailed response that I erased. Rather than chase that rabbit - I think if there's any topic someone wants to explore maybe open up a new thread on that topic. This one reads like a daytime soap (at times) and I'd more enjoy taking deeper dives without as much drama. I usually follow tangents - but tangents still touch the circumference.

There were two questions I had in my reply to you, but I'm conflicted about opening up new threads... admittedly, we're under an irrelevant subject line here, but at least the people currently involved in this sub-topic are already following it. But if you care to briefly address those two questions (whether here, or if you choose to start a new thread on the topic, at your discretion), they were basically this:

1. I understand that you like the idea of scene-based element switching in order to have more than 8 Parts' worth of simultaneously available/selectable different sounds within a performance, as a substitute for not being able to put more than 8 Parts under keyboard control. My question was, considering the limitations of this approach (as you said, " Insertion effects is one thing - but there's plenty of other items" ), isn't the MIDI loopback approach generally going to be a less restrictive way to accomplish the same goal? It still has limitations, but I think less so compared to all the limitations of this theoretical scene-based element switching.

Which isn't to say I can't see ANY reason for the latter... for example, you might actually want all the 9-16 Parts available to be driven externally, in which case they would simply not be available for the loopback approach. Or you might want a total of even more than 16 selectable sounds in your Performance, and the loopback approach only gets you to 16. Or you might already be using the Zone Master function to address sounds that are actually truly external to the unit, making that function unavailable for loopback. But assuming that loopback IS an option for you, wouldn't that generally be a better (meaning fewer limitations) way to get 9 to 16 keyboard-controllable sounds than scene switching of elements would be?

2. You seemed to be saying that using the AF Buttons to activate elements within parts in order to put a 9th (or 9th and 10th) sound under keyboard control generally won't work (where you said, "the assignable switches don't work because for XA control and using the local control surface we have two buttons that peanut-butter spread across all Parts and not sufficient states of these buttons to accomplish the task in most cases" ) but I'm not understanding why that won't work, assuming you don't need those buttons for something else. (And subsequently, Darryl seemed to say that he thought this actually could work for what he's trying to do... again, in situations where he didn't need the AF buttons for something else.)

ANDREW:Here's {Jason's} (conservatively) three good reasonings highlighted. I might make the case that this is more than that.

"For me this isn't so much about polyphony. It's about the limited resource of 8 Parts.

And you can see in my reply to that post that I agreed with him. My disagreement with your earlier post was the same as my agreement with Jason's... that is, it's not really about polyphony.

Again, I've never said that element switching in scenes would be useless. I only took issue with your post #32 that made it all about polyphony, when it looked to me like it was hardly about polyphony at all.

ANDREW {quoting Jason): And - although one can use level to "mute" elements - this is where the polyphony problem comes in because volume/level reduced elements pile onto the polyphony count unnecessarily if the goal is to have random access to switching some elements on/off.

Finally, polyphony! 😉 And I addressed this in my response to that comment.

ANDREW {quoting Jason):The assignable switches don't work because for XA control and using the local control surface we have two buttons that peanut-butter spread across all Parts and not sufficient states of these buttons to accomplish the task in most cases."

This is what I'm asking about in question 2 above, since it looks to me (and apparently Darryl) that this is indeed yet another solution for going beyond what would otherwise be 8 Parts' worth of sounds, if you only need access to one or two more sounds... and it would be yet another way of doing it without non-sounding parts using up any polyphony.

AnotherScott,

Your whole posit seems to be that there's some kind of limitation that comes about from enabling Scene based state switching of Elements.

This simply isn't the case.

It is a massive empowerment feature, that has (quite literally) exponential potential to increase creative options, without incurring any limitations, of any sort.

Your whole posit seems to be that there's some kind of limitation that comes about from enabling Scene based state switching of Elements.

No no no! There is no limitation that would arise from enabling Element switching in Scenes. (We're talking about only adding functionality, not removing any!) The limitations I've been referring to arise from using Elements as substitutes for additional Parts in the first place. And again, I'm not saying one should never do it, I'm saying there are significant limitations, compared to having sounds in their own Parts. As Jason said, "Insertion effects is one thing - but there's plenty of other items" too.

My specific posts to you have been about your comments about polyphony. But as for the concept in general, as I said, I do see where it could be useful. But you can't do it, as you say, "without incurring any limitations," not because of the scene switching aspect, but merely because a sound made up of a small number of elements in a Part shared with one or more other sounds similarly made up of a small number of elements in the same Part is going to have limitations compared to "normal" sounds, due to having to share certain parameters with other sounds that are part of the same Part, as well as, in some cases, simply no longer having as many elements to work with to create the desired sound.

So we're all on the same page, all of us would like Element state saving to be added to Scenes?

If so, the only questions left pertain to why this wasn't done already, as it makes for an exponentially more creatively powerful device, and is congruent with everything else about the operational mechanisms and paradigms of Montage/MODX usage.

(And subsequently, Darryl seemed to say that he thought this actually could work for what he's trying to do... again, in situations where he didn't need the AF buttons for something else.)

My erased reply covered this - but I'll try to sum it up in shorter bullet points of why the assignable function (AF1/2) switches sometimes (but rarely) help the task of providing random access to groups of elements.

1) AF1/2 are grouped differently than scene buttons. They are not mutually exclusive (one doesn't turn off the other) - which is good for the way you use them. Therefore we can only dedicate one of the two switches for something closer to random access.
2) AF1/2 switches don't manage your Part-level switching using mute or keyboard control (scenes). They depend on the previous state so you must also use them only in certain situations where the right scene button is pressed
3) AF1/2 as a multi-bit mux selector for different "modes" on any given Part has an incomplete mapping of states. This is the lesser consideration of why only one of the two buttons makes sense to try to achieve something approaching "random access".

By "random access" I mean you press a button and exactly what you want is selected. AF1/2 used in this manner forces one to press many buttons to "line up" the various buttons to achieve a desired outcome. In the throws of a gig - I can see having one of the AF keys (1 OR 2) to select some different elements (ON and OFF). There's a time and place for AF1/2 - but slightly constrained for this application due to how they work. "Constrained" isn't a dig.

And the loopback thing has its uses too. Parts 9-16 can't participate in keyboard select so you'll have to use mute - but that's still good. Parts linked together are tied at the hip for scene selection if you start using keyboard select (as I have) in lieu of mute. So I'll have to go back to mute for Parts 1-8 too instead of using keyboard select unless the "tied" 9-16 Part is always layered with the associated 1-8 Part. And this is different than using the element-level pie-in-the-sky scene switching because that would just leave the Part always keyboard selected and start managing at the element level instead. Although easier to program - there are some downsides to the loopback with respect to selecting groups of elements. For whatever reason although I often suggested MIDI loop-back as a "way out" for certain requests (with caveat) - I never chose to do this for myself.

And there's no UNDO!???

DARRYL - the democrat, said:
There's a great idea. Add that one to Ideascale and I'll be the first to Up Vote it for you!
You get enough votes and traction on that one, and with people from the Voicing team being on this forum, they may just push something like that high up on the list for future features...

Not even Chomsky shares your degree of religious devotion to democratic ideals.

@Andrew is that a backhanded compliment or an insult, referring to me as "the democrat"? Feels like some sarcasm that follows ... if so, not appreciated!
I think Ideascale is a great idea and I have had a good experience in using it. You obviously don't feel the same, but I was serious about Up Voting your "UNDO" idea and think it would be great a to add to Ideascale. If you don't think so, just say so, but there's no need for Chomsky references. From what I understand, Chomsky describes himself as a libertarian socialist, and while I have no issue with socialism, I am not selfish enough to be a libertarian ... so a reference in that context is not be appreciated!

And there's no UNDO!???

DARRYL - the democrat, said:
There's a great idea. Add that one to Ideascale and I'll be the first to Up Vote it for you!
You get enough votes and traction on that one, and with people from the Voicing team being on this forum, they may just push something like that high up on the list for future features...

Not even Chomsky shares your degree of religious devotion to democratic ideals.

@Andrew is that a backhanded compliment or an insult, referring to me as "the democrat"? Feels like some sarcasm that follows ... if so, not appreciated!
I think Ideascale is a great idea and I have had a good experience in using it. You obviously don't feel the same, but I was serious about Up Voting your "UNDO" idea and think it would be great a to add to Ideascale. If you don't think so, just say so, but there's no need for Chomsky references. From what I understand, Chomsky describes himself as a libertarian socialist, and while I have no issue with socialism, I am not selfish enough to be a libertarian ... so a reference in that context is not be appreciated!

Chomsky is the world's most famous advocate of democracy and democratic ideals. It is amongst his strongest assertions that if we had actual, real democracy, then most of the biggest problems we experience in modern countries (war mongering being the biggest) would be things of the past.

He contends that we have not yet achieved true democracy, but that the USA is the closest to this, despite still being miles off, because it's backed by a belief in freedom of speech, something he (as a linguist) claims is the single most important constituent freedom.

It is with that in mind, within the context of your comment on votes, and the manner in which "democratic ideals" and delusions can be abused, that I refer to Chomsky.

If you think it's some kind of sophisticated sarcastic snide snickering, you're wrong. It's a direct reference to the fact that what we perceive as being fair and just (a vote for each of us) is often a mechanism explicitly designed to ostracise, delude, divide and exclude us. This a point Chomsky (and many other media commentators and critics) repeatedly make about supposedly democratic institutions, mechanisms, governance and media, and the primary reasons for his hyper extensive support and rationalisations for the implementations of actual, real democracies.

As to definitions of libertarian as a description of self (as someone believing in libertarianism as a principled manner to operate things), it's very different from libertarian socialism, wherein the word is use is as a prefix to describe a form of socialism, not an end unto itself.

All of which is neither here nor there, because he's a self described libertarian anarchist, in which he describes anarchism as the purest form of socialistic democracy, not chaos, and you're not being compared to him, you were tagged as a lowercase democrat - ie a believer in democracy.

But you probably knew all that, and were just trolling 😉

I'd like for the steam to settle and folks take a step back. Try not chase or introduce topics just because you can. Some topics are predictably polarizing and that kind of thing doesn't serve any constructive purpose ultimately. I know at my gigs folks come in with all kinds of differences. Religion, politics, ethnicity, origin, affluence, etc. At the stage and under that roof the music is the glue that holds everyone together - getting along and grooving. It's quite a privilege for me to have the talent/knack/gift/what-have-you to be on the production side of this experience.

I don't always get what I want. I mean - this thread still reads like a soap and the suggestion to create a new topic - mostly just to leave the fat behind - wasn't popular. But I still think that the pieces which have value would be better served leaving the swamp.

Hope we can get back to lifting each other rather than too much of the opposite. Thanks for trying (and I mean that sincerely).

I'd like for you to not suppose things wrongly.

There's nothing but lift coming in what I'm saying in the post you're replying to, and any other reading of it is wrong.