Thank you for your kind and speedy reply.
As not all music necessarily has a time signature or key, Dorico starts with neither so it does not put you in a box from the outset. If you prefer to start with a template, why not set up a project with e.g. flow headings hidden, a single player and instrument in the project, 4/4 time signature, 8 empty bars - and then use that to start new projects from (using Save As each time)?
1 Like
Thank you Lillie_Harris for these instructions. You are very helpful and I try my best not to sound ungrateful, but as I wrote, itâs the little things and no matter how much I try I just canât seem to really like Dorico. Well, thereâs still 10 days left of the trial, I shall double my efforts. But really, thanks. You guys are very, very helpful.
Ok⌠Now I have tried to work with flows for a couple of days and I still canât do what I want. And I have read a lot of threads in here and watched the videos I could find that touched on the subject.
But I have to give Philip Benjamin right in his opinion, that the videos donât help someone like me, who is new to the concept of flows. The videos I have found, does not go through the use of flows in a step by step manner. There is always something else mixed in and to me, that only makes me more confused.
After reading this thread I thought I had it, but after spending an hour with an arrangement, I use to try things out with, I am no closer to a figuring things out. HelpâŚ
What is it youâre trying to do? Do you have any example pictures that youâre trying to recreate or do something similar to? Itâs a lot easier to cover this sort of discussion in the concrete rather than the abstract.
1 Like
I felt bruised by the way in which I was responded to in this thread 18 months ago.
I felt like I encountered a kind of tribalism - that users acted as if someone who hadnât done the same amount of time with the program that the experts had done was arrogant in thinking that they might possibly have something useful to contribute - when I am quite sure that I did. It felt as if users were saying that if others have to spend hours a day on the forums to learn the ins and outs of Dorico then why shouldnât I? The answer being that a well structured app leaves the user not having to give their life to master it - we all have to use a bunch of them.
I made comment because I believed then - and still believe now - that almost all users of Dorico are composing or arranging as they use the app and Dorico 3.5 didnât seem to me to reflect that being the case - that it was limited as a composition tool. There is no area where a user can for example park eight bars - or quickly re-arrange sections of music - or try different versions of their composition. At this point some may chime in and say that flows allow that - but clearly that isnât the intention - since the user must expressly include and exclude flows from each layout. And if you ask Daniel here about flows he will tell you that they are intended to be either the main performance divisions of a piece or to be formatting divisions (because they for example enable bar numbers to restart at 1 and provide separate titling possibilities). Despite this being the expressed intention for flows the reality is - when you dig deeper (as I did in this thread) flows are actually used for other things - such as for example importing music non-destructively. But doing an import then breaks the expressed main intention of flows - it requires each flow to be unticked or ticked for all layouts. In other words flows have too varied a set of functions in Dorico to serve each purpose well.
What percentage of people have their composition completely finalised before working in Dorico? Almost no-one. Surely then Doricoâs compositional flexibility is important - and suggestions for how to make it more compositionally friendly must be useful. Instead the reaction 18 months ago reflected users either not wanting Dorico to have the flexibility of a word processor - or users being so afraid of being rejected by the forum and Steinberg that they were unwilling to speak up. It was as if users were so aware of what Dorico doesnât provide that they thought it was dangerous to say what it ought to provide. Either that or people seemed to be trained by history to have limited expectations of a music notation app - that it should be limited to printing - and primitive playback to pick up note entry errors. Yet in the coming years there will be few who are printing music at all. The need will be to present a finalised composition electronically in an app which facilitates presentation, practice and performance - including the ability to play back parts not being played by the user. I thought when Dorico was first released that the developers were seeing things in a forward looking way - that everything should be flexible - in their making entered notes not be welded to bars - but if this is a priority why would ensuring that bars not being welded to a place in the piece - or to flows - without lots of copying and pasting of bars - not also be a priority? When Dorico was first conceived DAWâs were well established - I am surprised that their capabilities did not lead those designing Dorico to think âmore DAWâ in the way they designed it. The fact that for example there might be an orphaned second time bar when we moved a section of music around shouldnât be sufficient reason for the designers to retreat from having compositional flexibility as a priority. Instead what Doricoâs designers have is a challenge - when the user moves a section which will break things the app must do something like ask the user:
- Do you want to remove the items which will break in the section being moved? AND
- Do you want to remove the items which will break in the sections left behind when this section is being moved?
And if the user chooses to keep any orphaned items they should appear in an orphaned items event list - which can be emptied by the user at a time of their choosing - the list being similar to a set of markers with each marker having its own bar number. At least thatâs my best suggestion.
Is the hope that someone be able to make two versions of an arrangement within a file - because they share a substantial amount of shared content - completely out of left field in terms of expectations?
Then there was the reaction to my suggesting that the Dorico manual could help the user see associations between concepts if it grouped features where there was some sort of loose relationship. It felt like I was being inappropriate for making criticisms of the work of a woman. Thatâs pretty sexist. I suggest now even if I did not then that the table of contents could for example group features which edit a single note - and group all those that change two or more notes (e.g. slurs) - and group all those that change one or more bars or systems. Or better groupings if they arenât the best. The issue is - which helps the user more? - to group chapters in some way - or to have most of the Dorico manual be a series of individual chapters in which every page of the manual is cross linked to every other possibly related page?
And finally I expressed the view that the new user will have particular expectations of Dorico which it would be helpful to contradict early on. For example they wonât expect that blank flows are the means by which music is imported in order to avoid making destructive edits. And they will likely expect that Doricoâs layouts will be limited to a single full score and parts - because this is how other programs worked. And they wonât be familiar with the distinction between players and instruments - nor will they likely discover it when it only becomes obvious only in Galley view. I suggested these kinds of likely expectations - and these invisible concepts - be contradicted and introduced early in an introductory video - and by using a more anticipatory tone in the key concepts part of the start of the video. (Having said this I have already explained that I believe the answer with flows is to really go back to the drawing board - to limit flows to being piece and formatting divisions - to not for example use them for scratch music or imported music). So - in summary:
- Continue to use flows as piece and formatting divisions but ensure they donât have any other uses.
- Add the concept of versions of a piece to files - versions being able to share flows or have their own specific flows.
- Add a smaller unit of subdivision of music called regions which become a list (each region being optionally nameable - Verse, Chorus, Bridge or whatever) which facilitate quick re-arrangement of music within flows - regions being able to be transferred between flows.
The result being that flows divide music for performance and some formatting and regions divide music for the purposes of flexibility of composition - and quick navigation to points in a flow.
From the reaction to my suggestions I donât expect to see any major improvement in how Dorico works from a compositional point of view in version 4. I do expect improvement with the way the manual introduces key concepts (though probably not an introductory video) - and I expect no revealing of the commonalities between the endless chapters in the notation reference (they will continue to have detailed cross linking instead of being grouped at a higher level). But we shall see.
If my suggestions find a place in a future version of Dorico that would be great - we have all lived without music notation apps being flexible in these respects for decades so I guess we are all now trained to manage without such capabilities. Whereas word processors have let us for decades easily move words, or sentences, or paragraphs or groups of pages - not just by copying and pasting - but by having an outline view.
I am like everyone else interested to see what today brings and I thank Steinberg for a period in which they have managed to release a totally full featured iPad version (I canât say I expected that!) and have no doubt also done much to improve Dorico. I am as amazed at how many things Steinberg has done which are helpful to the user in Dorico as I am eager to see my suggestions considered - I look forward to finding out about the improvements today.
PS Some might say that my comment would have been better made after seeing version 4 but if version 4 doesnât make compositional flexibility a priority I donât wish to rain on its parade.
I was surprised at the time and now by the level of some of these questions. Of course brass players donât become string players when moved to another flow. And as for the second question I would have thought that was something that would be handled by the program - that it would either make a choice or ask the user.
Why instead of raise non-existent issues - or ones that can be handled elegantly - do you not instead not acknowledge the importance of ensuring maximum flexibility with the musical content?
Dorico 4 just made this completely possible.
B.
@substanceoverstyle: youâre basically describing Sibeliusâ Ideas feature. The team is probably familiar with it.
Hello @PjotrB
My ideas have been refined since this thread started I believe eighteen months ago.
To see mine and other peopleâs suggestions for Dorico 5 - which includes I believe better suggestions for how flows could work in Dorico - go to the thread currently active called Dorico 5 Most Wanted.
I have just completed 17 flows - all separate sections in a chamber opera. Iâve tried to import the 17 flows into a new project but am having problems. The main one of which is that the graphic/text pages are being imported or at least I canât see them in the new project.
Any help/advice would be gratefully received. I have spent some time on the forum, but canât see this problem discussed. thanks
Steve
Did you do each flow as a separate project file�
Importing a Flow into a Project file just imports the music: it then inherits the layout from the receiving project file.
Manual alterations are not going to be imported; though it is possible to export and import Page Templates.
Hello Benwiggy - thanks for quick response.
Yes I did create each flow as a separate project file. Itâs a pity that flows only handle music notation
Iâd recommend keeping any âgroupâ of slightly related pieces in one project file.
Itâs easier to separate them later if needs be; though you can just use different Layouts in the same file to isolate things.
You could, conceivably, put every single piece you ever work on in one massive project file! ( I wouldnât⌠
, but it shows the power of the concept.)
Haha ok Iâll think on that
It could be useful though to be able to import text/graphics with flows - I have many multi-movement works that will have different performance instructions for example for different movements.
thanks for your help
Steve
You could put such instructions in the Other Info field of Project Info Flows and then create custom Flow Header Templates to bring the flowsâ Other Info token into the flow header itself. That should allow you to export and import that info between projects by transferring your Page Template Set(s) along with the flow information.
Thanks for this Derrek, Iâll have to look up what youâre suggesting - at the moment Iâll be honest donât understand much of it. Iâm pretty much a newcomer to the world of Dorico - having used finale for 20 something years - still finding the transition tricky.
Thanks
S
Donât worry, Iâve been spelling âGalley Viewâ as âGallery Viewâ for three years.
2 Likes