PaulWalmsley wrote: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.
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:
1. 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:
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.
2. 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'.