Flow, cautionary signature (time & key), system comment, system text and frame (text, music)

Dorico
1

Dear users and developers,

In this forum, I recently confronted some threads dealing with cautionary time signatures and key signatures. I also recently requested the system-attached comments and previously had asked for folder-structured flow concepts or subflows inside a flow.

The responses were diverse because these resonances are based on the type and kind of responders’ work and background.

In this thread, I would like to write the reason for the perspectives I consent to.

Let’s assume that we compose or notate a piece which includes multiple movements, and one movement of the piece is a variation on a theme. For example, we can find those constructions in Mozart’s A-major piano sonata in three movements, and its first movement is comprised of variations with a theme:
https://dme.mozarteum.at/DME/nma/nma_cont.php?vsep=197&gen=edition&l=1&p1=14

As one of Dorico users, I would like to make just three flows for this sonata, but the flow conception of current Dorico makes it difficult. The reason is complex:

  • cautionary time signatures are usually not expected to be inserted between variations.
  • cautionary key signatures are usually not expected to be inserted between variations.
  • the title for each variation and theme, i.e. variation number and theme indication, might be inserted using system text. However, it is placed below the tempo assignment. So extra work is required.
  • Between flows, before the first flow and after the last flow, one could put a report or instruction to the score. These are usually done using text frames. However, inserting new text frames, inserting new flows, or repositioning existing flows can change the order, so users should sometimes reorganise the pages of the Dorico project after that insertion or changes. To prevent this, using system-attached text is helpful, but the 0-line staff is officially not provided. I know a Dorico user offers a library. Even though using this third party needs to resolve the problem raised by cautionary key signatures and cautionary time signatures by covering them using thick lines and changing the colour to white.
  • working on those big projects needs a comments feature, which is not only staff-attached but also system-attached.

What if one writes an opera score, a theory book, an exercise book for an instrument, or composes contemporary music free from traditional notation conventions? Without resolving the details mentioned above, the workflow could be very troublesome. This is why some users, including me, request changes and implementations.

Unless resolving these problems mentioned above, the flow conception of Dorico has some weaknesses. However, this is not an attack on developers. I will never be back to Finale because the basic workflow for inputting musical events and the printed output of Dorico is better. So instead, I want to request the features mentioned above.

Dorico is the most enjoyable software for making music I have ever used! Thanks to Dorico developers!

Sorry for my imperfect English, and thanks for reading!

3 Likes
2

For this particular example, I would probably just use a hidden Coda at the variation, which will also hide the cautionaries:

coda
coda2342×893 189 KB

I certainly agree though that there needs to be an easier way to simply hide cautionaries without unnecessarily using a new flow in the middle of a piece, handout, etc., or without repurposing codas.

3 Likes
3

I have never repurposed Coda for this usage, but it is very efficient as a provisory resolution! Thanks for letting me know it.

Coda provides custom text, but we should hide it because of the coda symbol, as you already pointed out; then we need the system-attached text, but the system-attached text stands below the tempo assignment, so we should move its position again.

Even though those are bothersome steps, it is undoubtedly the best way to do this kind of work currently.

4

To get rid of the symbol you can in Engraving options change Appearance of coda repeat sections to “Text only”.

1 Like
5

Ah, yes! I forgot it when writing the previous post.
It is a clever way.

However, a movement consisting of ten variations with a theme and coda has eleven codas with the main body. The problem is technically resolved, but conceptually still not.

6

AFAIK Flow is a purely architectural element of how music is handled internally with Dorico, exposed to us as a feature so we can have the ability to enter blobs of music. Naturally users think of these blobs (flows) as having larger musical significance such as movements - but they don’t. They’re just blobs, probably class objects internally in C++ that hold meta and music data.

So we get the eternal discussions and requests … Daniel is steadfast in his support of how flows work, probably at least because it’s a fundamental part of the design. So, live with it.

Elsewhere I’ve made the point that this would all go away of Dorico wanted to introduce Folders to the Flow list. A Folder holds a list of Flows, it’s a small extension to the design and Folders need have no further implications(1), they’re just holders of Flows. This I think would satisfy users need for a musically relevant structural element, would make managing lots of flows easier, wouldn’t affect anything else in how the software works externally (it would ripple through the code a bit though) and would end these discussions.

(1) You can bet somebody will say “can’t we have folder tags in the music?” That might be a nice extension but hardly necessary, if folder “Movement 1” holds flows “Movement 1”, “Repeat”, “Cadenza” and “Coda” than all the existing capabilities should work the same.

1 Like
7

I think they do have musical significance to users though. In a multimovement piece, I may want to structure it so each movement is a Flow, or in an exercise moving through the keys, each exercise is a Flow. With the exercise example, if I later decide to reorder the exercises, it’s easy to simply move the Flows around. If I’ve had to use Flows to hide cautionaries then this becomes more of a pain.

Using Flows to hide cautionaries also seems like an inelegant and horribly inefficient solution to a simple problem (from the user’s perspective, obviously I have no idea from a development perspective), which is in contrast to most of Dorico’s elegant and efficient design. Let’s compare steps between different methods:

Finale - With the Measure Tool, double-click a bar with cautionaries at the end. Click “Hide cautionary clefs, key, and time signatures.” Done.

Dorico (Coda method) - Click a preamble element or the first beat of the bar after the cautionary you wish to hide. Shift+R, Coda, Enter. In Properties/Repeat Markers, select Hide. Done. The catch with this is that “Default gap before mid-system Coda section” really has to be 0 as the system cannot be adjusted to the left, so this can be a problem if you need Codas to hide cautionaries and “real” Codas in the same project. (Workaround I think I got from @Romanos is to set the gap to 1/128 which is imperceptible, and then allows the actual Coda to be adjusted manually. It can’t be manually adjusted with a gap of 0. Of course all “real” Codas now must be adjusted too.)

Dorico (Flows method) - Click a preamble element or the first beat of the bar after the cautionary you wish to hide, and select Write/Split Flow. Using prko’s example where he wants the beginnings of movements indented, but the variations not indented, means that Layout Options / Indent first system of flow has to be set at 0, as other settings can’t be moved to the left with the Note Spacing Tool. As a result, the start of every other movement must now be manually adjusted rightward with the Note Spacing Tool. If Flow headings are desired for movements but not variations, then something will need to be done to remove the Flow heading and spacing with “Variation I” here. “Flow heading change” / None incorrectly assumes that there is only one Flow per page, so removing the workaround Flow heading also removes the first one as well. In prko’s example I’d either need to remove all the Flow headings and recreate the first one, or simply delete or edit the second one. Deleting the second one isn’t a great option either, because it creates a page override with the heading space already accounted for, so I’ll need to manually position the staves on that page now. Of course, audio export is Flow-based too. If audio for each movement is required, I’ll need to export all the other non-workaround Flows as separate files, then export the workaround Flows together as a single file, otherwise I’ll be assembling them in a DAW.

Using the Flow method obviously creates a lot of hoops to have to just through just to remove a simple cautionary. It’s so kludgy and inelegant with so many workaround steps that I don’t really use it very often, and usually go with Codas. A way to simply be able to hide cautionaries like you can in Finale would be very welcome.

(Obviously that’s not all directed at you Dan, LOL)

3 Likes
8

Right - that’s exactly my point, users assign musical meaning to them but the conflict comes in because they aren’t meant to have musical meaning. It’s a part of the internal data structure that was a good idea to expose to the user. As a developer I’ve been on these fights for 30 years, FWIW I think the best thing is to throw in the towel and compromise with the Folder idea or some such, which is just recognizing that users want musically relevant structural elements.

if I later decide to reorder the exercises, it’s easy to simply move the Flows around. If I’ve had to use Flows to hide cautionaries then this becomes more of a pain.

C’est la vie, again you assign musical meaning to them, they’re just blobs of data, if you reorder then of course that might need adjustment since music is linear and forward affective, no different than if you reorder bars.

Using the Flow method obviously creates a lot of hoops to have to just through just to remove a simple cautionary

No idea, but I suspect it has architectural/design/internal implications which is why it’s not so simple. Maybe not.

1 Like
9

The current manual describes them as: “Flows are separate spans of music that are completely independent in musical content; for example, a single song in an album, a movement in a sonata or symphony, a number in a stage musical, or a short scale or sight-reading exercise of only a few bars in length.” All of those structures have some inherent musical meaning. Of course the description isn’t accurate either as Flows can’t be fully used for any of those things if they also must be used to hide cautionaries in the middle of any of those structures.

Here’s a page from André Maquarre’s Daily Exercises for Flute. I’ll often warm up with a few from this book as his patterns are a little more interesting than some of the standard books IMO.

maquarre
maquarre1920×1440 288 KB

As is standard in etude books such as these, there are obviously no cautionaries. Logically, I would personally think of each pattern as a Flow, so Exercise #1 here would be a Flow, #2 a Flow, etc. In this little 37 page book there are 7 exercises plus some preparatory material, scale work, and chromatic scale work. If I were to engrave this, I would probably want to use 10 Flows, handling the preparatory material and chromatic work as one Flow each, the scales as a single Flow, and each exercise as a Flow. The official Dorico way of engraving this book would be to use 194 Flows. (8x24 +2) That’s horribly inefficient and way slower than the Finale method or Coda workaround.

I sorta have a master file of my own warmup and technique patterns. By keeping each exercise contained in a single Flow (using Codas), it’s easy to just add that Flow, or a few Flows, to a Layout and print for a student. Adding 24 Flows to a Layout for a single exercise as in the Maquarre book means a lot more cleanup work before I can print.

If adding a Hide Cautionaries checkbox to Properties is too difficult or time consuming to implement, many situations could probably be handled in Notation Options too, since they are Flow-based. A Notation Option to Hide Cautionary Clefs, Key, and/or Time Sigs could be very useful as they could be turned on for Flows where they are desired, and off where they aren’t.

5 Likes
10

@FredGUnn: Thanks for the good example!

I think that resolving the problems in the first post of this thread might not be so complicated from the developers’ side because they already made the following features:

  1. “Hide” options for some items, e.g., stem, notehead, ledger lines.

  2. “Coda” feature.
    It is nearly perfect for resolving problems. However, conceptionally it needs to be corrected; moreover, it would be problematic when using a coda and variations altogether in a flow.

I guess that the simplest ways to resolve the problems seem to make the following two features:

  • a property for hiding the cautionary clef, cautionary time signature and cautionary key signature.

  • a “Section divider” for each variation: It might be simpler than making subflows or folders because they already have the “Coda” feature. The “Section divider” feature is a variation of the “Coda” feature.

The perspectives on the problems I illustrated in the first post of this thread may differ from the users and developers according to their work experience. I hope the users who encounter difficulties arising from this problem will add their experiences to this thread because the users like me who need these features should persuade the developer team to change their idea of the Dorico flow concept and emphasise the necessity of hiding cautionary symbols if the developers do not implement this feature due to their perspectives.

2 Likes
11

An unreasonable assumption.

12

OK, my assumption could be unreasonable or even wrong since I am not a professional software developer. However, it would have been better if you could have written why you think my assumption is unreasonable because I accompanied my assumption with why I think so.

13

Without knowing the backend structure of the database and programming that support Dorico’s features, one cannot know the difficulty or ramifications of making changes or additions to the programming. Daniel and others on the team have explained this many times.

2 Likes
14

Ok, I understand now.
I apologize for the hasty speculation.

15

prko said “might not be so complicated”.

16

I do not have any programming experience in C++, but I have some programming experience in SuperCollider, Cycling 74 Max, pd (pure data), open music, Processing, Kontakt etc.

Making a code or a patch to let it work for a specific thing may, of course, be challenging. However, encapsulation or defining a function could sometimes be more straightforward because it allows utilising the existing codes efficiently. I thought the following two existing features could be extended in this way:

  • “hiding stem, notehead, ledger lines etc.” to “hiding cautionary time signatures and cautionary key signatures.”
  • “Coda” to “Section divider.”

However, I do not know the internal code structure of Dorico. Moreover, I have also experienced many times that I should change unexpected parts by changing a variable inside of a function, an encapsulated part of a whole code. Therefore, I have no mouth to defend my speculation if someone thinks it’s unreasonable.