playback of pizz. and arco

Hello, for the first time I use Doricos playback possibilities to check on a string quartet score. Hmm, switching to pizzicato works well after the pizz. marking. Once the specific part has started it, there seems to be no way back: the arco markings in the same part just get ignored. I end up with the rest of the piece being played plucked.
I input the playing technics via the panel using the mouse. I select the note and click on pizz. and later the same procedure when adding arco.
Is there something, I am overlooking? Thank you for a hint.

1 Like

On this subject it was written already a lot. Please search the forum.

In general you should find that this works OK, but some users do encounter problems. It could be that you are switching to another playing technique and inserting an additional ā€œnat.ā€ playing technique before the ā€œarcoā€ works for you. If not, please attach your project here so we can take a look.

Strangely enough, Iā€™ve just started to see the same thing (1.2.0.37 on 10.13.2) - I think for the first time today, improbably though that sounds.

Switching to pizz. works fine. But dragging arco from Playing Techniques (SHIFT + P) to a note consistently fails.

Iā€™ve also noticed that if I (single) click on a note which should sound, say, pizzicato (because it follows the start of that articulation and before it is notionally ā€˜cancelledā€™), it will sound arco by itself no matter what; although the correct articulation is usually applied in such circumstances when I play through the whole piece.

Could these two be related?

Please see the attached file, only pizz. and arco (no nat.).
It sounds more like flamenco than Schubertā€¦
If I follow your advice Daniel, adding a nat. before the arco does work, thank you.
This is a workaround - I would have to hide it though.
6. Wasserflut sample.dorico.zip (2 MB)

Just checked - and found some suggestions - in this thread, thanks.

Should 'nat.ā€™ work invariably - and in preference to ā€˜arcoā€™ until this is fixed (good luck with that change)?

I also see that the bug seems to manifest itself after a Save and relaunch/restart in my case as well.

(Standard Halion Sonic SE, BTW.)

Klaus, thanks for attaching your file. In the latest development build all of the arco/pizz. changes happen as they should. I expect the difference is due to a change Paul made a few days ago that ensures that the playing technique is output a tiny bit ahead of the note to which it applies, and with a longer duration. This change should make playing techniques more reliable in general, not only for the arco/pizz. cases.

Thank you Daniel

Thanks, Daniel. When will that build become available, please?

Should ā€˜nat.ā€™ always work instead until then?

Mark, yes.
I am actually interested more in what is been notated in the score.
Playback is just something to play with :slight_smile:

The reason one sometimes needs to add ā€˜natā€™ is because that clears ā€˜all nodesā€™ in the technique list so you can start fresh.

Pizzicato is a ā€˜stickyā€™ node that stays until you remove it by inserting an arco (or nat.) technique. Arco just removes a pizzicato node, while nat. clears ALL sticky nodes. Other example of sticky nodes include mute, no vibrato, snares on, and more. Other nodes which only last for a single note can get piled on in addition to the sticky nodes.
In an expressionmap set you might have assignments for all sorts of technique combinations.

staccato
staccato+mute
tenuto
tenuto+mute
legato+staccato
legato+staccato+mute
legato+tenuto
legato+tenuto+mute
pizziccato
pizzicato+mute
pizzicato+staccato
pizzicato+staccato+mute
pizzicato+tenuto
pizzicato+tenuto+mute

etcā€¦

As you can see in this GPO5 violin Map I have dozens and dozens of ā€˜combiā€™ techniques assigned. Itā€™s not unusual at all for me to need to add, remove, or change things around for each individual score I build in Dorico if itā€™s not initially calling up exactly what I need when I want it. Sometimes I even ā€˜cheat a bitā€™ and borrow seemingly unrelated techniques from another instrument family to get the ā€˜sound I wantā€™ and later ā€˜hide themā€™ in the score.

Depending on how your list of expression map techniques is built, you can have a different setup for each and every possible technique ā€˜combinationā€™; hence it is possible to wind up with a combination of techniques turn up in a score that ends up pointing to unintended instructions in an expression map. Dorico parses your list of techniques seeking a direct match, and if none is found then in most cases it just keeps using the most current technique.

One can always check the exact combination of techniques Dorico will hunt in the expressionmap in the play tab. If you see a star (*) in the technique lane that means it has more than one node. Hover the mouse over that event in the play screen to see the list of nodes that are active.

To build these types of ā€˜combiā€™ techniques one simply holds the ctrl key while selecting more than one technique.

Sometimes itā€™s better to clone or build a new technique that will call up the sound you want (adding any relevant sticky nodes), and sometimes itā€™s better to just send a nat. technique to get a fresh start.

Sending nat drops any sticky nodes to return to the base/default technique in the expression map and give you a fresh start. Itā€™s similar to the [reset] node in Sibeliusā€™ sound world in this respect.

1 Like

Does anyone know if there is out there some company that is developing expression maps? Iā€™d pay for a complete Spitfire expression map for Dorico.

1 Like

There might be, but Iā€™m not aware of any.

Disclaimer: Please understand that throughout this post Iā€™m not trying to rake Dorico through the coals. I think it has come a long way in a short amount of time. Many of the things people like me are ā€˜waiting forā€™ from Dorico, weā€™ve also been ā€˜waiting forā€™ from ALL THE OTHER platforms that ā€˜attemptā€™ to ā€˜interpretā€™ traditional notation into audible sounds.

Iā€™d considered doing some to share for libraries/Plugins I have at hand, but at this stage of Doricoā€™s development Iā€™m going to hold off and here is why:

  1. Really nice/advanced libraries have loads of ā€˜optionsā€™ for a reason. In fact, there are often so many options that require human interpretation and continual/precision intervention, that it still makes sense to simply unfurl things into a ā€˜tracking style dawā€™ before even trying to use such libraries.

What works well in one score at a given tempo/style/etc. can be terrible in another score. You would not necessarily want the same setup for a Romantic Era Tarantella as you would use for a Classical Era Symphony. You wouldnā€™t necessarily want the same static options for a melodic theme at a slower tempo as you would for a harmonic progression at a fast tempo. So, we need a little more logic in the playback system before sound designers can work up ā€˜smarterā€™ expression maps.

  1. When it comes to seeking a decent balance for a ā€˜minimalistā€™ map that can more or less get a user in the ball park, one has to have hundreds of scores from every conceivable style, historical period, and musical genera to try out. One needs years to play them all through the system and take notes on what your ears are telling you. You seek a balance that will at least be ā€˜okā€™ in a wide variety of scores. Once you start to get remotely close, the plugins are obsolete and the library has progressively morphed into something entirely different (if itā€™s even still available, supported, and will load and work in a given DAW). In this approach youā€™re essentially ignoring a lot of potential details that make the library so nice in the first place. To get something that is somewhat acceptable across every score you throw at it, youā€™re pretty much back to a basic General MIDI implementation (maybe 20% of what a respectable premium orchestral library is capable of).

  2. There are still some advancements that need to be addressed in the Dorico playback system. We need more information on how things behave now, and how they are intended to continue behaving far into future versions. We need a way to determine tempo and fork choices based on this. We need implementation of micro-tuning. We need the ability to make ā€˜customā€™ techniques. We need more control over ā€˜fall-backā€™ behaviors. We need exclusion groups. The ability to ā€˜channel bounceā€™. More of the ā€˜place holderā€™ functions showing in the expressionmap system need to be ā€˜implementedā€™. These things will come in time and they will be very nice, but for now many of us who love digging into these kinds of playback aspects are waiting in the wings to get, ā€˜more featuresā€™ and ā€˜more informationā€™ on the ā€˜standards and best practicesā€™ required to build something worthy of ā€˜sharingā€™, let alone ā€˜charging moneyā€™ for.

To somewhat provide a ā€˜work aroundā€™ some of us even use tools like Bidule or VEP to tack on some features that a given DAW might not have natively. I.E. With Bidule in the mix you can ā€˜channel bounceā€™ among any plugin you like TODAY, without having to wait around for Dorico to get that as a native ability. The catch here, is the setup is no longer ā€˜universalā€™. To share it with others, they also need Bidule, all the user files, and the patience to set it all up to ā€˜matchā€™.

Note, several of the things Iā€™ve mentioned here are not included in ANY scoring system to date (Sibelius, Finale, etc. either), and some of us have learned a valuable lesson when it come to trying to make a decent ā€˜sound-setā€™ for them. Case in point, Iā€™ve spent many months making very complex soundsets for Sibelius that sound great in specific scores, but terrible in others. I made the mistake of sharing them for FREE, to mostly get harsh and less than helpful feedback. Even if I take a specific score and do my best to force a musical sounding interpretation, and Iā€™m lucky enough to be working with a composer who will annotate things and describe what s/he WANTS, it rarely turns out ā€˜exactlyā€™ as the composer desires without a TON of extensive COMMUNICATION and COLLABORATION (it should do this instead of thatā€¦but only for measures blah through blah blah, but then do something else from the bulls-eye to the fifth sign, and on and onā€¦). Itā€™ll take thousands of lines of code-like instructionsā€¦requiring endless reboots of the DAW (or relaoding maps). Ultimately, itā€™s work I could have done in a few sessions in a tracking DAW like CuBase using itā€™s CC or NE lanesā€¦

  1. Personally Iā€™m also waiting for more information on how to communicate with HALion (as well as other VST3 plugins). HALion 6 is really good, and once we third party folks can learn how to best talk to it directly from Dorico, thatā€™s probably where Iā€™ll put most of my personal efforts (making HALion stuff). I.E. How do I pull up a sound directly in the plugin using Doricoā€™s own Flow building UI. If I were to charge money for something like this, Iā€™d want it to be able to work its magic by default if desired, without forcing the user into the ā€˜play tabā€™ to work in a whole new universe of playback madness that needs yet another manual of its own. Eventually we should be able to get kits to learn how to talk to ANY VST3 plugin at the command line level and place things that can call them up from inside the Native Dorico UI. Personally, I plan to start with HALion and Groove Agent, and we donā€™t have information kits for talking to those yet either.

  2. At this stage, itā€™s probably best for users to more or less start from scratch with ā€˜each scoreā€™ and build up a map as needed. Again, each score is going to have different needs. I.E. There are times when you might always want a staccato note living under a slur to be bowed martele. At a different tempo you might rather it be sautelle. Even at this level of ā€˜building personal maps on the fly for a specific scoreā€™s needsā€™, we still need in the least exclusion groups and custom user techniques.

  3. Iā€™m also curious as to how possible CC or Note Expression lanes might someday be incorporated into Doricoā€™s Play Tab. Once those are up and running, there are so many expressive things that it would make sense to enter there instead of trying to rely on static expression map entries to control. Once we get these, you can elect to simply draw what you need with continuous precision for each note and be done with it (like we do in a tracking DAW). Once we get these, we can maximize the potential of almost any third party library just as we would in a tracking DAW. Youā€™ll be able to do a full mock-up entirely inside Dorico himself. Expressionmaps will be somewhat ā€˜optionalā€™, and youā€™ll no longer need to export things into other DAWS unless you need the full scale audio track features such a DAW provides as well.

Hi Alroli,

A product like this has just been announced on the VI-Control forum, check out this thread:

https://vi-control.net/community/threads/art-conductor-for-cubase-expression-maps-more-than-360-maps-in-one-collection.68120/

This product isnā€™t really up my alley so I canā€™t vouch for it from experience, but there is supposedly a demo version you can test in Dorico ā€¦ not sure if the demo includes Spitfire though.