“Compiling” is taking your Swift code and turning it into a series of instructions for a given CPU. Apple Silicon is an entirely different CPU from Intel ones, with entirely different instructions. Existing Intel binaries won’t work unless they are ‘translated’ into instructions that the new chips can understand. Apple provides a translator as part of Big Sur, but it seems that the results may not be good enough in some aspects that mean Dorico can’t usefully work.
The audio and MIDI features of Dorico have to work in real time. That introduces an extra layer of possibilities for problems compared with non-real-time software. Just doing the right thing isn’t enough, you also have to do it at the right time.
But aside from that, the OS is “just a program” and may have a different set of bugs and features that appear when you use completely different hardware. All the Intel family of CPU chips in Apple and Windows PCs are basically similar, but the Apple Silicon CPU is completely different.
Plus, even when everybody follows published standards without making any errors, the standards sometimes leave some unintentional wiggle room. One example I discovered (the hard way!) was that in one programming language, the specification didn’t actually say what was supposed to happen if you opened an existing file and wrote new data to it, using the default options for everything. Every implementation so far had done the same thing, namely overwrite the file from the start, until some creative computer vendor decided it would be more fun to append the new data to the end of the file instead. They refused to change that to be consistent with everyone else, because “it was compatible with the ISO standard” - even though it was incompatible with their own previous implementations on products they were still selling!
So we had to write code that worked out whether it was running on an ABC machine with operating system version XYZ, and do something different in that one special case…
OS does not execute a program, it only schedules it to the CPU which executes the actual instructions. Think of OS as the DAW which just orchestrates midi files and the CPU as VST which is actually executing (playing) midi commands.
And why do you need different version for apple silicon, windows and mac on intel? Think of it as VSTs with different key switches requiring different epxression maps. E.g., midi output for spitfire will not produce the same result as for vienna sinfonic orchestra. It’s actually much more complex, as even “midi commands” of the CPUs differ, but you get the picture.
Also, if you did just simple programming, it’s likely you did it in a language which is actually interpreted, which makes the program CPU and OS independent (but requires an interpreter/vm for each of the combos).
Thanks for the info! It helps to paint a clearer picture for me!
Robby
I wonder if it is really usable, at least for light works. On VirtualBox, it seems that a Mac guest is not yet usable. Is it under Parallels?
I kept my old Mac mini 2012 as a safety machine. Connected via gigabit ethernet to my Mac Pro, with Screen Sharing it can appear in a window among the other windows. Fast as if I was working directly with it. This is another solution I may use, even if I would have liked to keep everything in a single machine.
But, all considered, keeping the external mini switched on next to the main computer is not so different than having an additional external drive attached.
Paolo
I found this old thread, and want to update it with my experience with Parallels Desktop. It works. I very recently updated to the latest version, and it seems that my virtual Sierra machine works fine, and CS6 with it.
Paolo