You’re reading a tone into my response which I didn’t intend, Dan, and I’m not in the business of disrespecting our customers. I’m sorry that I came across that way.
[Dan T]: I am still surprised how you can’t see this in your own post, but apology accepted.
As you work in software yourself, you’ll know that it can be difficult to separate your idea of how a problem should be solved from your understanding of its requirements. Many of our users without such experience will find it much harder to make that separation, and in general it’s much more common for us to be presented with a user’s idea of the solution rather than the underlying requirement. Of course, as the product manager with responsibility for understanding user requirements, it’s my job to unpick those requests and get at the underlying requirements, and I would like to think that after 25 years I’ve built up a decent muscle for doing just that.
[Dan T]: Part of this paragraph leads in to a larger discussion that is OT in this context, but I will send you some thoughts in a private message. But in terms of “separation of requirements”: in the thread start I describe what I think could be labeled “underlying requirements” in the “Rationale” section: 1) Support creation of drum parts that are clean and readable - for instance by avoiding long sequences of repeated information that does not contribute to anything but rather decreases readability and overview:ability (sorry for bad language) 2) support creation of drum parts that contains as few page turns as possible.
Then the next question will probably be: Ok so how could we meet these two “underlying requirements”? Then comes what I would like to call detailed requirements (or at least “a little bit more detailed”) on functionality that I would like to see as a user to make it possible to create clean and readable drum parts with as few page turns as possible. Here I propose the introduction of a easy and effective function that is customizable to make the drum parts look the way I as a writer would like them to look. I would still call these “requirements” (even if perhaps not “underlying”)! But not you?
I’m struggling a bit with your request here because it really does feel to me like what you are looking for is a set of incremental improvements on top of Dorico’s existing bar repeat regions feature, but you are quite adamant that you think of it as completely separate, or even more closely allied to multi-bar rests than bar repeat regions.
[Dan T]: I am not sure that “adamant” is an adequate choice of words here, but English it not my native language… But yes, I think of this as an “extended multimeasure rest” functionality, especially since the proposed workaround from Dorico in this thread Jazz/pop/rock drum part considerations - #21 by dan.h.tillberg was based on manipulating multimeasure rests. Anyway, “thinking of” a functionality “in terms of” is not really the same thing as stating a solution, is it? For me it is just a clarification that what I ask for is close to what already exists; and exactly for clarification and understandability purposes. In the requirements overview I have asked for the ability to mark a region in the score as a “multimeasure play” area, meaning that it is clear in the score what is reflected in the drum part, and that I as a writer decide what areas that should be of this type. Again: do you consider this to be a solution proposal rather than requirements?
While there is a certain amount of overlap between how consolidated bar repeats and multi-bar rests work, in musical terms they’re pretty far apart: one, after all, is concerned with playing the same pattern over a period of several bars, while the other one is about not playing anything at all over a period of several bars.
[DanT]: OK, I guess that way of “thinking of it” is as good as any other as I wrote earlier.
If I may take one more crack at summarising your requirements here, in terms of how we might extend Dorico’s existing functionality to satisfy them:
– In the full score, you would like to be able to replace the bar repeat symbol in the first bar in a bar repeat region with a box centred in the bar that shows the number of bars to be played, e.g. “Play 6 bars”, with the following bars showing bar repeat symbols as normal.
[DanT]: No, this is not what I have tried to explain. I want to mark a certain area in the score as a “multimeasure play region” (or “consolidated bar repeat region” if that better suits the discussion). The corresponding section in the drum part will then be condensed to something that I can configure it to show. Text boxes are clear and concise and would be my first choice, but I know others having e. g. wavy lines instead. This is up to the writer to define.
As a conductor/band leader, it should be obvious that a certain region is a region of this kind, then I know that the drummer only sees a “Play X” instruction for that region (or whatever I have configured it to be).
Very important is that I need to be able to have the freedom as a writer to decide which regions that should be of this kind and which should be written in another way.
I do not feel extremely comfortable to let the program condense bar repeats into “Play X” regions. I would like to be in control as a writer: if I mark 17 bars as one-bar repeats than this is what should be displayed in the part as well. There might be reasons for doing this. The writer is the one to decide. So to be usable, I would like to differentiate between marking a region as a ‘region to condense in the part’, or a section of bar repeats (of any kind), or a slash region. These are different things in my world.
– In the part, you would like to be able to replace a consolidated bar repeat region, where a bar repeat region appears as “a single bar” in the part with a bar repeat symbol and the number of bars shown above the staff, with a box centred in the bar that shows the number of bars to be played, e.g. “Play 6 bars”.
[DanT]: Well see the comment just above, I think that answers this. But yes, to save space in the drum part, the result should not initially take more horizontal space than necessary (of course, if I then could get the opportunity to change the width, that would not hurt but I guess it is not really necessary if the general note spacing settings works so well as they do today also for this kind of “measure”).
There are some further incidental details, such as you want the ability to control the font, size, style of the text and the box, and you want to be able to override the text region by region via Properties if need be. Otherwise, the requirements for displaying numbering above subsequent bars etc. in the full score are already satisfied by the existing functionality provided by bar repeat regions.
[DanT]: Yes as stated, I would like to define a style myself that is then used when marking a region this way. As mentioned, I think there are very different ideas on taste and design here and that should be left for the writer to decide. We want to leave our works to our customers in a way that we feel is what we want it to look like. Just as you do.
But fundamentally you are asking for a way to display a bar repeat region in the part as a consolidated bar that shows “Play n bars” instead of a bar repeat symbol, and to annotate a bar repeat region in the full score with some boxed text on the first bar.
[DanT]: Again, not sure that it has to be “first bar”. The underlying requirement in this case is that it should be clear and obvious to the score reader that a specific region is condensed in the part. It is certainly an advantage if the score reader can see more exactly what the part reader sees (e. g. the number of measures condensed and why not also the text marking). The clearer the better.
If I’m misunderstanding your requirements, please tell me in which ways.
[DanT]: Well I hope it is clearer now.