I don’t necessarily fully agree with this personally. Now in Cubase it is pretty much like how it has always been in Dorico. Yes, it may seem a bit unorganized, but I view articulations almost like “tags” where you select a sound slot by choosing what tags you want and it narrows it down to a specific best match sound slot from the list. The same way in which tags are unordered, articulations should be as well, and are only given orders by placing them in groups at the bottom. And you can have a large number of groups, for some VSL maps I’m looking at making around 10 or 11 groups, so having 10 columns could make the window too large.
I do however agree that it could make sense for them to sort differently, since the order of selection makes no difference at all. In Dorico they are shown lexicographically rather than in the order you’ve added them to that slot - the order you’ve added them doesn’t matter, so perhaps it could at least be the same here. I agree that the order they were selected in makes very little sense, since the selection order doesn’t have any practical impact.
In Dorico the lane this is based on doesn’t show the addons right in the name. However, it shows up in the tooltip when you mouse over. This information is not currently in the equivalent tooltip in Cubase but I did request this be added so that it matches the Dorico functionality.
I’m not opposed to also showing the addon names in the sound slot lane name itself visibly as an option, but if this was done, I’d also want this to be done in Dorico so they matched in functionality in this way.
A trick that might help you with this would be to use the search box in the articulations list to find multiple articulations at once, this can be done by using the vertical bar (aka “pipe symbol”) as an OR operator. So you could easily limit your list to just Largo and Norm attack by typing:
Largo | Norm
In the search box. It doesn’t exactly address your suggestion, but you might find you no longer need that by using the search. At least, I’m guessing you might not know about the | for “OR” since it is not obvious.
Also as another hint, in Cubase 15 you can now simplify your map design by not needing to define things like “regular” and “norm attack” at all. Instead, you can use the new special direction called “Reset” for this, since it lets you get back to an unset state for a group. This will simplify your lists. Each group can have an unset state as a “default” in which it doesn’t contribute any articulation name to the stack. This was always the case, but before there was easy no way to return to this unset state, but that’s what Reset gives you. So you can leverage this to make simpler maps.
As an example, “Normal attack” could be considered the default for its group and then you don’t need a lane for “Normal attack” - just don’t enter any attack, or if you are currently at a non standard attack like Slow attack, use “reset” to return to Normal Attack once again. You only need lanes for things that are “not normal” and use “reset” to return a group to normal.
This strategy for map design has some advantages in that it needs fewer slots since there are fewer permutations to handle. It also needs fewer articulation lanes. The only downside is for each group you might have to remember what the “default” is, but in most cases this can be decided in a predictable way, by deciding something like “anything that is regular or normal or sustain will be a default”.
The other advantage is that will help with your first issue (the “clutter” of not having the columns), by meaning you need fewer articulations in most cases. Everywhere you have “Norm Attack” or “Regular” or “Sustain” would disappear. So your list of sound slots that consistently has 3 articulations throughout would often drop down to just one or two, by leveraging this ability to use unset as a valid group state, resulting in a significantly cleaner list.
Using this new strategy for map design is also most compatibile with Dorico best practices for map design, allowing you to use similar strategies in designing maps that work in both programs without changes (at least, once we get a full featured map import from one to the other).