Have you tested just running under a VM rather than on the base OS of the machine?

If so were there any latency issues that made you decide not to do that?

On Windows we just install the latest VM manager on the base metal and run everything else underneath.

That lets use run everything from MS-DOS to CP/M and all versions of everything else without having to worry about driver updates and stuff on the base machine.

Have you tested just running under a VM rather than on the base OS of the machine?

"I tested Ventura before as a VM ..." was indicating precisely this.  I ran Ventura as a guest OS under the host OS of Monterey.  The purpose of this was to check that my Montage and the driver stack on the guest OS (newer OS) would recognize Montage, Montage Connect, Soundmondo works, etc.  This is how I pre-test an OS before committing to it and/or test a new OS to inform someone else that the new OS seems to work for what's tested.   I don't have to worry about the latency because I just use it as a verification step and not a daily driver.

Even though I tested Ventura probably over a year ago, I still kept running Monterey (an older version of MacOS) since there was no compelling reason to upgrade.  Latency wasn't an issue -- I didn't need to run the later OS for any reason.  I've got Cubase and everything running just fine on my bare metal older Monterey OS.

Non-music compiler toolchain dependencies are pushing me to the newer OS.  I don't want to just use a VM for my toolchain.  That's a huge waste of space.  On MacOS Xcode is a monster of an install and having this under a VM would mean I have two such monsters simultaneously installed.  If I had unlimited funds, I'd buy hardware with massive space but I have to compromise within my means.  I've considered the merits of external storage and other "schemes" - but none of that would be helpful discourse for me or anyone else.  My decision is to upgrade the entire OS to an "n-1" version where "n" represents the latest version that seems to work OK for music (Yamaha drivers, DAW software, etc) purposes.  Even "n-2" is available since I've already tested that it works fine for likely all the things I do.  However, as mentioned, I want to keep the fuse of a supported OS lit for as long as possible.  Skipping a generation seems reasonable.

On Windows we just install the latest VM manager on the base metal and run everything else underneath.

It's no different on a Mac.  And this is an Intel Mac - so it's really close to exactly the same.   For this OS preview - I'm doing different things with my VM usage.  So you may be talking past me ("talking past each other" ) given there are different goals and usage in mind of the VM usage I expressed for my own OS testing.  

That said, I understand your usage because I have other VMs that are geared for that kind of "daily driver" usage.  Not just a one-off test to prove something.  And I don't see any latency issues because generally I'm carrying some old piece of software forward that needs a lesser OS that suffers less from the hypervisor/VM overhead and originally didn't have the benefit of SSDs or the better underlying CPU/memory.  The software devs of the time were working on weaker systems and therefore optimized for those so the VM experience is transparent minus perhaps some things that get lost in translation like key bindings and occasionally mouse precision which seems to be an unresolved bug of the notation software when used in a VM.   All of this straying from my original message, however.

Maybe I mislead you when I said this:

On Windows we just install the latest VM manager on the base metal and run everything else underneath.

I didn't mean that literally for our entire shop. We provide support for customers that have a wide range of hardware and software versions. Even for the same piece of software they are often on different releases. 

Rather than maintain our own bare metal matching hardware/OS for each customer we use a VM for each customer. Our various customer VMs aren't of the 'daily, continuous use' type - they are just used for support when needed.

Using VMs isolates us from hardware issues if actual hardware/cards/etc were being used. Some of that older, actual hardware can't be acquired easily or at all.

As you allude there are things that are best run on the bare metal host especially if latency is a possible issue or when tools .

Any two chains that need to communicate (e.g. your toolsets) need to be in the same environment (either vm or non-vm) to function effectively.

We find VMs to be most useful in supporting tool chains that we want to isolate from changes that need to be made to other components or to the bare metal machine/OS.

Things like video compression and video/audio format conversions aren't well suited for running in a VM as the interpretive nature of vm has too much impact on performance.

I don't want to just use a VM for my toolchain.  That's a huge waste of space.

That's certainly an important point. Using a VM pretty much dictates that there will be a bare metal OS and a separate OS within each VM. And 'dual boot' isn't always available as an option.

Comprehended what you said - but as I mentioned:  your bias (I've used this term before and you seemed offended by it - but it's not a negative word.  Plants are biased toward the sun.  Transistors are biased through termination.  etc ...) has set a certain paradigm of use that doesn't necessarily apply to others.  So it's easy to talk past each other when espousing preferred use cases.

A 'preference' is not at all the same as a 'bias' - you seem to be conflating the two terms. The path from a preference to a bias often begins when one stops considering/accepting other options or opinions.

If you carefully reread all of  my comments you will find that I was careful not to express EITHER a preference or a bias. So I'm both surprised, and disappointed, that you use the phrase 'your bias'. I've always thought you were more open to rational discussion than that.

IMO the particular requirements of the use case(s) will dictate the suitability of the options available. Then any preference/bias might come into play when considering how well the best 'technical' solution fits into the rest of the existing framework.

An example from the very early days of the electronic musical world would be if the best technical solution might be to use an Apple product but the existing infrastructure doesn't include any Apple products or persons with experience with those products. Apple/Mac was the early high-end pioneer for that but has since lost most, if not all, of its advantage.

I was merely inquiring if you had considered the option of using a VM for the music-related stuff rather than having to be concerned with whether it would work properly on a new OS. I didn't suggest that you should be using VM or that you should not be using VM. 

I have a bias based on my usage, resources, etc.   Bias isn't a bad thing.   If you want to call it a preference because this is less triggering for you, then fine.  My goal isn't to offend you (plural) but sometimes it's unavoidable.