Daniel, they are just the Command key combined with the ‘<’ or ‘>’ keys. I guess they could be any other key combination. They are just handy, since they are the first ones in the lower left corner of the keyboard.
They trigger the ‘Next Window’ or ‘Previous Window’ commands systemwide. I usually use it to cycle between the Setup or Write window, and the Play window.
I’m sorry, Paolo, but I’m still none the wiser: how would using system-wide shortcuts to go to the next or previous window help you to switch between modes in Dorico, unless you habitually use multiple project windows each set to a different mode?
Dorico is freezing very often. One of the most common cases is when selecting a different track in Play mode. The spinning ball goes on forever. The Activity Monitor says that it is unresponsive, and it only takes <1% of CPU. Vienna Ensemble Pro show no sign of communication with Dorico.
I’ve attached a spindump, in case it can reveal something.
It looks as if Dorico is running as normal from that trace. Next time this occurs, please sample both the Dorico process and also the VSTAudioEngine process.
Daniel, this is the sampling of both Dorico and VSTAE while one of these freeze happened. In reality this was shorter, and lasted less than one minute. But maybe they are related.
I was choosing a different flow in Play mode. Each flow is using different VST instances. Dorico appeared unresponsive, with the spinning ball, and VSTAE was >250% of CPU. VEP was at about 80% CPU, that should mean it is also doing something (even if there is no sign of it).
This is a much longer freeze (not yet ended after a few minutes), happening after invoking the VST Instrument Edit (‘e’ button) from the Play mode.
This time, Dorico, VSTAE and VEP are all at <1%, 2.2% and 6% of CPU (so, apparently all of them idling).
In Activity Monitor, Dorico was the first to appear as unresponsive, followed after a few minutes by VSTAE. VEP was still working. To relaunch Dorico I also have to force-quit VSTAE, or Dorico can’t reconnect with it.
This time, VSTAE froze after I invoked to show the connected VEP instance (target button from the VSTi instance window). Dorico seems to also be frozen, even if it is not marked as unresponsive in Activity Monitor. (Edit: it is, after a few minutes).
In Play mode, you can’t scroll the tracks with the Up/Down keys. This would be very useful when quickly browsing through the tracks to check them, and to do repetitive tasks in the inspector.
As it is now, you have to first move the mouse pointer on the track, click on it, return to the parameter you are editing in the inspector. Very carpal-tunnel-syndrome ready!
Not exactly a crash, but I have to quit to exit this situation.
The Jump bar remains in the display, after I’ve explored a few of commands with it. I can press Esc, click anywhere, select a command, change mode, but it remains open.
Is there some further information that can help tracking this issue?
I looked and didn’t find the result. Obviously I must have accidentally started from the wrong place — I can certainly see it now and Daniel has provided a reasonable explanation.
When the Hub opens, it is moved to the latest position of a document window. Since documents are usually placed starting from the top left corner, this moves the Hub all on a side. Its most comfortable position should be at the center of the display.
I guess that the remembered Hub position should be separate from that of the documents.
The reason I use the Key Editor is because I can adjust the start and end of a note in an absolutely free way. No snapping, no grid quantizing.
With Dorico 4 I can no longer avoid the notes to start back at the original position. According to the video tutorial, this should be still possible. What am I doing wrong?
you need to change the highlighted icon at the top of the Key Editor to the playback icon length shown in the attached. The default is the two keys which is the notated length and thus quantised.