I didn’t find any specific post clarifying the question
My suggestion for a stress-free trial:
deactivated properties show their automatic value - activated properties show their currently edited ( or recorded ) value.
Deaktivieren der Start/End-Offset und Velocity Eigenschaften sollten editierte Werte nicht löschen
Ich habe keinen speziellen Beitrag mit Klärung der Frage gefunden
Meine Vorschlag für stressfreies Ausprobieren:
deaktiviere Eigenschaften zeigen ihren automatischen Wert an - aktivierte Eigenschaften dagegen ihren aktuell editierten ( bzw. aufgenommen ) Wert.
When you deactivate a property, Dorico removes the value, so it’s not possible for it to remember it without a significant design change, which is very unlikely.
I don’t know whether you’ll be familiar with this English idiom, but I think you’ve rather gone off the deep end in terms of your replies here. Not all of the suggestions made by users can be practically implemented, but we take as many of them into consideration as we can, as early and as often as we can. I think your characterisation of Dorico as “sloppy” and not taking problems seriously is pretty unfair – though you are of course entitled to your opinion.
As for your original suggestion, I’m sorry to say that I misunderstood you. You want Dorico to show the prevailing, current value for a property when it is not activated, rather than to remember the value that it previously had after you deactivate it. This kind of thing has been requested before: it would be useful if Dorico could set the initial value for a property after activating it to the prevailing value. We do this in a few places, but it requires significant custom work for each type of item and often even for each individual property, so it’s not something that can be simply done. We don’t rule it out, of course, but in practical terms it’s unlikely that we will be able to address this in a thorough way any time soon.
I’m sorry, but we’ll have to agree to disagree on this point. When you deactivate a property, the value is deleted: it’s no longer needed. If you want to keep the value, don’t deactivate the property.
Perhaps you can say a bit more about why you think it’s important that Dorico retain these values when you deactivate the property so that I can better understand your needs?
If this is true for you, then why are you attempting to use a tool that is specifically designed for the production of formal notation for your compositional process?
Your described workflow appears to be ideally suited to Cubase (or other DAW). And it occurs to me that your efforts to bend Dorico to meet your needs are destined to be frustrated.
I wondered about this one day in the first year of development. It is absolutely not sloppy programming. It was a design decision from the start. The Properties function as overrides for the preference settings – not as alternatives you can switch on and off that get stored with the document whether they are in use or not. I can tell you that this complaint will never get anywhere with the Team. Dorico was designed this way.
Mark, thank you for this comment - I’m trying to understand the point the OP is trying to convey, and this was helpful.
If I record a MIDI sequence, Dorico derives the notation from it by quantizing the MIDI and displaying the result.
So, in some sense, Dorico is overriding or altering the recorded MIDI sequence in order to notate it properly. But then it flips everything on its head, in a way, by considering the original sequence to be an override and the derived, quantized notation to be the original. That’s how it presents it in the properties panel.
This makes sense from Dorico’s point of view and it’s essential for correct notation, but a user might not understand this or simply see it from a different angle e.g. the composition is done and now it needs to be notated and mocked up. For this user, the value of the recorded MIDI is clearly very high, and s/he likely believes Dorico is more than capable with something like this.
Even more confusingly, simply enabling/disabling the offset button - without modifying the value in any way - is very likely to be understood as your typical bypass function (the on-off switch, as you noted). But instead, it results in Dorico quantizing the value for the second time, hard to the grid now, and now deleting any trace of the original MIDI recording. And this comes from just from toggling the button.
UNDO function is the only recourse, but it is limited. EDIT: I think this is a really interesting conundrum in the context of enhancing or expanding Dorico’s playback and editing capabilities and I’be really curious to see how the developers address it in the future.
“Track Versions” might be an idea from Cubase to consider for this, along the lines of “now that notation is produced, here are multiple versions, or recording takes, of how it can play back”, including the original MIDI recording by the user.
No. You appeared to imply that Dorico was not useful as a compositional tool and therefore not as advertised. I simply observed that, on the contrary, I find it a very effective compositional tool and very much as advertised.
It’s not at all what you want, but is it possible to fine-tune the recorded MIDI performance inside the Key Editor/Played Durations instead of the properties panel?
I understand this is a lot more cumbersome because it means dragging inside somewhat poorly defined space and of course this will never be as precise as typing the exact values in milliseconds.
However, and perhaps counter-intuitively, when I use dragging it forces me to try to get to the essence of the change rather than trying out hundreds of variations. It’s just a thought, as I think I do understand now where you’re coming from.
I would like to ask one further question, if you’ll allow me, @_derBertram, because I’m still not clear on one point (which I suspect is very much my own failing, so I apologise for asking you to re-tread the same ground again):
I still don’t understand why you would find it helpful to deactivate and then reactivate the Playback start offset or Playback end offset properties and have the original value restored.
Is this something you do for individual notes, or for whole chunks of the music, entire instruments? What prompts you to want to turn it off, and then turn it back on again?
Apologies for continuing on - but am quite intrigued.
Had a suggestion:- perhaps what’s being asked for is here akin to the ‘A’ and ‘B’ comparator toggle bank switches, found in just about every FX or instrument plugin these days. Its that mechanism whereby you ‘load’ a known or reference snapshot of parameters into bank ‘A’, then do some editing/tweaking and load these changes into bank ‘B’. You continue in this fashion, loading changes into bank ‘B’, all the while retaining the ability to flip back and forth with the original ‘A’, to see if you are improving/making progress or not, etc…
A temporary/interim solution granted, but if something of this kind of workflow/concept could be implemented in the Key Editor itself (snapshots.?), it might be some way towards easing what’s being discussed…
It sounds as if the old “Live Playback” feature we built for Sibelius way way back in version 3 might be helpful here: a simple switch that toggles between playing back the notation with and without any start/end offsets or performed velocities. Would that go some way towards addressing your use case, Bertram?
As I’ve tried to explain, Dorico doesn’t know the edited data once you deactivate the property: it removes the property value. That’s the way properties work in Dorico.
It may appear from the user interface that Dorico has both a separate switch for whether or not a property is set and the value itself, but that doesn’t reflect what’s going on underneath. Dorico stores a single piece of information, the property value. When it can find a property value, the switch in the user interface is shown as activated. When it cannot find a property value, the switch in the user interface is shown as deactivated.
When you click the switch in the user interface to activate it, a default property value is created. So when you click the switch again to deactivate it, the property value is deleted.
This is a perfectly valid and good approach, and it does exactly what we want it to do. It was never a design goal that a property value should be retained independently of whether or not the property itself is set. You are, to date, the only user who has ever asked for it to behave this way (though I daresay that not all users have given it as much thought as you have). So in general I believe this design to meet not only our own requirements from an implementation point of view, but also our users’ requirements.
I’m sorry that this doesn’t suit your specific requirements, but this aspect of Dorico’s design is simply not going to be changed. It would be a great deal of work for a very marginal benefit when considering the needs of our user base as a whole.