It seems to me that EVERY layout window should have its own playback cursor. By default, the window should be “synced”, meaning that if any other window initiates playback, then the synced window will adjust its playback cursor to scroll along with the window that initiated the playback (which is how it works today.)
But if the user, toggles playback sync off, then the non-synced window(s) would retain their previous playback position and would not scroll along with the window that initiated the playback.
That seems like a very straightforward way to operate. I think we are saying essentially the same thing.
This would allow the case where we want to see two parts of a flow. It also would allow a person to keep open windows for different flows without the windows all jumping to the same playback point.
Just wondered if development of LUA scripting had featured anywhere in this most wanted list. I imagine it is fairly low on priority lists but I know it gets the odd question raised in the forum from time to time. I’m assuming it would be the door into third party scripting for Dorico but at present that door seems to be shut or at least has no key. Thanks
Couldn’t find this anywhere - improving Follow Playhead during playback (Page view).
At the moment, off-screen music is only brought on-screen when the playhead encounters it, even if that’s mid-bar. However, I would prefer that when the playhead meets a system that is not completely on screen, the scroll occurs at that point so that the whole system is visible.
This is a different request from the idea of locking the playhead to the centre (often discussed). It’s simply bringing the one-off scroll forward in time, not doing continuous scrolling.
When exporting pdf:
please make possible to set the Destination folder as “./” or “{@projectdir@}” or something similar.
Sometimes I move dorico files around and then when exporting pdf I end up with files in various locations… Usually I just want exported pdfs in the same folder as the project file.
I second that. I rarely create any Dorico project from scratch. Almost always I copy in a template. But those templates have the old export locations for every layout. I have to be careful to change all of them. I will always want my exports to go to the project folder. I would never put them anywhere else. This is a little item, but it could really make a difference, especially to new users who are struggling to get comfortable with Dorico.
Various local Hide properties are currently inconsistent across items and it would be good to have a consistent naming and property for Hiding things. Specifically I want to hide tempo changes like “rit”/“accel” which are used for simulating humanistic playback (for easier formal score reviews) yet I may not want these tempo markings to be visible on the score (because they are not intended as markings for humans). The tempo mark q= can be hidden under a differently-named property (“Metronome mark shown”) which should simply be renamed “Hide”. I can probably change the font and lines of “rit” to White using the Color property property to make them invisible, but that’s not a proper solution. Additionally the Line style could/should have an additional property setting of “(none)”.
Here are some screenshots of the various “Hide” properties showing that these functionally-similar properties have different (and a bit confusing) UI property names across different notational items, or may not be available at all on some notational items.
It would be more proper/consistent if there were a single universally-named and universally-placed “Hide” slider available on all notational items, similar to the universal property of “Color” or “Scale”.
You may have better luck at humanizing the playback by adjusting things in Play mode. You can manipulate the tempo there, and it removes the need for score markings. My be quicker, as well.
The door isn’t actually locked on scripting, but it’s dark in there with no light switch. I feel too much like a burglar waiting for the sharp teeth of a large dog. Or maybe a mummy.
I would love if the team would concentrate more on the notational part of the software instead of putting so much efforts into making it also a daw.
things like (partial list…) :
SPEED (I understand all the explanations I read about this, but nevertheless, this is a very slow program in some areas)
Cross staff notes between any kind of staff
Straight flags drawing from beam primitives (do be able to do straight flags of choose your own angle)
Bracketed rests
Temporary 5 lines staff cues in any unpitched percussion staff
Courtesy accidental on tied notes from previous system/page
Dynamics editor to make any combination of symbols
Add an arrow as a possible ending for a Pedal line
Possibility to hide a group label bracket if there is only one player in the group
Revamp of the “manual show/hide staff” to have a more compact UI of the list and anchored in the right pane in stead of a modal window. Also add a scope to the function instead of the current reset system.
Lua API !
And my number one choices :
Automatic, dynamically updated and aligned “show/hide” instruments staves in facing pages
Revamp the horizontal spacing editor in Engrave mode to allow grab and move of items (or select opt/arrows) with the option the show/hide the underling current system of vertical blue lines. (I honestly get serious panic attacks when I open this editor in my dense orchestral scores)
Fermatas that only go over the appropriate beat(s) of long notes or rests. (I.e automatically break whole rests into smaller rests and/or whole notes into tie chains of smaller notes as needed to show precisely where the fermata goes.)
Option in note input to tie the most recent note back to the previous note. This would help immensely when writing durations that are visually some non-dotted note tied to some dotted note. (Plus general flexibility.)
Option to break one tie in a long tie chain without disintegrating the whole chain.
Ability to access properties panel options from the jump bar.
Ability to assign key commands to playing techniques and ornaments.
Improved automatic vertical spacing between systems.
Flexibility in staff order on a per-flow or even per-system basis. Especially useful for musicians doubling instruments where the two or more instruments they’re playing belong at different positions in the system.
Greater ease of hiding note heads and stems in Write mode. (It would be intuitive for me if the option to hide the note head were in the same right-click menu as the other note head options, for example.)
Aleatoric/Box notation.
A huge luxury item that probably is not in high demand, but I have to include it : automatic lever tracking for lever harp, similar to the existing phenomenal pedal tracking for pedal harp. Would be great to have Dorico warn me when the levers don’t allow for what I’m writing and help me work out what lever changes should happen when.
Many thanks to the team and I look forward to seeing what they’ve been working on!
In addition to lever harp, another rare variety: single-action pedal harp (generally in Eb). Not a very high priority, but I encountered one recently, and did some arrangements for it.
It would be nice to have the “Avoid collisions” property on lines. I have started using lines instead of playing techniques on some drumset parts where I want to indicate “Play 13 bars swing”. Using PTs for that has lots of problems, especially that Y offsets are lost at page breaks, which really messes up the scores. I think lines work better with fewer side effects. But when I select the “Placement: Inside staff” property, that really is what I want. If there are other elements in the affected measures, the lines might not go inside the staff because of collision avoidance.
====
On edit, it may not be accurate to say that the Y offsets are lost on page breaks, although that is the practical effect. Perhaps it is a case that when there is a system break, the continuation of the PT construct (a wavy line extending multiple measures in my case) may require a different Y offset in order to float to the middle of the staff in the continuation. That is to say, collision avoidance may determine a different natural Y position in the continuation compared to the beginning of the PT. And as it is only possible to have one Y offset for the entire PT, the continuation will be wrong. And if you change that value in the score, then the part will be wrong. Basically, PTs just aren’t a good solution for that particular task.
: automatic lever tracking for lever harp, similar to the existing phenomenal pedal tracking for pedal harp. Would be great to have Dorico warn me when the levers don’t allow for what I’m writing and help me work out what lever changes should happen when.