First, there is no default articulation, only the default slot, which normally has no articulation associated. But you actually can associate an articulation with it if you want to, entirely optionally.
In the expression map editor if you click on the “—” in the articulations field for the default (top) slot, you can choose an articulation it should be associated with.
You can choose anything from the factory list. For instance, you could choose ordinario and then you will get an articulation Ordinario with text ord. in the list associated with the default slot. It is a personal choice. It is very easy to do for an existing map and takes only a few seconds.
You’re also not using the main user interface for working with articulations - the main interface is the articulations lane, which has been revamped in Cubase 15. You’re using a secondary method (the drop down list in the info bar) which works with attributes only, so the design decision for the defaults might seem to make less sense to you but actually generally makes a great deal of sense (at least to me).
When using the main method, not having the defaults take up lanes has some clear advantages. They take up less vertical space in terms of articulation lanes in the key editor, and result in less map programming being required. For instance, if you are making a multi-group map where one of the groups determines whether it is muted or not, you can avoid the need for a special lane for not muted, because you can consider not having an entry in the “muted” lane as being the same as “not muted”. This allows you to potentially avoid some pitfalls when you are programming the maps. For instance, if you have articulations in one group (like staccato/legato/etc) and your second group is con sord and senza sord (muted and not muted), you can end up with the situation where the user wanting an unmuted staccato note might choose staccato from the first group and in the second group they might choose unmuted or they might not choose anything because they might assume that unmuted is a “default” of sorts if they don’t choose muted. But this means you might have to program special cases for when the user makes a selection, so you might have to program a slot for if the user just chooses staccato in group 1 with no selection in group 2 (implied unmuted due to lack of an entry in this group) and another for if the user chooses staccato in group 1 and selects unmuted in group 2 (specifically choosing unmuted) and one for staccato in group 1 with muted in group 2. This means three slots in total, two of which are really the same (senza sord. specifically chosen vs no mute selection made and senza sord assumed) but are meant to handle the exceptional case where the user doesn’t make a choice from every group. Then for legato, you would also need three slots instead of two to properly handle the situation where the user only chooses staccato and doesn’t also choose senza sord for the note.
These extra slots to handle the various possibilities of a selection in a group vs no selection in that group and handle both correctly will not just be one extra slot, it would grow based on the number of groups in use. So if you have a more complicated map with 8 groups, you would need way more slots (in some cases, twice the number of slots, and need 400 slots instead of 200, or potentially even more) to handle the permutations.
The other choice with such a big map is to not handle the situation where the user doesn’t make a choice from one of the groups and require the user to add a selection from every group for every single note. However, this would quickly become annoying for the user, especially in the scenario where instead of using a mix of directions and attributes, you are using only attributes. Consider the situation where the choice of legato/staccato/etc is group 1, choice of muted or not is group 2, choice of vibrato type (ord (normal), molto or non) in group 3, and bowing position for strings in group 4 (sul pont, sul tasto or sul ord. (normal)). Forcing a user to add a selection from every group from every single note would require that, to hear a simple legato note, they would have to choose legato from group 1, senza sord. from group 2, vibrato ord. from group 3, and sul ord. from group 4, adding all four articulations to one note just to hear a regular legato. If they failed to choose something like vibrato ord from group 3 or sul ord for group 4, they would not hear the legato at all and would instead fall back to whatever is in the topmost (default) slot of the map. This would not be a user friendly design.
You could understand from that example that forcing the user to make a choice from every group like this for each note adds a lot of friction and extra work for working with the map, aside from being confusing to the user that they don’t hear their legato if they only choose legato without also choosing things like a vibrato type. But programming the map to accommodate for all the different permutations that the user might do (ex. selecting senza sord as the mute type or not choosing anything, selecting vibrato ord. as the vibrato type or not choosing anything, choosing sul ord. as the bow position vs not choosing anything) could require a large number of extra slots in the map by twice or three times or more, increasing the amount of programming work for the user making the map in the first place.
The easiest solution is therefore to design each group in such a way that a selection is not needed for the single item that is the “normal” way of doing things. In the group that controls whether it is muted or not, simply remove the “senza sord.” as an option and then the failure of the user to select “con sord.” would be treated as an implied “not muted” selection and would not need any extra slots created in the map. Similar with vibrato ordinario, you would only need options for molto vibrato and non vibrato and no selection would be considered vibrato ordinario (or in some cases like clarinet or horn the default should probably be non vib). Similar with bow position, you would only then include sul ponticello and sul tasto as lane options and if the user doesn’t choose either it would be considered the same as sul ord.
So that design keeps things simpler for the user (since they then don’t have to make a choice from these groups that shouldn’t really apply to hear something simple like a regular legato with no weird/extra stuff added) and for the person making the map (since they don’t have to make extra slots to accommodate selections that the user could make.
You’re coming at things from the perspective of incredibly simplistic maps where you only have one group and 6-8 slots, but the libraries I’m dealing with need quite a few groups and large numbers of slots (hundreds of them). So the considerations are a bit different. Your preferred design can work with the smallest maps with a single group, but becomes much harder to work with when the map becomes larger with groups etc.. I also couldn’t imagine working with a library like VSL duality strings with 300 articulations under the violins 1 all under a single group, the drop down list that you like to use would fall apart with 300 articulations in it and be really awkward to use. So you have to use groups, and working with defaults as a valid choice (choosing nothing at all is a choice) makes these maps a lot easier to construct and ultimately less work for the user at the end of the day.
