I have a suggestion - but only if it’s a good idea in the minds of those who know more than I do.
The suggestion is that there be two new threads on the forum.
The first would be called (and if it was started would include in its first post every word from the next line down from this one until the words below “The second thread”.
MUSICXML APP COMPATIBILITY
A thread to report import and export experiences with other apps. Please post in one of the following two formats only (omitting the words Format 1 or Format 2!):
FORMAT 1
IMPORT EXPORT TEST
App name:
Test date: (format Mar 5, 2034)
Plugin Name (if the test used a plugin):
Plugin Version number (if the test used one):
App Version Number:
Dorico Version Number:
Import to - or Export from - Dorico?
Import/Export Completed without Crash (different to error)? Yes/No
Completed With Error? Yes/No
Error Message(s):
Content Successfully Imported/Exported: (only required if error)
Content Not Imported/Exported: (required)
Notes:
FORMAT 2
APP/PLUGIN UPDATE
App/Plugin Name: (not Dorico - put entries for Dorico in MusicXML Dorico Compatibility)
App/Plugin Update Version Number:
Date of Release: (format Mar 5, 2034)
Updates to what version of MusicXML? (if known)
Additions? (if no known version number)
Omissions from full version number compatibility? (if applicable)
Notes:
The second thread would be called (and if it was started would include in its first post every word from the next line down from this one until the end of this post)
MUSICXML DORICO COMPATIBILITY
A thread to allow users to discover what improvements have been made in Dorico since its first release and what version number of MusicXML a particular Dorico version includes.
User entries would be in just the one format (don’t include the words Format 1!):
FORMAT 1
Dorico Version Number:
Update affects Dorico Pro? Yes/No
Update affects Dorico Elements? Yes/No
Update affects Dorico SE? Yes/No
Release date: (format Mar 5, 2034)
MusicXML Version number updated? Yes/No
MusicXML Version number?
Update introduces what new features?
Exceptions to compatibility with this version number?
Notes:
Can people who are highly knowledgeable about MusicXML and how reports concerning progress and issues needs to be structured - suggest any changes to the formats above (please include the whole format so it’s clear exactly what change you are seeking).
The aim is obviously that the general status of MusicXML functionality be able to be more quickly determined by any user and - if they wish to benefit from user tests - by the Dorico team.
I will include a request that any information not compatible with the formats be posted in their own thread.
If someone knows all the version numbers of Dorico releases that would be helpful. And obviously it would be nice if the entries in MusicXML Dorico Compatibility were in version order.
Dorico 4.0 nominally both imports and exports MusicXML 3.1. I don’t think it’s especially instructive to worry about earlier versions of the software, since the same is true going back all the way to Dorico 1.1. In the relatively near future, Dorico 4.something will nominally import and export MusicXML 4.0, but this won’t really make much material difference until we devote more development time to enriching the support for MusicXML features: making the app compatible with the latest schema version will resolve the kinds of errors and warnings that users might encounter at the moment, but that’s it.
The simple fact is that MusicXML support is just one of hundreds of things competing for the attention of our small and highly-contended development team. It has to be weighed against every other area in which we could spend our time.
This is also a poor time, from the point of view of us in the Dorico team, to be asking us to produce additional documentation about existing capabilities of the app. Producing such documentation also consumes resources in the form of time and attention, which is just as limited for the human beings working in the team as it is for every person reading this. While I don’t doubt that comprehensive documentation of Dorico’s MusicXML support would have a certain amount of value for certain people, I’m not sure it has sufficiently high value to warrant diverting our attention away from fixing high-priority issues reported in the recent Dorico 4 release, for example.
You may suggest that this work could be done by somebody outside the Dorico team, or by a community effort. The former is impossible: nobody outside of Steinberg will be permitted to see or examine any of our source code. The latter is impractical: without confirmation or guidance from team members who can determine with certainty the capabilities of the import or export code by auditing the source code or tasks in our (tens of thousands of item long) historical backlog, it would still end up consuming lots of the team’s time.
So my suggestion would be simply that MusicXML is treated like any other functional area: users who have specific needs should post their requests or queries, and we will consider them as they arise.
Thank you for explaining Daniel. It’s clear to me from your reply that my suggested MusicXML Dorico Compatibility thread won’t be of help. And I imagine that as regards the other thread your attitude is that you believe that you already know what will most help Dorico exchange MusicXML data with other apps more effectively and therefore reporting current tests would be busy work - we may as well not bother.
That only leaves me to ask - is there ANYTHING at all - no matter how unconventional - that you can think of which the combined efforts of the user base could do to lift some of the weight off you and your team? I am sure that there are many Dorico users who see that you have such an enormous task and are willing to be useful - if that is a way to see themselves and others better served? I can’t help noticing that you seem to be in a situation which is a somewhat unique in the level of support you are providing on the forum. Is there some way in which it’s possible to free you up more of your time so that you can attend to issues that are less one to one? For example could some volunteers who are passionate and already very knowledgeable liaise with you on issues about which they do not have answers - and seek to reply to questions on the forum - so that you might direct more of your time to things internal? (I realise you are not a developer but I ask nonetheless). Or is there some other way in which answers to questions can exist in the form of a Wiki so that there is greater capacity for people to be solving each other’s problems? I am imagining a structure where every tiny area of Dorico was divided up so each had its own page - or specific discussion area - allowing users to provide answers and information that pre-empts the likely needs of others. And where suggested improvements sit exactly where they relate. That kind of thing.
The Discourse system seems brilliant to me - I was going to say that to you in our private exchange. However it is as if it needs to exist within a hierarchy of larger - drilling down to smaller - drilling down to very small - subject areas. If it cannot be compartmentalised - is there a way that users could be requested to make breadcrumb style discussion threads so that areas of the program can be examined for answers and existing suggestions - users benefiting more from previous discussions? For example:
Write > MIDI Editor > Lengthening notes
Users would catch on - it wouldn’t have to be administered with an iron rod.
Suggested breadcrumbs could exist in a summary guide document.
So that all the titles of threads weren’t merely paths - causing them all to look the same the paths could exist at the start of the body of the post - enabling them to be found by search. So the format becomes (no spaces):
And for things which aren’t part of Dorico which might happen in the future!
Dorico>Write>ArrangeView or whatever
Dorico>NonclassicalNotation>SymbolEditor
You could update the guide document after each new version (it becomes part of the manual person’s job) and you can let your users do the work of keeping the document up to snuff by making their own paths in their posts (which you pay attention to) when the guide doesn’t suggest any suitable one.
The question underlying this is - are you constantly repeating the same information in addressing customer issues?
@k_b Every thread has the same depth in the list of threads. And it’s possible to see the thread names and who started them. Isn’t that enough for you? Do you have to read every word I write - only to then say it was a waste of space? Considering the situation I describe I hope you forgive me if I don’t overreact to dismissive responses which rarely if ever engage with the actual content of what I write - and if I imagine the environment to be one in which people with that type of outlook are limiting the freedom of others who are more open minded - positive.
Realistically I don’t think forum members would conform to such a naming scheme, even were we to propose one. I do appreciate the idea behind the proposal, namely to make it easier for everybody to find areas of interest or expertise, either to seek or provide support or relevant discussion. We have also had proposals in the past to split the Dorico category up into a larger number of smaller sub-categories. I’m personally a bit resistant to that, probably for no reason other than that I don’t find hierarchies especially easy to traverse or especially pleasing (I’d make a lousy librarian), and I have a feeling that it would end up having the effect of dividing the community rather than bringing it closer together.
We could perhaps make greater use of Discourse’s system of tagging, but in general forum posters don’t use the existing tags particularly consistently. It certainly wouldn’t be advisable to make tags mandatory in order to post, and if we had too many it would surely lead to miscategorisation as often as not.
So the current forum organisation as it stands is surely imperfect, but I find it generally meets both our needs in terms of being able to effectively hear from and support the segment of users who post here and the needs of our users, who know that it is an efficient way to ensure that their feedback is at least read and considered by members of the team.
I hear you and I will let the matter rest. What won’t sit so easily with me is the idea that Dorico is in some way unique in the demands it imposes on those providing support. Pro app or not - people usually function with a great deal less attention. I therefore believe that even if my suggestions aren’t the right ones there must be other strategies which would serve you (to not work every waking hour), your team, and your customers in the long term - better. Strategies that don’t make the number of customers you can support match the number of posts you can write on the forums.
PS For what it’s worth none of my ideas were supposed to mean that there would be no way to look at a single list of the latest posts.
I think, with the exception of the teething problems of the new Steinberg Licensing system, in general users can function pretty well without us in the Dorico team providing such a high level of attention. In the immediate aftermath of a big release, however, I expect to be spending more time here than I do at other points in the product cycle, because the forum is home to some of our most engaged users, likely to be early adopters, and we want to get visibility on any snags that were either not picked up during our internal or beta testing, or that we know about but which we may learn require a different (typically higher) priority. It’s not in general representative of how things normally go.
And of course we have many thousands of users, so this forum is only one avenue among many for them to seek and receive help or share their ideas with us – it is merely one of the more visible, publicly-accessible ones. Steinberg has a broad product portfolio, but Dorico generates roughly as many tickets to our support team, for example, proportional to the relative size of its userbase, as more established products in our portfolio.