Idea: Signposts for automation

[SampoKasurinen]

I think it would be really useful if in write-mode user could create a signpost for automation, for example:

CC11=100

That would then simply show as a signpost in score and set CC11 to 100 at that point.

This would be ideal for example to control volume, tuning or any other fine-tuned parameter where it doesn’t really make sense to create multiple entries for expression maps. Big benefit would be that all edits would be clearly visible and editable in the score, but also easily hidden as other signposts are.

After working for well over a year with vst -libraries and dorico I’ve learned to avoid using automation lanes and keep expression maps as simple as possible. The problem is that I tend to forget what I have added to automation lanes and then wonder why the playback is acting weird (after the music is edited, moved or even deleted and rewritten). Therefore I try to work in a way that all playback information is visible in write mode (or in the properties of notes or dynamics). For me this would be a powerful tool that would simplify working with multiple libraries.

I’m thinking that this automation -signpost could be added via popover (perhaps playing techniques -popover)

[dspreadbury]

Thanks for the feedback. However, although I understand the problem (you find it hard to know where you have added controller data when you return to a project later on), I don’t think this is the right solution. Making the presence of controller data in general more discoverable is probably the right approach, and I’ll think about how we might be able to achieve that in future.

[SampoKasurinen]

Thank you for considering this!

Visibility is one challenge for me, but at the moment even more important is the speed of adding and editing things in automation lines - it is incredibly slow compared to working with playing techniques.

For example adding a simple CC2=1 to a string section is literally difference between seconds and minutes between these methods. (And the same is true also for deleting those markings…)

On the other hand, it takes quite a long time to set up a playing technique, playback technique and a new entry for expression map for something simple such as CC2=1. If there are multiple libraries with multiple expression maps in use, this can also become very time-consuming task and disrupt the workflow.

[SampoKasurinen]

I thought more about how these signposts could actually work and realized that it could be very similar to how edits to tempo track are shown in write mode.

Automation signposts could have three different types:

1) Single data point

This could be added via popover or by adding a single point to a MIDI CC -line. It would show as a simple signpost:

2) Gradual change

This could be added by drawing a line to a MIDI CC -line. It would show as a signpost in the same manner as gradual tempos:

Similarly to gradual tempos, length of this line could be adjusted with key commands or dragging with mouse.

3) Automation region

This could be added by drawing or recording to a MIDI CC -line. It would show up in the same way as gradual tempos:

---

Finally, individual CC parameters that have been edited would appear in the menu where signposts can be hidden or shown:

---

Here are the reasons I think this approach would be very effective:

-Copying, moving and deleting automation data would become very fast and practical. It would allow user also to record or draw automation data and very fastly distribute it to larger section of instruments.

-Precise individual automation data points would be fast and easy to add. For example the process of setting up noteperformer section sizes via midi CC is at the moment extremely slow process which involves expanding automation lanes to huge sizes in order to hit a certain numbers.

-There would be no need to create extensive amounts of playback techniques, playing techniques and expression map entries in order to control these “non-semantic” vst -parameters (such as section size, volume, tuning, vibrato…). This would help to keep expression maps more simplified and easier to edit.

-Like mentioned earlier, automation data buried inside play mode would no longer cause problems, as it would be very easy to detect. At the moment perhaps the only types of data that exist solely in play mode are midi-CC automation and midi velocity. I think it would make sense for these to be visible in write mode in the same manner as everything else is (I’d like to have midi velocity in properties panel next to note start and note end offsets).

---

I know that many users like to use Dorico solely as a graphical program, but for me it is also a powerful tool for composition. I think this idea could provide very interesting and effective alternative for the typical DAW-like workflow with automation.

[MiloDC]

@SampoKasurinen’s suggestions here are interesting, and he’s obviously spent a lot of time thinking about how they might work in detail.

Personally, I prefer Dorico’s approach of separating notation from playback as two distinct aspects of the application. Intuitively, those aspects of the software that deal exclusively with playback (performers have no interest in MIDI messages) are laid down and edited strictly in the Play tab.

I wonder whether @SampoKasurinen’s chief aim of diminishing and streamlining the time and effort involved in making manual changes to playback – while in Write mode – might be satisfied without offending this design paradigm. (I had thought about something like a playback popover, below, but honestly, that kind of breaks the design, too, and doesn’t even address the problem of knowing where MIDI messages have been introduced while in Write mode.)

[dko22]

I can see the merits of this sort of approach – after all it’s a bit like how it works in Sibelius where the CC changes are specifically shown in the score (although there they are of course written directly into the score). On the other hand, one of the reasons something like this might seem necessary is because the complaint has often come that it’s only currently possible to view one automation lane at once in the Play window. You can’t easily see things like pitch bend and tuning together.

However for dynamics, in fact, you can see three at once if you show the velocity lane, the primary dynamic controller and the secondary – some libraries use all three at once. In most cases you can then quickly see where the problem is for a dodgy dynamic and, using the magnification tools, can look at a variably long stretch more quickly than in a score, I would say.

I suppose my instinct is, like with @MiloDC that it’s better to improve the Play window than add things to the score but as things currently stand, I can see the attraction of being able to get certain signposts added in the score. Judging from Daniel’s comment, though, that’s probably going not be the way things go.

[SampoKasurinen]

I’m glad that you and @MiloDC can also see the possible benefits of this kind of approach!

It is true that Dorico has a very systematically divided design paradigm that keeps different tools organized and easily accessible. The same discussion has happened concerning system and page breaks, which some users would like to add in write mode instead of engrave mode. In this case, I personally am happy to switch to engrave mode as it causes no noticeable delay. This is because the action itself is identical in both modes.

However, in this case I would argue that the situation is very different: write and play -modes are very different working environments which both have their individual benefits. One of the great things about Dorico is that there are usually multiple different ways to execute a certain action - every user can then pick their desired method based on their personal preferences. If same kind of effeciency (or way of working) could be achieved in play mode, I would too argue that this function should only exist in play mode (like system and page breaks exist only in engrave mode). But since these working environments offer so different possibilities, I would like to raise the question that does reaching a more diverse (and in my opinion powerful) toolset outweigh the benefits of a very systematic design.

I’d like to make a comparison to composing; a strict pre-determined system can produce very interesting results, but for a good enough reason the composer should also be able to break his/her own rules.

I would like to add, that the way of working that I’m suggesting is partly already in use: many users create their custom playing techniques that are only meant to show as signposts in their scores. Therefore the strict design paradigm has in a sense already been broken. But like I already mentioned earlier, this method has also it’s limitations (as it takes a fairly long time to set up a new playing technique).

Finally, a signpost can be set to be hidden by default, so it would not confuse some of the newer users that are still learning the inner organisation of the program. But for those who really benefit from it it would provide a powerful tool for working with automation.

I greatly appreciate how systematically dorico has been designed, but I would like to point out that some aspects of the design might become visible only after very long time of extensive use. To exaggerate a bit, it could perhaps feel beatifully organized to go to play mode to draw a single line to an automation line, but repeating that process hundreds of times under the pressure of a looming deadline might open a very different view to that functionality… But therefore it is so great that we have this forum where heavy users (which I confess to be) can give feedback to the developers!

[dspreadbury]

I’m certainly grateful for the feedback, and you can be sure that I and others in the team read and consider everything that is posted here. I still don’t think that adding hidden items to duplicate the functionality of Play mode’s controller lanes in Write mode is the right approach, but I certainly understand the underlying requirements for being able to work quickly and to know where data has been added, and indeed what data has been added.

[SampoKasurinen]

Hi!

I have been thinking about this for a while: At the moment the biggest problem (for me) with working with automation is that there is no link between the score and the automation overrides.

Ideally, while in write mode (where I spend 90% of the time), I’d like to be able to:

1. see where automation has been overridden

2. copy, paste and move automation overrides

I guess these needs could be addressed in many ways, but I just wanted to clarify that this is the biggest challenge for me at the moment: All manual overrides to automation are completely disconneected from the score. However, typically these alterations are meant to be connected with certain music in the score; therefore it would make sense that if that music is moved or copied, the automation would follow it (if selected).

I’m about to finish a 45 -minute orchestral score for a movie and managed to the whole mockup process inside Dorico. It is based on that experience that I wanted to raise these needs.

[dspreadbury]

Yes, I agree that it would be helpful for associated automation data streams to be included when you copy and paste material in Write mode. This is something we should take care of in future.

[TylerE]

One major beef I have with the current Play mode implementation is that it assumes controller data is quantitative, when in fact many libraries use it more like a function call… the exact value is important, and often only a small portion of the range is used.

For instance, NotePerformer uses CC 104 to control divisi…and the valid values are 1-8.

[SampoKasurinen]

Exactly, that is one reason why I think it would be so useful if you could also type in CC data in write mode (with a popover).