When To Use More Than One Flow

This post contains errors due to my not seeing parts of the help and the manual. Read beyond this post before making conclusions about the manual and online help.

I wasn’t offended at all Marc. I know others know the program better than me - but I still sense I can make a contribution while hopefully learning quickly from others.

Thanks Lillie for your comments.

Please understand that you and Daniel are responding to a completely awed Dorico user who is delighted with how Dorico is designed. I wouldn’t bother making comments if it didn’t seem worthwhile for this reason.

Yes Lillie I see that there is a section labelled Dorico Concepts at the start of the manual but its focus is only on the fact that Dorico has less in built dependencies/rigidity than other programs. It then has a couple of links to individual concepts. The reason why I believe this is not adequate is because I believe people will only understand Dorico’s key concepts, and have the quickest introduction to the program, if you do each of the following three things:

1.——— begin by describing each of the key concepts independently of each other. And do so while attempting to predict which aspect of each will prevent the user from guessing incorrectly how the feature works. Every single key concept in Dorico is met by users with pre-existing expectations. For example:

-FLOWS - many users will think that flows are more of a unit for formatting than is the case. I have at the bottom of this comment made an attempt at introducing a user to flows. I’m sure others can do better than me but I post it in case it reveals where I am coming from.

-PLAYERS AND INSTRUMENTS-the issue with players is that they aren’t instruments and instruments aren’t players and yet Score view starts in page view which doesn’t show either instruments (with triangles pointing across and not down) or staves for each instrument - only galley view does. Therefore we don’t learn any difference between players and instruments by landing in page view - an introductory video could have prepared us.

-LAYOUTS -the issue with layouts is that users with any history with notation apps will likely expect a single score layout and a layout for each part and no more. And they will expect all entered music in a project to exist in all layouts. So the focus needs to be on correcting those expectations.

  1. ——— having introduced each concept separately I believe you must then explain the RELATIONSHIPS between the key concepts. I mentioned above that understanding the many to many relationships between players/instruments and layouts and flows, and then showing how Dorico’s user interface has been designed to reveal them, is very important. People must be led to seeing the WHY in the design. Part of doing that will require a user to understand why Dorico has modes. Why doesn’t the app just have one mode with lots of tab views around the edges?

3.——— having done these two things finally you must ensure that ALL of this information be IN ONE PLACE:

  • in the manual (as if to say "You won’t get any one of these things until you understand each key concept in relation to the others - or at least REALISE that that’s what you will eventually need to achieve”.
    -in an introductory concept video pinned to the top of the hub.
    -as a separate menu choice in the Dorico help menu (above the general help). This information must not be WITHIN any help or manual (although in the case of the manual I’m only suggesting that it exist at the start and be given a heading style that indicates that it is the first “half” of the manual and the subject based help is the other half.

Finally, here is an idea which I believe would be of help not just to those writing documentation but to those designing and developing. You need to think Why then What then How. Watch this brilliant and famous talk by Simon Sinek to understand where I learned this.

I think that Dorico has absolutely nailed it with its thinking through on design issues. And thank God (I’m a believer) - the task is so complex. The design issues show that developers and UI people have been thinking hugely about the why first. But as yet I don’t think that this same emphasis on letting the structure of app help, videos and manual be governed by the why is there yet. I know that most app help doesn’t focus on the why. But if Dorico’s approach to help and documentation takes the same approach I believe it will suffer even more than other apps do when it is the case.

You will know when you have the manual right - it will lead people to read the vast majority of the many pages with an expectation of what must have to exist and how it will likely need to work. One helpful consequence of this is that you feel less need to make sure that every place in the manual reference every other one. When it does I believe it’s an admission that the manual has no power to guide users from big concept down to small.

FLOWS

A flow is a collection of adjacent entered music (including potentially any number of empty bars in metred music). Each flow is represented in the bottom panel in Setup mode and is given a default name (Flow 1, Flow 2 etc) but you can name each flow as you wish.

In a new blank Dorico project in which players have been added there is a single flow which displays staves for each player. If the user enters music without adding additional flows all the music will be added to that single flow. The user can then choose at any point in the music to split entered music into two separate flows and can also add new blank flows. Finally a user can re-order flows as a way of re-arranging their music.

Splitting music in Dorico into two or more flows enables Dorico to complete various operations by selecting one or more flows as the target for the operation. For example one or more flows could be chosen for export. Or an empty flow could be the destination for imported data. Flows also enable the user to quickly locate key points in the music for viewing, editing and playback.

Although flows are used primarily for organisation and operations flows can assist the user with two formatting tasks:
-by default bar numbers restart at bar 1 for each flow. This means that flows are suited to being used to distinguish movements in a score, or numbers in a musical etc.
-flows provide a way of telling Dorico the points in the music at which you wish to automatically generate titles. The titles are automatically generated from flow names.

2 Likes

Are you sure you can speak for “many users”?

I wonder if by trying to “simplify” the concept of flows you will be introducing confusing or erroneous information into the discussion, given the responses you have been getting from those who better understand the several ways flows fit into Dorico; and those who seek to learn more about flows will be more confused rather than less after reading your take on the subject.

No question Dorico is a sophisticated and ground-breaking program which can confuse people as they first encounter it. But many users :wink: have learned to navigate within it even though few, if any, may know it completely (other than Lillie, of course, and Daniel :slight_smile: ).

Hi Derrek,

Thanks for your comment.

No I’m not sure I can speak for many users. I’ve listed my predictions for how people might pre-conceive certain Dorico features based on a belief that I may be right with at least some users. I think it’s unhelpful if those responsible for users believe they wouldn’t benefit from seeking feedback - or if people responsible for users have no ideas concerning how to help users in the absence of asking them. Both are a real problem.

The reason why I have posted is because I think that it will advantage Dorico users to think about key concepts not in respect of how most users use them now - but in terms of thinking accurately about what they do and don’t do.

I hope that my asking others to show me errors in my thinking - and my willingness to change my original post to correct mistakes - will result in this thread being helpful and not harmful at least to those who read carefully. I posted because I sense that flows is an area where it will help to think more accurately to get best use out of Dorico.

1 Like

My take on all of this is… watch Daniel’s original video introducing Dorico 1.0. (The basic conceptual roadmap is there). Then I feel it’s up to each user to experience flows by playing with the program a little and see the power and beauty. Finally, I believe the user should assess ways in which flows can be used for different projects that they decide to take on.

Flows are pretty amazing. It would be nice if you can have them in separate windows so when you hit play in one window, if the other window is in other flow it doesn’t move. For copying/arranging will be a nice tool. If you already can do it, I would like to know how :slight_smile:

Thanks for your feedback substanceoverstyle - it’s always informative to hear from users.

Forgive me if I misread your paragraph referring to the Dorico Concepts chapter - but did you actually read the topics below the link I posted? At the bottom of that page, the related links to “X in Dorico” don’t take you to elsewhere in the manual, but to the specially-written “concept” introductions in this initial chapter. (The links essentially duplicate the subtopics in the list on the left; because that initial page “Design philosophy and higher-level concepts” is quite long, having links at the bottom means you can go straight to further information without having to scroll up again.) They are segmented, but the explanations for each concept very deliberately touch on related ones, and in roughly the right order (as I imagined this as the sort of chapter users are more likely to read top-to-bottom, more so than the more reference-y parts elsewhere) - so “Players in Dorico” comes before “Instruments in Dorico”, as you can’t add an instrument before you’ve added a player, but then the next topic explains how instruments work and why the player type is relevant to them.

Hopefully the topic in this chapter about modes is helpful too - without being too laborious or prescriptive, the description of each mode outlines what the mode is primarily for, gives examples of a couple of key functions, and (if there are particular restrictions like not being able to delete anything in Engrave mode) a note as to why that is.

Edit: here’s a link to the new topic in this chapter, published today, “Notes and rests” that was added after encountering a number of users grappling with the difference between how Dorico handles rests and ties compared to other software.

Hi Lillie,

You were right - I screwed up.

I didn’t notice in the online help that when you click on “Design Philosophy and Higher Level Concepts” that in fact the left menu exposes topics at the third level down. And I thought instead that the links at the bottom were to elsewhere in the manual and were therefore not part of a conceptual introduction.

Similarly in the PDF manual I got to the end of “Design Philosophy and Higher Level Concepts” and when I saw that the next heading had the same title size I presumed that it was a new section - not a continuation of design philosophy.

I confess that I do this all the time when reading information - I find it hard to remember where I am in a hierarchy. And yet that’s how I think - hierarchically. I’m obsessed with this issue - I want websites to have a navigation bar that leaves “breadcrumbs” so I know how deep I am in. But how is one to do this in online help and in PDF documents?

Thank you for VERY graciously putting me in the picture.

Your point that people can find details about any feature or menu or setting in the manual if they search with the correct terminology is important and absolutely true - but that truth leads me to the opposite conclusion to you - and I confess to possibly the rest of the human race! I would prefer a Dorico manual which was strongly hierarchical - because the user would still have the ability to search for the feature they seek to understand by either doing a computer search or using the index. So my preferred Dorico manual would at its highest level be three sections:

  1. Dorico Design and Key Concepts - introduces each mode and each key concept (projects, players, instruments, layouts, flows, master pages) as you already do now (I now realise!). And I maintain that the user needs a greater insight into the way in which flows work in the program even in the initial introduction - because flows are more abstract than other key concepts and because unlike the program, the project, the layout, the master page, and the page - flows are less used for formatting.

    \

  2. Dorico by Mode

      Setup Mode
    
              Players and Instruments
              Layouts
    
      Engrave mode
    
              Engrave Options
    
      Write mode
    
              Notes
    
                    Entry
                    Editing
                    Properties
    
              Slurs
    
                    Creating
                    Deleting
    
  3. Dorico by Key Concept

      The Dorico app
    
              The Toolbar
              Panels
              Preferences
              etc
    
      Projects
    
              Project Settings
              Creating a new Project
              etc
    
      Players
    
              Player Settings
    
                    Viewing Chord Symbols
    
      Layouts
    
              Automatically added layouts
              Creating additional layouts
    
      Flows
    
              Adding new flows
              etc
    

Before I get flamed let me say that I imagine that many wouldn’t like this (but perhaps to a great extent because they have become used to the manual being a particular way?) - but I’m quite sure that it would lead to new users understanding Dorico more quickly. I’m mindful of how important it is that Steinberg win schools to Dorico - that it not seem too “pro”.

Once again my apologies for not seeing the detail you pointed to at first and thanks for taking the time to consider my thoughts.

Perhaps it is not that we are used to the current approach but that we trust Lillie’s expertise.

Don’t just moan about it. If you think there is gap in the market, write your own “Getting started with Dorico” book and sell it!

I’ve edited my very first post so that it more accurately introduces flows and so its checklist is easier to glance through in making decisions regarding multiple flows.

I would love for future flows to behave like DPs ‘chunks’, where they can be arranged on their own timeline and different flows (of varying tempos etc.) can play at the same time as each other.

2 Likes

Yes.
A DP’s “chunks” emulation would be a great improvement to an already great notation software.

2 Likes

That would be kinda cool actually. Similar workflow as with Maschine - write little pieces and assemble them in something bigger. It would probably require something like “global segno”, “global coda” etc to glue it all together. Or alternatively, use flows like procedure / macro definition in programming, then refer to them by name in the “main score” and compile a resulting score to something readable by musicians… That would be super, super cool!

Then, to take it to the next level, enable also something like patterns where you could create a pattern but apply it to a chord, something like mma, but visual.

So many interesting options!

I didn’t know anything about DP’s chunks but having watched a few videos I think your idea is a very interesting one. The problem though is the relationship of the different saved arrangements of chunks to the formatted music. What for example would happen if the user chose to make an arrangement of chunks that excluded a chunk that had a second time bar in it? It would be too difficult to handle issues like this per arrangement of chunks. But I think I’ve come up with a way of getting something closer to chunks even if not all the way there.

I’ve also realised that if there are a lot of smaller flows in a project it makes administration of layouts - choosing which flows will display in each layout - pretty much impossible. In Setup mode where flows are currently managed you wouldn’t necessarily remember which music is in which flows and therefore which flows to include in a layout - and you don’t want to have a pile of flows to tick and untick for layouts. So I think this sinks my idea about using flows more flexibly. However I have thought of another way to proceed.

Imagine that along with flows Dorico had a concept of “regions”. A flow would be made up of one or more regions. No region could cross a flow boundary and just as every bit of music in a Dorico project must currently be in a flow every bit of music in a project would be included in one and only one region. If you exported the piece to Cubase in a special file format the region breaks would become regions in Arrange view. To make regions you would be able to go through the piece inserting region breaks. If you didn’t create region breaks then each flow would remain one and only one region. They could either show as signposts or you could use an alternative interface - when you clicked on a music object the system track could light up to show all the parts of the system track that were included in that region (just the system track would light up - not all the musical objects). Then you could choose one of three commands - Move Region Left or Move Region Right. Or Move Region to Bar Number. Moving the music to a bar or point located within another region would cause the region being split to become two separated regions (divided by the moved region which would be a third separate region). To merge regions you would chose a note in the leftmost region and rightmost region you wish to merge - all regions within the range would become one region. If you moved the music to a flow boundary (which wasn’t the start or end of the layout) you would be asked if the region’s music should be added to the left or the right flow. You could also Split Region just as you can currently Split Flow and on the score layout you would have the option to “Hide Region from All Layouts” (a temporary hack in a piece without losing content or having to store it in a dead flow - you wouldn’t have per layout control of region visibility. Dorico could remove symbols from the region being moved and the region after the ones being moved such as second time bars etc. And you’d warn the user during a move or copy operation that this meant having to review layouts - which included the flow of which the region was part - for bar number changes or other items which may no longer be in order. Playback would miss hidden regions - but you would still be able to see the hidden bars in Galley View (marked in a secondary highlight colour?) although not in Page view (except for a signpost).

Of course doing these things will have consequences for scores where the user had already inserted system and frame breaks but the user will soon enough realise that they shouldn’t be formatting their score except minimally until they have finalised the arrangement of the music.

So the user would use flows for the reasons they have up to now (except perhaps for worksheets with short examples that are each in a separate frame?) - to create points in the music are marked for playback, entry and editing, titles, export, import etc. And regions would be for composition, arranging and for temporary or inbuilt conditional edits.

With regions being able to be merged or moved it would mean that you wouldn’t absolutely need a Merge Flows command - instead you could move regions one by one into the neighbouring flow (if you had that capability would a Merge Flows command really be a much bigger change?) and when a flow was emptied of its last region it would be deleted automatically.

Regions could be visible in a list via a side palette like Markers and nameable only there. And reorderable there too. Click on a region in the palette and the score jumps to its start - it’s another form of navigation (along with two commands - Go to Previous Region and Go to Next Region?). Drag a region up and down in the palette and the region changes its spot in the order and music moves in the score. A thicker line between two regions indicates the start and end of a flow. Imagine you are making a worksheet of scales and the scales are all entered in the one flow. And then imagine you decide to change the scales from being in alphabetical order to being according to the cycle of fifths. Regions will help with tasks like that.

I can see a lot of compositional power and real world practicality in this feature. I am sure that a good percentage of those entering music into Dorico are either still composing or still arranging - both of which would benefit from moving optionally named chunks of music around as easily choosable units.

Dorico is the first music notation word processor in the world as far as I am aware - why not provide these features to ensure that it is so to the fullest possible extent?

Another thought - you currently have linked objects such as dynamics - what about “linked notes”. Linked notes could for simplicity of interface only be added while doing step entry on more than one stave at once - a key command would turn on link rhythm and another command turn on link pitch during entry. If the user forgets to create the links during multi stave entry they cut the music - then enter multi stave entry and then paste with the relevant pitch and rhythm settings set. Changing the octave of notes linked by pitch would not unlink them.

Linked notes would only be able to be created for notes which were in bars with exactly the same time signature or in the case of both metred and unmetred music which started at the exact same point in time. To see which notes are linked you could choose a note on a stave and both the linked notes on the same stave and other staves would highlight in a secondary highlight colour. Or just the beams in the case of notes linked only by rhythm and just the noteheads for notes linked only by pitch. A single link could only include horizontally adjacent notes although rests within a bar could be acceptable - the issue is making sure all notes part of a link are seen - to ensure no unforeseen consequences linked notes would not be able to reduce the width of the music in time as happens in insert mode - so insert mode would have to be off to edit linked notes?

If you changed the length of a note linked by rhythm to other notes (those on a different stave or different voice) then those notes would also change rhythm. And the same with changing the pitch of a note linked by pitch to other notes.

The issue I see with this idea is with manual staff visibility causing linked items to be hidden. How is this problem handled currently with linked dynamics on hidden staves?

2 Likes

While I get the concept behind flows and see many instances where it is useful, I personally find it distracting. I like one song to be one entity (as in one Sibelius file) and the fact that I have a mini-song inside a song I’m writing drives me bonkers. When naming my song I have to get rid of the flow title first so I don’t see it by fiddling with the tokens and it’s just a royal pain. Could you please release a version of Dorico without flows : ) ?

You don’t have a mini-song within a song: you have one song in a project document.

It’s easy enough to configure the Layout Options to what you need. You can either import a Master Page Set with the frames and tokens you want, or you can use a document template with everything set up.

Dorico has to cater to everyone making music: some are writing songs and some are writing symphonies. Some are using using esoteric notation forms, with different tonal systems and more. Creating a different version of the app for each style of customer is too much work, and unnecessary.

1 Like

If you don’t need the separate “1. Flow 1” flow heading in addition to the project title, make sure you hide flow headings rather than working around them! And as tempting as it can be, don’t just delete the green text frame.

If you know you’re unlikely ever to use a project that needs flow headings, you can save your layout options with flow headings hidden as default.

1 Like

Hi Benwiggy.

Thanks for your reply. I was joking when I suggested they make a version without the flows and, as I wrote, I get why most people embrace the concept of flows. It’s just that I feel there is an extra (and for me an unnecessary) layer of organization which I find surprisingly off-putting. I am aware of the different ways I can go around the flow, but it’s still there, lurking silently and making me uneasy. This is one of the key reasons I find myself liking Sibelius better, another one being the lack of empty bars in the beginning of an empty flow. The lone quarter note rest frustrates the crap out of me! I want at least 8 empty bars of 4/4 time in C major, thank you. I am aware that there are ways around that as well but honestly, I don’t think I’ll ever become a good convert. It’s the little things.

All those years with Sibelius have permanently affected the way I like to work and since I am a stubborn and lazy dimwit I see no way out of this. The greatest thing about Dorico is the ease with which one can change bar numbers. That is really, really cool.

There is a certain amount of peer pressure and practical issues which will sort of force me to buy this program but I guess I’ll be using it more to read other people’s Dorico files rather than use it as my go to music writing application.

I must say, however, that this forum is great and mops the floor with that of the competition.

Thanks for taking the time to write to me. Have a nice Spring.

Since this is a professional forum, I will really try to resist being snarky here.

What would you rather see in a blank project? I’m wracking my brain trying to imagine what would be less intrusive or condescending. Empty bars with a pre-selected time signature that you had to change?

Usually the first thing I used to have to do in Finale was to change the time signature from 4/4 to whatever I was writing in. Now that was annoying.

1 Like

Hi dankreider. Thank you for your reply. One has to pick a meter and a key anyway, so changing a pre-existing one or creating a new one is the same amount of work. And since I write mostly in 4/4 anyway (and being a drummer I try to stick with the white keys as much as I can) that C major would speed up my process of getting started something like 85%. The empty lead sheet in Sibelius is what I’m used to seeing and it fits my purposes perfectly.