I am trialling Dorico 2.2.10 on a MacBook Pro/RME Babyface Pro setup, and here’s a list of quirkiness I wonder if I could solve:
All tasks were done in an empty Orchestral template provided by the Dorico menu (Steinberg hub).
[Metronome] Dorico’s metronome does not work (neither on recording nor playback).
[Mixer] Faders lag quite a bit when moved.
[Score] I can see the notes following my mouse pointer on score if no VSTs are connected to parts. Once I load them, I am not able to see the notes following the mouse pointer anymore. I can only see the note once I place it in the score.
I’m on a MacBook Pro 2017 (Mojave) / RME Babyface Pro setup.
I also would like to note that I have reinstalled the software to see if there was a corrupted file, but it’s not the case over here. I still experience the same issues as posted above.
Having attempted to look through and searching the forum, I’d like to add an issue that has occurred after updating today:
Chord symbols with bass notes other than the root are written with a big, empty gap between the chord and the bass note, not with a ‘/’. Also, the # is missing.
I’ll just add a snippet for clarity. The chords are supposed to be D, Em, D/F#, G.
There’s also an odd gap in the tempo marking. Please see the snippet for that as well.
Do you see the fader for DoricoBeep in the Mixer? Is any output shown in its meter when you play back? Is its output muted?
Yes, the Mixer is not the highest-performing part of the application from the perspective of the GUI. We plan to address this.
I’ve not heard of any report of this before. The shadow note always appears reliably. If you could record a screen capture video of this phenomenon in action, that would be helpful. Thanks!
Hello,
In subject of “few issues” I have one too.
I would like to signal a small, but unnerving thing, i.e the way Dorico manages saving files. I open a project (so Dorico knows where the file comes from), do a small change, push Command-S and Dorico asks me where to save it. So I have to indicate the place again, accept overwriting and for some time next Cmd-S works. But if I close the project and reopen it, we are back to the same problem.
Small, but unnerving.
Another small thing, actually, more an improvement or indication. When in Play mode we add plugins and, say, it is 5 times Kontakt and 2 times Play after some time their names say nothing, at least to me. If there was (or “is” but I did not succeed to find it) a way to add either visible description or simply rename these instances it would help a lot.
Witold
What you describe should only happen if Dorico thinks it is dangerous to overwrite the old file without warning you, for example if Dorico converted it from an earlier version of the software, if you opened a MusicXML or MIDI file, or if you are recovering a backup file or an autosaved file.
The other possibility is that somehow you are using the “save as” command (which always asks you for a file name) instead of “save.”
To answer Rob and pianoleo, I use Mac’s Command-S only, which in equivalent to “save”. When I use “save as” it is natural that I should be asked of how and where. Also, my autosave/backup folder is a separate, dedicated folder having noting to do with my project folders. Let me re-explain the case: I open Dorico, I indicate on its own list the file I want to open, I open the file, press command-S and Dorico instead of just saving it opens my default project folder. So I have to show the correct folder and once I click OK, naturally, I have to agree to overwriting, because my project resides there. Once I pass this phase all consecutive command-S work as they should. Then, when after closing Dorico I open the same file again Dorico goes back to square one. I will be experimenting and will post whatever next I will find. At the moment I consider such behaviour a bug.
Witold
Dorico will behave in the way you describe only if the project file you’re opening is being opened from within the AutoSave or Backup Projects folder, or a folder contained within either of those folders. You should really check what you have chosen as the ‘Auto-save’ and ‘Backup Projects’ locations in the Preferences dialog. It really seems to me that you must have your projects either saved in one of those two folders, otherwise Dorico would not behave this way. Perhaps you could post here, for clarification, the complete paths you have specified in your Preferences dialog, and the complete path to one of the project files you find gives you this behaviour on save. Maybe there is some way in which the code that determines whether or not the project is being opened from the AutoSave or Backup Projects folders can be fooled.
You may be right. The setup is that the folders for different categories of the projects sit on the root level of the disc, and each project has its own subfolder within its category, while backup is directly on the root level. But project folders are in no way directly linked to level of backup, so why is there a problem? I will create a separate backup folder that should separate backups from the rest of the disc and see what it gives. Will be back here once I know the results.
Witold
From the computer’s point of view, the root level of the disc is a “folder” just like the other folders you create. Otherwise, there would have to be a different way of handling “files directly on the root level” and “files in folders.”
Dorico assumes that anything inside the backup or autosave folders might be a backed up or autosaved version of something, and it stops you accidentally overwriting it by asking you to confirm the file name. So in your setup, it thinks every file on the disk might be a backup version.
In general, keeping a lot of files directly in the root level is not a good idea, since it will tend to slow down the access to everything else when the computer has to search through everything at the root level to find subfolders. Ideally, the only individual files at the root level should be a few things used by the computer operating system itself (on my Windows system there are only four of those files), and they are likely to be hidden from users by default so they aren’t tempted to mess about with them!
Rob,
My project disc is a separate, dedicated disc having nothing to do with OS disc. By “root level” I mean the first available level on the disc, which, as you rightly point out, is no different from a “folder”. I also understand the underlying philosophy of the concept of not putting projects and their backup files in the same space, but that is not very obvious. In Cubase projects and their backups sit in exactly same directory, they just have .bak extension. But that is just a question of design philosophy, as good as any other. I have tried to find info about this subject in Dorico’s Help but to no avail. Did you?
After I separated backups from projects, command-S works but still in a strange way. The first “save” after opening the project takes unusual long time of the range 30-40 seconds. The project I talk about here is empty, not a single note or plugin, just 6 players and the disk I save it on is an SSD.
Did you observe such kind of behaviour too?
Witold
I read it before even joining the subject. If found nothing about problems we talk here, no info, no warning. Did you find anything about these problems in this Version History file?
Witold
I guess it’s not explicit. However, when I read the following paragraphs I immediately thought “Dorico’s going to delete files automatically from this directory. I must not store anything I need to hang onto in this directory”.
What you’re doing is storing ALL your Dorico files in this one directory, albeit in subfolders.
