Complex flow structure and layout (operas & ballets)

There is something that feels unconfortable when laying out a complex flow structure. Let’s imagine an opera in 2 acts. Each act has a symphonic prelude and 3 scenes. Each scene has 5 numbers, for a total of 30 flows.

This would be a typical set of layout requirements:

  • At the initial page of the work I would like to show the opera title and author.
  • At the initial page of an act I want to show the act number (“Act 3”)
  • At the initial page of a scene I want to show the scene number and description (“Scene 2: Inside a wood hut. A door on the side and opposite to it a fireplace. A wood table with chairs.”)
  • At the initial page of each flow I want to show the flow number and title (“12. Recitativo”).

This is going to be painful today with Dorico. If I’m not mistaken, the best way to achieve this is the following:

  1. Add Act number, Scene number and Scene description to all the flows that begin a Scene. Unfortunately there is no arbitrary key/value metadata in the Project/Flow Info so we will be forced to reuse some fields (because typically we will want to format each element in a different way, so it’s not enough with “Other information”). So maybe I use “Arranger” to set the Act number, and “Publisher” to set the Scene number and description, and so on.
  2. Create a Flow Heading for each of the scenarios (Act start, Scene start). The Default one be enough when we just want to show the Flow Number and Title. You have to create these Headings in the Full Score set and in the Parts set.
  3. Create Flow Heading Changes on each page where a Scene begins, choose “Act start” if it’s also an Act beginning, or “Scene start” otherwise. That means 6 Changes for the Full Score and other 6 Changes for each of the parts.

In my opinion, this recipe has the following problems:

  • Repetitive work: It’s a LOT of work creating Changes.
  • Reuse of Info fields: It’s not good to have to use fields for a different purpose. Besides, there is a chance that you run out of fields if you have them already filled out.
  • Layout rigidity: Flow Heading Changes are associated with a page number (also Page Template Changes). That introduces a rigid page schema that cannot be changed. If, after creating all these Changes you realize that you need to fix something that creates or removes a page, then ALL the following Changes will be misplaced… and that’s a lot of them in this use case!
  • Flow sequence rigidity: Once we write the Flow Info of each of the flows that start a scene, we have also fixed the order of the flows. Changing the order of one of those means that I have to transfer the information from that flow to the flow that now starts the scene.

To get rid of these problems, I would suggest the following features that I reckon will also be useful for other scenarios:

  • Tree structure for flows: flows are placed in a folder tree. The folders have Folder Info (similar to Project/Flow Info). This would solve the Flow sequence rigidity because info like the Act number would be set in the folder that represents an Act, instead of the first flow of the Act, so you can again move the flows around freely.
  • Arbitrary key-value metadata for Project/Flow/Folder Info (so that we don’t have to workaround with reuse of other fields). This would solve Reuse of Info fields, but it’s certainly useful for properly registering a billion other things.
  • Conditional flow headings. When there is no Flow Heading Change, the Flow Heading is chosen based on conditions. This would solve the Layout rigidity and the Repetitive work.
Condition Flow Heading
isFirstWithin(currentFlow, parent(parent(currentFlow))) Act start
isFirstWithin(currentFlow, parent(currentFlow)) Scene start
else Default

You can edit this table using some expression language. The last row of the table is always fixed (cannot edit, delete or sort it out of the last place) and shows the name of the Default Flow Heading. The rules are evaluated from top to bottom, and the first that matches is chosen.

11 Likes

parts don’t usually include scenic instructions, so there’s one problem solved.

2 Likes

You are right, I guess parts can get away without specific Headings because the (workflow) Number is unique throughout the piece, so the conductor and the performers can just use that. You could add “Act X, Scene Y” in the Default Heading if you need that info.

1 Like

I would enjoy having a tree structure for flows as well. There are a few use cases I can think of where this could really come in handy.

6 Likes

it would definitely be a welcome addition to Dorico’s functionality.

1 Like

I’m trying to imagine what the implications would be for flow headers and templates at the various levels, not that the problems would be unsolvable: my mind just starts wondering about the implications of such things on the programming side.

3 Likes

It would be interesting ; maybe it would ease the coding by “simply” preventing multiple flows on one page in those cases (which would also be useful to allow to swap flows that have custom layouts on each page for instructional material)

I don’t think that this would necessarily force additional complexity. Perhaps it just becomes a case of Flow 1.1, 1.2, etc. or 1 A, 1 B, etc. Or, each flow just gets a unique name just as it is now, but when they are grouped, you can simply move them around together in chunks, but that doesn’t necessitate that those flows be re-named or even subsidiary, in a strict sense. If each flow has a unique name or a unique internal ID, why should the program “care” if you end up grouping flows 12, 27, & 33? All it needs to know is that you want them grouped together. And potentially the only worry with naming would be to add a “flow group title” or some such thing, which would be an additional box in the info dialogue and an extra token.

My quick and easy method for now is naming the flow headers as Act/Scene/No./title

Atto I.1: 1. Recitativo
Atto I.1: 2. Aria

Atto III.5: 8. Aria

It does not look beautiful and it can’t be used for an edition, but it’s quite helpful for rehearsals and performance.

With the features I suggested, I don’t think there would be a lot of issues. The folder structure is used just as a way of organizing your metadata and sorting your flows. From the POV of the layouts, flows are still a flat collection. As @Romanos says, you have to come up with a unique name for each flow just as before. In operas, you usually do that with the first words that are sung in that particular number.

With the folder feature, this could be relaxed to be unique inside the folder, just like files, and then if you move one flow to a folder where there’s an existing one with the same name, Dorico would ask you for a new name for one of them.

I made a short video showing how I make opera scores here:

I’ve never run the risk of running out of Token fields, and applying different Flow Headings or Page Templates is pretty straightforward.

13 Likes

Ben, extremely helpful.
Flow Header changes were unknown to me until today!

I think it’s more or less the process I described, which is fine in the sense that it gets the job done, but you’ll still have trouble if you need to do something that adds or removes pages to a flow (all the subsequent Changes are broken) or the order of the flows (where potentially you will need to move metadata around, change titles, etc.).

This means you have to totally finish the music and the pages (I mean how many pages does each flow take) before starting with layout. Which is more or less fine if you are typesetting an existing work like your case, but a bit more problematic if you are composing a new one. And even in that case, tuning up a heading font size could lead to a flow having one extra page and then you’re in trouble with all the following page changes!

My feature suggestions follow the same mindset that led Dorico to the idea of writing music individually for each player so that the software could automate condensing as much as possible. In other notation softwares you write condensed music from the beginning. This leads to rigidity: if a homophonic section suddenly turns into a bit of counterpoint, you will have extra work splitting the chords into separate voices or even staves (or viceversa if you go counterpoint → homophonic). So you are forced into a way of working: first decide whether homophonic/counterpoint, then write your music.

Well, this is the same: if you dare to sort some flows in a different way or modify the music so that a flow has now a different number of pages, you will have extra work. Which forces you to compose first, layout second. That’s why I think it’s a good idea to add more structure to flows (if you need that) and conditional heading selection, so that Dorico can automate the layout of complex titles as much as possible.

2 Likes

@IgnacioCalvo - I LOVE this suggestion / feature request.

It would be incredibly helpful to have a folder structure for flows. And, if we already have part layouts and flow layout header options, could it really be that hard to implement a Folder First Page layout option of some kind??

The use case that I can see is for tune books where you want to group tunes by type – think 10 jigs, 12 reels, 5 waltzes. I personally like being able to arrange the flows within sections so that they make efficient use of the page. It would be absolutely fantastic to let the “folder header” carry all of the information about the tunes in that section of the folio.

Great suggestion!

3 Likes

I really love your idea of Folder Headings! It’s surely an easier intuitive way of implementing the Conditional flow headings.

I cannot edit the original post anymore so I will add it some specs for this, which would replace Conditional flow headings:

  • Folder Headings: For each folder you can optionally assign a Flow Heading to it. The heading for a given flow will be chosen according to the following rules:
    1. If there’s a Flow Heading Change, take that.
    2. If there are Folder Headings defined when going up in the folder hierarchy, take the first one.
    3. Otherwise, use the current default logic (First Page Flow Heading or Default Flow Heading)
2 Likes