Not sure that's in the cards (adding features to discontinued models).   Neither MODX is officially shown as discontinued on the webpage - but the shared codebase with a discontinued product does somewhat put the writing on the wall.

There's lots of resource allocation that isn't optimized.  Another one is how elements consume polyphony even if they haven't started yet.  There's a way to delay when elements start.  When you press a key that starts the delay (not the element sounding - but the "silence" before the element envelopes start) -- all of these delays consume polyphony.  I just set up a Perf with all elements delaying except a few for testing and would immediately get notes cut off which told me the delays themselves are treated the same as "running" non-delayed elements.  Which is easy to program but maybe could be optimized. 

... and - maybe these optimizations are too core to the underlying ASIC cores to do anything about in software.  Which would explain why these things haven't been improved either in older gear before it was discontinued or the more recent reincarnations.

Still, good to document this stuff so Yamaha knows what you feel is important.

Not sure that's in the cards (adding features to discontinued models).   Neither MODX is officially shown as discontinued on the webpage - but the shared codebase with a discontinued product does somewhat put the writing on the wall.

I don't see the suggestion as adding a feature. I see it more as a 'fix' so that it can support 8 arps the way it is advertised as doing. And, as a fix, it might be appropriate to add to the older models. 

There's lots of resource allocation that isn't optimized.  Another one is how elements consume polyphony even if they haven't started yet.  There's a way to delay when elements start.  When you press a key that starts the delay (not the element sounding - but the "silence" before the element envelopes start) -- all of these delays consume polyphony. 

My take on that is that when you press a key you TRIGGER (NOTE ON) that element so you definitely ARE using that element and using 'start' is appropriate. And your own programming now has control over the element including any delay.

I would also point out that an element does NOT use polyphony just because the Element Sw is set to ON. It is only when you trigger it by pressing key that it uses polyphony.

That is the contrast the suggestion is making. Currently if an Arp Switch for a part is ON it counts as being used even though it hasn't been triggered.

Just like an element an arp has to be triggered and, when triggered both an Arp and an Element have 'started' in my opinion.

We can take things that aren't optimized in any way we wish - but the two examples are nearly equivalent.  Both share the same root issue: it's easier to code allocating resources based off a leading indicator that's less nuanced rather than allocating according to a policy if that something is "fully" operational.

And both are wishes for an alternative solution without really knowing what, if anything, is on the inside painting the current implementation into the corner it's in.