So, you're saying that there's a chance that it could get removed?they can take that feature away, no problem.
Edit - adding emoji to make it clear this is a joke.
It’s a joke because someone says a feature sucks, so I jokingly said that the feature can be removed (because it sucks). But the reality is that many people really like that feature. So it’s a joke because if it was removed, many people would not like that, so it will probably never happen.
Scene controllers are a different thing. They tell the box to modify a specific parameter. But X/Y says to load an entirely new set of parameters. To do what you propose, the Axe would have to look at both sets of parameters to figure out which ones changed, and that takes time — more time than people want to spend waiting for an X/Y change.Maybe, or probably you are right. I thought if the scene controllers can make it, than it would not be a problem for the x,y. An already saved preset could keep that info what You are referred to? I'm not a programmer, don't know nothing about it, just thinking.
the Axe would have to look at both sets of parameters to figure out which ones changed, and that takes time — more time than people want to spend waiting for an X/Y change.
Perhaps. But we know that the blocks are instantiated at startup, and parameters change on the fly. We know that, when a block undergoes an X/Y change, the output must be muted while the parameters are changed and the audio is flushed and propagated through the changed block. We know that the audio must be completely processed through the entire changed block, even if only one thing was changed, and that the mute window must be at least 30 ms or so to prevent a resulting transient.I don't think we have any information to guess about that. Even if this parameter check took time, what if the Axe could do that & save the answer when storing a preset?