Hi,
I can’t find this question, so I’ll post my own. Can a playing technique, in Dorico, be linked to a technique in an xmap, that selects a sound using a CC message?
In particular, I’m thinking to VLS’s Synchron Player, where some articulation have to be selected with a combination of CC4 (for a more general category), then a keyswitch (for the actual articulation).
I can’t seem to be able to make it work, so I wonder if it’s my fault or some limitation in the xmap system.
Paolo
There are also other problems in my setup. Referring to the attached image, here are my notes:
m.1: while the Strings instrument and the Long+Percuss. type are always selected, the Normal articulation is not always (or never?). Programming in the playing technique → playback playing technique → xmap technique seems to be correct.
m.2: the staccato is no longer selected. It has been sometimes, but no longer. I’ve tried with the ‘stacc.’ technique, but it isn’t working. Dorico restarted. No way.
m.3: the tremolo articulation is sometimes selected, some others not (and replaced by the fake tremolo by Dorico).
m.4-6: seem to be working fine.
m.7: the Pad+Solo type is not considered. Has been once, and then never more. The Flute solo instrument is not considered. Solo instruments can’t be selected in no case (they are the ones requiring CC4).
Paolo
I believe the issue here might be about the order in which the events are processed by VSL, and the distance between them. I was talking to Paul about this only yesterday. We believe that Dorico outputs all of the MIDI events shown in the ‘Actions’ table in the order in which they are defined, and they are output a few ticks before the note on which they are supposed to take place, but multiple MIDI events for the same action will all themselves be output at the same tick, and I have a feeling that this might not work in VSL, and that VSL might require each message to arrive at a different tick position.
The good news is that we are actively fostering a closer relationship with the team at VSL to try to improve Dorico’s support for VSL products, but please be aware that this will take time and is just one of many projects we are working on as part of Dorico’s development.
Daniel, knowing that you are working on it is very good news. Dorico + the best orchestral libraries on the market (VSL, Spitfire, Orchestral Tools, Cinesamples and the others) will be a heavenly combo, when ready to work together.
I know that engraving may be top priority for most users. As a composer, I’m usually asked to give both a beautiful looking and perfectly readable score – and a credible sound prototype. So, I’m very interested in seeing both sides of Dorico progress together.
In the meantime, I’ll try to place concurrent actions a bit far apart, using the finest grid I can set.
Paolo
Hi Paolo,
I use a similar setup as you, i.e. VSL articulations are triggered by a combination of CC messages, which are linked to playback playing techniques (and combinations of those) in a custom made xmap. This works fine for me, though I should add that I use the VI Pro player instead of Synchron. What I have learnt to be crucial, though, is to systematically ad an ‘ord.’ to avoid Dorico getting confused between articulations.
Koen
Koen, you should find that provided you set up the mutual exclusion groups in your expression maps correctly, there’s no need to add ‘ord.’ between each change of articulations.
In my experience this often fails with custom PPTs, which still requires an ord. to get things going…
There is one other thing that puzzles me: in the VSL VI(Pro) player, set up two small identical matrices with 3 cells each (e.g. a solo violin and a tutti violin section) each containing staccato, sustain (natural) and legato. Use any KS to switch between these identical matrices (using e.g. custom PPTs named MATRIX1 and MATRIX2, or solo and tutti, whatever) by a mutual excl. group.
In Dorico the techniques Natural, Staccato and Legato all work as expected when MATRIX1 is in effect, but fails when MATRIX2 kicks in (or vice versa, don’t see a pattern yet)… I’ve used this scheme without any problems in Cubase, so wonder what Dorico assumes under the hood… It’s probably trying to be helpful, I just can’t figure out in what way… 
After reading the above messages, I did some other tests.
First of all, I enriched the exclusion groups. This seems to work fine with the articulations requiring CC4 as one of the selection messages.
Mutual exclusion groups seem not to be enough in all cases. Sometimes, a ‘nat.’ technique (or equivalent, like ‘ord.’ or ‘bowed’) is still required.
Mostly, it seems to work.
Paolo
You are totally right - I hadn’t started implementing exclusion groups yet (this is a new feature in Dorico 3, right?) but yesterday I gave it a try and it appears to work fine. This more or less makes my set-up Dorico-VSL complete now.
Thanks for the good advice!
Koen
I think to have seen that things are more complicate when there are more techniques at the same tick, or near one to the other. This should confirm the observations Daniel referred here above.
As a workaround: maybe one could create separate technique for each case in the Synchron tree. But this would make the list of techniques incredibly long.
Paolo
FYI - VSL has no problems with CC/keyswitch ordering at all. Unlike Kontakt, which reorders CCs and notes arriving on same tick.
Rich, in your experience you can safely send a bunch of different messages (controller changes and multiple notes) at the same tick, and they’re always interpreted correctly by VSL?
Yes, in my experience VSL’s VI Pro player is best in class at dealing with control messages. It often needs 3 - matrix/X/Y - to select an articulation, and can handle any intermixing of program change, CC and/or keyswitches with aplomb. I have written many MIDI scripts (in Logic’s Scripter, Bidule etc) that generate these, in order, on the same tick and it works fine. MIDI is a serial protocol and the whole “send it a little bit ahead of time” thing is a needless result of Kontakt’s broken reordering of CCs. Any MIDI plugin that can’t keep and process messages in order is broken.
I recommend Bidule or some other MIDI monitor for those who are struggling to see what is getting sent, in what order and when. Bidule’s monitor can show the timestamps.
Rich is talking about VI Pro which is VST2. The issue of out of order midi messages is with VST3 plugins. VE Pro is VST3. VST3 protocol allows this so the host needs to deal with this properly.
I haven’t seen VST3 nor VEP mentioned in this thread so far. Oh right, Dorico wants VST3. Well if this is another Steinberg ‘enhancement’ to MIDI, aargh. Another reason I dread entering the Dorico expression map waters right now.
ptram is using Synchron Player and/or VE Pro. Both of these are native VST3 plug-ins.
If he is using Synchron Player inside VE Pro then that is the VST2 version of Synchron Player (because VE Pro doesn’t support VST3 inside VE Pro).
But in this case VE Pro is what is seen by Dorico. And that is VST3.
If he uses Synchron Player directly in Dorico, unless he uninstalls the VST3 version and adds the VST2 version to the whitelist, then the VST3 version is used.
So, if Dorico sees a VST3 plugin, it has to provide timestamp ordering or MIDI events can get reordered if they occur with the same timestamp.
If that is really the case, I’m not sure what to say except “this way madness lies”. VE Pro has a VST3 interface, but it only supports VST2 plugins internally???
That is correct. But it also supports all the other formats inside VE Pro (e.g., AU and AU3 for Mac apps, AAX for Protools, MAS for Digital Performer).
UM… the madness is that Steinberg in its infinite wisdom has chosen to eschew support for all the other formats (unlike every other company in the audio world) and push VST3 as the sole format in the long term. And this is the one that still doesn’t work.
Well, a blanket statement that “VST3 doesn’t work” seems to be heading beyond rational debate.
But what you say doesn’t give me any reason to want to by VE Pro, so that might be useful information.
