The Sound Variation API comes up short for a number of reasons.

The point you make is, I think, related to the fact that different dimensions are quite often best handled by a multi-group articulation manager such as provided only by Cubase expression maps.

having every possible combination of keyswitches listed as seperate articulations is indeed very unwieldy in many cases.  

For the case of Synchron, the total number of "rows" in the articulation lane should be DIM1 + DIM2 + DIM3..etc..  rather then DIM1 x DIM2 x DIM3, etc...  Even the Synchron Player itself presents things in this kind of fashion...but unfortunately StudioOne, LogicPro and DP do not have have multi-group functionality in their articulation managers as of now so the only way they can handle all the possibilities of multiple dimensions is DIM1xDIM2xDIM3, etc..resulting in combinational explosion. Only Cubase expression maps can handle up to 4 dimensions that way.

I have been able to code around this limitation in LogicPro using scripter and automation lanes to provide the other groups..  But I am switching to DP now...so...won't be any help much longer.

At least in the case of DP, one good news is that DP saves the results received via Sound Variation, into a json file, which you can edit after that if you like...and then basically just ignore Sound Variation after that.  So maybe you can write a script that can manipulate the json as you wish to reduce all the dimension multiplication...

Originally Posted by: richhickey

Cubase groups still have combinatorial problems (consider using a group for per-note accents, it's still a multiplier).

This statement doesn't make sense to me.  Maybe you can explain further.  I don't think it matters whether its by attribute or direction whatsoever.  Its the grouping that allows you to have up to 4 independent group of mutually exclusive keyswitches...which is basically what Synchron does too for the most part...

Umm no.  You can still have independent groups on a per note basis.

I think you might be conflating several things here.  Cubase expression map grouping works regardless of whether you are using ATTRIBUTE or DIRECTION.

DIRECTION and ATTRIBUTE both have their separate pros and cons, but grouping is not reserved only for DIRECTION.

Originally Posted by: richhickey

I do understand Cubase expression maps well, and did not say all groups have to be directions. I'm saying you do not get out of combinatorial explosion of articulation entries until you have an independent notion of directions. Consider: you have staccato, spiccato, detache and long, 4 artics. Then you add a mute group with 2 entries normal and con sordino. You now have 8 (4x2) entries in a Cubase-style map. You add a vibrato group with norm,

No you still understand that incorrectly.  it does not matter if the articulations are ATTRIBUTE or DIRECTION.  When you create multiple groups you end up with up to 4 separate articulation lanes, within the larger articulation pane of the piano roll.  Each of those sub-lanes has one of the 4 group's total possibilities.

So in the example you gave above, adding 4 primary articulations along with mute/unmute in seperate groups results in 6 total articulation rows on the piano roll.  that is totally the same regardless of whether you use DIRECTION or ATTRIBUTE.  Cubase is able to sort all that out.  And you can assign more than one articulation to a single note (in ATTRIBUTE MODE), one from each group.

Additionally, if you use ATTRIBUTE mode for the Mute/unmute, its possible through careful programming of the expression map sound slots; to have just a SINGLE row for mute, you don't need unmute.  SO you can reduce that expression map to a total of 5 rows: 4 rows for each of the primary articulations and one row to indicate mute. (when mute isn't selected, then unmute is automatically assumed).  You can't do that with DIRECTION very well because DIRECTIONS last from where they start until where they are replaced by something else, so if you h ave a mute group that has only one thing, mute, there is no way to switch it back to unmute.  So for that scenario you specifically want to use ATTRIBUTE type for the Mute group.

With this additional, you should only need 3 more rows added to the expression map lane...a total of 8 rows, not 24. 

groups are already independent, regardless of whether you are using notation or piano roll.  Its all the way you program the sound slots.  what you are describing above for notation can definitely be done for the piano roll, I have done it numerous times.  I can even do your example in 8 rows, by using ATTRIBUTE for the mute.  And in fact if you use ATTRIBUTE for the senza and molta you can reduce it even further to 7 total rows in the expression map lane of the piano roll.

I have made a program you can download which might help you to set these up, found here:  https://gitlab.com/dewdman42/emz

Dorico expression maps have a few improvements over cubase, for example, you're not limited to 4 groups, but you can accomplish the same things I have described above and there are other differences, not worth discussing here.

I do not understand exactly what you are trying to say in the above statement.  Maybe try wording it another way.

The main annoyance I see with Cubase Expression Maps and groups, is that the editor is lame and requires you to retype a lot of sound slot rows to account for all possible combinations in the actual sound slots, but when configured appropriately, those sound slots will not appear in the piano roll as all possible combinations, they will be consolidated in the piano roll as I have described above.

Again, I don't understand exactly what you're trying to say.  Synchron Player simply provides a hierarchical structure of keyswitches..which can be used to setup a patch in a way that will be conducive to using groups in a way as I have described above, or it can also be used in a different way to literally create all entirely different configurations such that there is no way around combinatorial explosion.  It just depends on how you configure the dimension tree.

Well I encourage you to try out the emz program I wrote and see what I mean.  It definitely does.  its just that the expression map editor makes it bloody difficult to figure out intuitively for most people.  its not obvious.  Its all int the way the combinatorial explosion of sound slot rows is configured, if you configure it a certain way, the piano roll reduces the view down to just a few rows...particularly for the kind of example you gave above.

I don't understand this suggestion either, maybe you can try writing it another way, I am genuinely interested.

We're definitely crossing our signals here. What you have been talking about is the UI within the Cubase MIDI editors for indicating which articulation is to be used, where you can orthogonally talk about the directions vs the per note attributes.

I am talking about the expression maps themselves, because that is what gets transferred from VI to DAW via sound variations.

So let's take a single case of something in Synchron Player and how to talk about it in Cubase vs Dorico. Dorico in their 3.5+ maps offers more of what I am talking about.

Let's take a theoretical SP instrument with the artic and directions I described. In all cases there are 24 patches, I am talking about the definition of the control plane.

In SP it looks like this:

Artic (C-0)  Vib (CC1)   Mute (CC4) - note how the control per dimension is declared

===================================

stac (C0)    Senza       Norm

spic (C#0)   Vib         Con sord

det (D0)     Molto

long (D#0)

9 entries. Note that e.g. how Vib is controlled is explicit (CC1). To change vib you only need to send CC1 and it 'sticks' until you send something else. This is an independent idea from any DAW/Notation and its editing UI - it's the control plane for the VI.

In Dorico it looks like this

Artic

===========

stac (C0)

spic (C#0)

det (D0)

long (D#0)

Vib (add-on)

==========

Senza (CC1 - 0)

Vib (CC1 - 64)

Molto (CC1 - 127)

Mute (add-on)

=============

Norm (CC4 - 0)

Con sord (CC4 - 127)

again, 9 entries. The add-ons correspond directly to the dimensions. Dorico knows that if Vib changes in the score it needs to send CC1. Whether or not it sends this with every note is its problem, not yours.

In Cubase it looks like this:

Artic   Vib       Mute      - Messages

========================    =======================

stac    Senza     Norm      C0+(CC1 - 0)+(CC4 - 0)

stac    Senza     Con sord  C0+(CC1 - 0)+(CC4 - 127)

stac    Vib       Norm      C0+(CC1 - 64)+(CC4 - 0)

:

20 other entries...

:

long    Molto    Con sord   D#0+(CC1 - 127)+(CC4 - 127)

24 entries. Tons of redundancy. Worst though is that e.g. Vib is not an independent first class idea - there's no indication which of the messages represent Vib. Vib is just something that can participate in a combination, and only then, to generate a ball-of-mud set of messages. But vib was an independent idea in SP, so this is lossy. Dorico add-ons are strictly better.

Cubase's maps are not good because they are only combinatoric. The Cubase MIDI editing UI (I'm not talking about the emap editor) could just as easily be used to control maps that had first-class directions, because that is exactly what Dorico does via notation and add-ons.

Originally Posted by: Dewdman42

Quote:

Synchron Player similarly needs to let us specify which dimensions are for per-note articulations and which we want to control independently of the sound variations system.

I don't understand this suggestion either, maybe you can try writing it another way, I am genuinely interested.

What I'm advocating for SP is that it let me tell it to only use, in this case, the Artic dimension for sound variation sync, meaning it will send a map with 4 entries, because I am going to use CCs or automation lanes to control Vib and Muting.

There is no need to have a shared "group" idea in the sound variations API because that will just lead to more copying of Cubase in its current limited state (which Dorico did and then backed away from), and dictates too much to implementations. Sound variations are ok for per-note stuff.

In practice, for most Synchron libs I'd only want the Articulation and Type dimensions to generate a sound variation map. I just did this by hand for Elite Strings and the map has 42 entries (instead of the 400+ it generates automatically) - perfectly great for DPs artic selection menus and editors. I control Vib, Attack, Release etc with CCs - they chase, and fewer messages are sent per note. In Logic it's trivial to make a Scripter UI which gives CC values names.

Still WIP, but I'm happy to share if you have Elite Strings

Originally Posted by: Dewdman42

Originally Posted by: richhickey

We're definitely crossing our signals here.

apparently still....  sorry but you are just incorrect about cubase.  But I'm tired of this discussion.  Try the things I suggested earlier if you like and my emz program may help you set up Cubase expression maps without combinatorial explosion

But both DP and S1 will suffer from the combinatorial explosion when using Sound Variations.

Sorry to hear that. I enjoy taking with you about these issues since we seem to share many of them. I'm a programmer and can and have written programs like your emz, but I think the need for it highlights the shortcomings of Cubase. When you say "the editor is lame and requires you to retype a lot of sound slot rows to account for all possible combinations in the actual sound slots" you are again highlighting the problem with the expression map architecture itself. Even if you use a program to help you generate it, the map is still one of combination->bunch-of-messages and has no sense of which messages correspond to which values in a particular dimension/group.

But the important thing here is not a "what if?" about Cubase or the Sound Variations API. The Sound Variations API exists, it works the way it does, and it raises the question as to how Synchron Player will interact with it.

I maintain the initial premise that Synchron Player, by naively exposing the multiplicity of all dimensions to the SV API, is creating a combinatorial explosion that does not exist in Synchron Player itself.

At least it seems obviously wrong to send combinations with dimensions assigned to Speed or None, since there are no messages in the SV API that can control them.

To be perfectly clear what I am talking about, here is the articulation picker menu generated by default from Synchron Player for Elite Strings. The image is just the first of 5 pages of menu!

Now here is the entire menu generated from just the Articulation and Type dimensions. Since I use CCs/Velocity/Speed for things like vib/attack/release/agile I don't want them in the sound variation system. That control is what I am asking for.

If anyone wants to try this, and has both DP11 and Synchron Elite Strings, this folder contains slightly re-arranged presets for Synchron Elite Strings (mostly normalizing the treatment of Vibrato, which in the defaults was sometimes a Type but more often its own dimension), as well as an articulation map file for Digital Performer 11 and up. The same articulation map works for all the sections, enabling copy/paste between tracks keeping articulations.

This map has entries only for every combination of Articulation and Type, both of which are driven by keyswitches at the low end of the range. The rest of the dimensions (vib/attack/release etc) are controlled by CCs, velocity or speed.

This yields a manageable list of 42 entries, which works great in the articulation picker menus and UI. By default velocity controls attack type, CC1 controls vibrato type, CC3 controls release type, CC20 controls slot XF and CC2 controls velocity XF. You can easily change which controllers are used in the Control tab of Synchron Player.