Please add this one thing that we never got in Sibelius and Finale, and please add it ASAP so user and third party content development can progress rapidly along with Dorico itself. It would be a major help in making and debugging expression maps:
An information/status line, or perhaps a listing style console that will display a real time list of technique choices as a piece is playing. It’d be very helpful to be able to quickly see exactly which technique(s) are being requested and chosen. Currently it can be a bit of a guessing game, even if we insert a third party MIDI Monitoring plugin (Bidule) in the VSTi chain, there is still a lot of guess work as to which technique(s) the Dorico playback engine truly favors/finds/doesn’t find/etc.
I envision something like a debugging console supporting save as log, and highlight and copy features. It’d have control interface enough to pick the player/instrument(s) to monitor, and show what expressionmap decisions are being made in real time.
I.E.
[bar,beat,tick] Seeking pt.staccato+pt.sautille (Found)
[bar, beat,tick] Seeking pt.staccato+pt.sul tasto (Not Found) Falling back to: pt.staccato (Found)
This is a good idea. Also, using Vienna Instruments (pro) as a “debugging tool” is highly recommended at this stage, as it gives very clear visual feedback regarding which articulations (and combinations of same) are actually working …
That is actually something I have been wanting to add to aid in the development of the playback features, but there’s never been quite enough time to get that done in addition to everything else. There is some text logging we have in debug builds - but it’s very low level data and probably not too useful for most people .
I’ll certainly bear this idea in mind when I’m next working in the area.
I’m with you on having a monitor plugin. I do this with Bidule and it helps me to quickly analyze visually the events that ultimately get sent to the plugin. It’s a BIG help, but I’d love to get info on what Dorico is doing before it ever sends any event(s).
My understanding thus far is that expressionmaps are a bit different from Sibelius Soundworld in that there is no calculated ‘fallback hierarchy’ unless we specifically define it in the technique. Without a , if a technique isn’t found, then nothing changes (last selected technique sticks).
Example from “playingTechniqeDefinitions.xml”:
Once we get the ability to add our own custom techniques I think this will be far more predictable and much less confusing than Soundworld, but a little console showing exactly what techniques are being sought and found would still be a big help.
While experimenting, I did discover that we can add techniques via XML editor and they are added to the list; however, I can’t figure out how to get them into a score so they can be used (they do NOT show up in any of the panels to be inserted into a score).
Yes, the hierarchy isn’t totally obvious at this stage. (I updated the post above with a gif, if the ord.'s are removed then the previous technique goes on for bowed articulations, whereas pizz will override them.) I understand this is all work in progress, so I haven’t really spent much time trying to get to the bottom of it all…
If I understand correctly:
You can remove the pizz. node by dropping an ‘arco’ or ‘nat.’ technique on your score.
‘arco’ seems to just remove the pizzicato node, and leave everything else alone.
‘nat.’ seems too drop all nodes and take you back to your ‘Natural’ technique.
Some techniques do NOT have a ‘fallback’ assigned to them. If that’s the case, then you’ll need to figure out what’s missing and add it to your expression map.
For example: Lets say you’ve added a con sordino technique to a string stave. A few bars later, you might add pizzicato. If you discover that it’s still playing arco then you’ll need to add more techniques in your expression map, or simply send a nat. technique first (clears all the nodes), and then send the pizzicato.
By having lots of seemingly duplicate entries, we make it more possible to toss just about any technique we want anyplace in the score and instantly swap ‘stacked’ effects. It also makes it less essential to clear out our nodes (nat.) before building up a new articulation set. In this case, we could also be sure to get a ‘muted’ version of pizzicato.
Example:
Natural
legato
Accent
Staccato
Staccatissimo
Pizzicato
No Vibrato+Natural
No Vibrato+legato
No Vibrato+Accent
No Vibrato+Staccato
No Vibrato+Staccatissimo
No Vibrato+Pizzicato
Vibrato+Natural
Vibrato+legato
Vibrato+Accent
Vibrato+Staccato
Vibrato+Staccatissimo
Vibrato+Pizzicato
Muted
Muted+legato
Muted+Accent
Muted+Staccato
Muted+Staccatissimo
Muted+Pizzicato
No Vibrato+Muted
No Vibrato+Muted+legato
No Vibrato+Muted+Accent
No Vibrato+Muted+Staccato
No Vibrato+Muted+Staccatissimo
No Vibrato+Muted+Pizzicato
Vibrato+Muted
Vibrato+Muted+legato
Vibrato+Muted+Accent
Vibrato+Muted+Staccato
Vibrato+Muted+Staccatissimo
Vibrato+Muted+Pizzicato
Never enough time All these years later and Sibelius still doesn’t have it…nor does Finale. So, please try to convince the team that any and all info and debug tools (even if they are an optional dev pack for users that comes with extra licenses and agreements) will pay off big time in the long run.
These sorts of short-commings in mature products like Sibelius are EXACTLY why so many of us are excited about, and buying into Dorico as early adopters to participate in influencing its course of development while it’s still fresh at the ‘foundation’. Avid and Make Music no longer listen to anyone about anything (or perhaps they listen and would like to help, but have long lost the personnel with enough knowledge of the platform to implement such wish lists).
This is one thing that I believe would actually be a major ‘time saving’ contribution in the long run. Spending a day, week, or whatever on it now, would buy back many HOURS of time on down the road. Based on my experience with doing personal Sibelius soundsets…well, I’ve lost HOURS having to reload/test/reload and still mostly just ‘guessing’ at what’s really happening. For this reason I’ve never felt confident enough to do any truly polished ‘commercial’ soundsets for Sibelius.
HALion 6 really has me exited (now we can make libraries for the free Sonic SE player that comes with Dorico). It’s got an intense enough scripting engine to do the sorts of things NotePerformer is doing in Sibelius (real time decisions on articulations based on tempo, velocity, etc)! The same is true for Kontakt I think. So…given this sort of tool, dev time for content packs could be cut WAY down. In house, I think it’d also help speed up debugging for the fundamental building blocks of the whole technique and expression map system.
I agree that anything we can do to make the development of xmaps easier for power users will ultimately have a big benefit in the end for all users. As for the current state, please do bear in mind that this is still all in a very early stage. As your questions indicate, this is a hugely complicated area with many special cases. We are introducing functionality incrementally so that we can get feedback from the community as we go along (rather than create the full implementation and then find out doesn’t meet everyone’s needs).
As I may have mentioned before, the whole area surrounding multiple concurrent techniques and how they get resolved still has a lot to be done. We’ve not fully established the rules for mutual exclusions, priorities and fallbacks. Once we do I hope the behaviour will be a little less mysterious.
Very true indeed! While MM may have recruited enough new personnel to maintain the status quo for yet some time to come, the personnel able to nuture further development is long gone. The future of notation/composing software now seems to reside solely with Steinberg, so we should all rejoice and support the Dorico team in every way possible!
I do understand that Dorico is still a baby who’s cutting his teeth, and things will develop and improve with every update. This is exactly the reason I think that NOW (or in the very near future) is the time to go ahead and build in some sort of parsing/debugging console that shows us what is going on from score to expression map to MIDI/VST events.
Such a tool would help us to:
Analyze with our own eyes what’s happening. That covers for things that have not been documented yet, or might seem to behave differently from official documentation. Documentation/communication is a big deal…it takes forever to do well in any single language, let alone the dozens supported by Dorico. In contrast, a good programmer can make many awesome lines and modules of code in a few hours, with simple command line control structures built into the modules, but then discover that ‘explaining to others what it does, and how it works’ can take twice as long as it took to write the code in the first place. As a result, we have ‘implementation and documentation teams’ mandating to ‘programmers’ how things ‘must be implemented’, instead of having a more flexible/universal engine that ‘almost anyone can observe, implement with nearly ANY GUI, and ultimately document for end users’.
An even better analogy, is that it can take several pages of text, images, mathematical equations, etc. to show people what a wheel is and how it works. It takes about 5 seconds to pick up an actual wheel and roll it down a hill. The majority of users will get the vast majority of the information they need to know by watching that wheel roll down the hill. Status lines and consoles, as ‘out of fashion as they are in software these days’, still let us watch the wheels of the software roll by…yet they can easily be disabled and tucked out of the way when we don’t want them cluttering up the work-space.
In Cubase, we can visualize such logic for these expression maps in the MIDI Editor lanes. It’s not hard to judge exactly what a given technique is going to do, and if/when it’ll get triggered. I’m ‘guessing’ that eventually Dorico’s Play Tab will give us a nice graphical overview as well, but that could be many more months, or even years in the making. In contrast, a little code that simply parses the string of nodes to a dumb terminal, or a simple status line area somewhere in the GUI shouldn’t be that difficult to implement…and folks could more easily go ahead and be designing VSTi content with Dorico in mind TODAY…so more users can get that great ‘less tech, more composing-centric out of the box’ experience.
Being able to see what string of techniques are being asked for, found, not found, etc, lets us uncover in a few seconds what could take pages of documentation to ‘explain’, second guess, and ‘test by trial and error’. Even if all it does is display on a line just before it sends the actual VSTi/MIDI events on to the plugin, something like:
staccato+legato+no vibrato+mute
Then that’s some VERY helpful information to have at hand. It makes it super easy to figure out what we need to do on our end to make it play what we want.
As early adopters, we can better communicate our needs if ‘what IS happening’ isn’t going to be enough to achieve our ultimate goals given all our crazy ‘special circumstances’. If I could easily see what techniques a combination of objects on a score yields, then I could much more easily communicate with Dorico users and Developers. Chances are, there’s already more than one way to achieve a goal…we just don’t know it yet because GUI based controls (typically glorified XML editors) are not yet implemented in the main code body, and/or documentation is forthcoming. If we can see exactly what’s being parsed at the end of an expression map as a list of nodes (before it sends it as a MIDI/VST event), then with a simple glance we can see what it’s doing with our score instructions.
Sorry if I’m arguing in circles. Really I don’t mean to come across as argumentative, but rather pleading that information and debugging tools be top priority. Decades later, and we STILL do not have it in other scoring platforms, and they are still a nightmare to use with advanced orchestral libraries, and this lack of such a simple information status line or console ends up costing many users/developers a lot of time and ultimate product quality. Again, I can already envision BIG PLANS for the Play Tab…I know that we’ll see that part of Dorico grow by leaps and bounds as time rolls by…but in the meanwhile, some simple consoles and such could help early adopters get the ball rolling to help make Dorico a great ‘out of the box experience’ for new/potential users much sooner. Such a data stream will also come in handy when it comes time to build onto the Play Tab’s graphical interface. Such a module would already be there, all ready to snoop and incorporate all sorts of interesting ‘meters’, ‘status lines’ and other sorts of user ‘feedback’ into the Play Tab’s graphical interface.
An optimistic, yet realistic view is that by the time Version 2 hits the streets, people will already have access to some really nice sounding stuff ‘right out of the box’.
All these years later and Sibelius still doesn’t have it…nor does Finale. So, please try to convince the team that any and all info and debug tools (even if they are an optional dev pack for users that comes with extra licenses and agreements) will pay off big time in the long run.