Jim Roseberry

https://www.diskpart.com/gpt-mbr/convert-system-disk-to-gpt-without-losing-data-3889.html

In Windows 10 v1703 and later, there's a command line application (MBR2GPT.exe) that'll convert the boot drive from MBR to GPT (without losing data). It's located in the Windows\System32 You can also use a 3rd-party (paid) application called AOMEI Partition Assistant Professional ($50) Before proceeding, make sure you have proper backup and read up on the necessary steps.

Hi Zo, Yes, With version 11... I'm finding performance at ultra low latency is less prone to ASIO peak buffer overloads.

Dirty Shirly or the BE-100 BE-100 is extremely versatile (real amp or model)

If you don't already have a copy of Cubase, the cross-grade is also on sale ($231.98).

FWIW, I've noticed that Cubase 11's ultra-low latency performance is a significant improvement vs. version 10. ie: With version 11, I can run Helix Native at 96k using a 32-sample ASIO buffer size (1ms total round-trip latency)... with zero glitches. Version 10 was more prone to ASIO buffer peak overloads (glitches).

Hope it works well for you! I had a 5059 Summing Mixer. Loved the sound and flexibility Couldn't get over the fan noise... so I returned it.

Looks like MS is talking later 2021 into 2022 for the Windows 11 upgrade roll-out. If you're not wanting to be a beta-tester, don't be an early adopter. There will be early issues that'll need driver updates, software patches, Windows updates, etc.

I'm aware of that... 😁 If you deal with enough quantity, you see a percentage of defective parts... across all computer components. Lately, and I think this is somewhat related to manufacturing during the pandemic, I've seen a higher percentage of defective Intel CPUs. The rate is still extremely low... but it's more common today than several years back.

Using the Samsung 980 as an example (popular/good NMVe SSDs): 250GB version is warranted for 150-TBW (terabytes written) or 5 years (whichever comes first). I've seen reports where M1 Macs were writing ~0.682TB of data per day to the onboard SSD. If the onboard SSD has the same specs as the Samsung 980, it could potentially fail after ~220 days. You should have a backup of your boot drive (no matter what you're running). With that backup in hand, I'd not get overly obsessed about it. It's a tool. Tools are meant to be used. Of course, it's a whole lot easier to replace the boot drive in a PC (vs the M1 MBP, MBA, and Mini).

Modern SSDs often have 1.5 million hours MTBF (or better). It's the number of writes that people are worried about... as those are finite.

Yes, the DAW has to allocate resources for many additional I/O channels, etc. But it doesn't consume the same amount of RAM as using separate/unique sample libraries. Let's say your lean OS install idles at ~3.1GB RAM Fire up Studio One Pro v5 with an empty project... and you're at 4.3GB Add a single instance of Kontakt 6 (empty - no libraries loaded)... and you're at 4.5GB Load The Grandeur into the single Kontakt 6 instance... and you're at 4.8GB Load a second instance of Kontakt 6 with an instance of The Grandeur. You've now got two instances of Kontakt 6... each with The Grandeur loaded... RAM use is now 4.9GB. If you load the same two instances of Kontakt 6... load The Grandeur in the first... and The Maverick in the second... RAM use is 5.2GB. Both piano libraries are a bit over 7GB in total size. I'll liken the situation to testing drive speed. Let's say the drive you want to benchmark has 128MB cache. What happens if you benchmark with a 32MB file? What happens if you benchmark with a 1GB file? With the 32MB file, you'll be testing the speed of the cache. 😉 With the 1GB file, you'll circumvent the caching... and get the actual speed of the drive. Load up 20-30 libraries that are similar in size to The Grandeur (but each a unique separate library). Report back with the RAM use and RAM Pressure graph. I pushed the 16GB M1 Mini ridiculously hard... and it did a pretty remarkable job. The RAM caching, compression, etc allow you to squeeze a lot out of 16GB RAM. That said, if you really push it... the RAM Pressure went thru the roof... and it took a LONG time for this type of project to fully load, RAM to be compressed/cached/etc. It's not ideal in a heavy load workstation type scenario... and (to me) not a real substitute for having enough physical RAM for your largest projects. To be fair, Apple doesn't market the machine for that type of use. For what it is (small form-factor, inexpensive, silent), it's a nice machine.

I specifically mentioned this when talking about running stress-tests on a "RAM limited" machine. If you load many instances of the same library, it completely invalidates the test. Why? Because the single library is only buffered once (in RAM). RAM wise, you may as well only be running a single instance of The Grandeur. To actually stress-test the machine's limited amount of RAM, you need to load separate/different large libraries.

Make sure you have a backup before installing H2. Otherwise, from our testing here... it's performing pretty well. There was an issue with Celestion's "Speaker Mix Pro" plugin (higher CPU use). I need to test again... to see if that's been resolved.

One last post... and everyone can draw their own conclusion. Here's a screenshot of the Ryzen 5950x running the full stress-test project... still set to 96k using a 32-sample ASIO buffer size. With all those large Kontakt libraries loaded, Superior Drummer 3, and two simultaneous instances of Helix Native (one being monitored in realtime with the green Z button enabled for lowest possible latency), CPU use was right about 35%. I can start the transport and play Helix Native (1ms total round-trip latency)... and play with absolutely zero glitches. I'll repeat that comparing a $800 M1 Mac Mini to a full-bore workstation running a 5950x CPU ($800 CPU) isn't a fair comparison. To run the above project (without glitches), the M1 Mac Mini had to be bumped up to a 256-sample buffer size. Overall, I thought the M1 Mac Mini performed extremely well... and especially for what it is (small form-factor, low cost). Blows a typical $800 off-the-shelf laptop out of the water. I'm used to running a machine where I can make it exactly what I want... with lots of speed and storage space. For the M1 Mac Mini to work for someone like me, it would need a Thunderbolt dock and multiple external NVMe/SATA drives. At that point, you've got a fair amount invested... (IMO) trying to make it something it was never designed to be. I wish that Apple would just allow the user the choice of 32 or 64GB RAM. I wish end users could add a couple internal M.2 NVMe SSDs. More RAM, more drives, more ports... If the M1 Mac Mini had 64GB RAM, with its current RAM scheme it would feel almost limitless. The M1 Mac Mini squeezes a lot out of 16GB RAM (using RAM compression, caching, etc). When pushing the M1 Mac Mini to the point where "RAM Pressure" was getting high, I could get it to start hitting the VM Swapfile pretty heavily. What's odd is that after sitting for a while (with the same load still running), "RAM Pressure" seems to normalize (reduce to where it's back into the green). If you're trying to run large projects, waiting for RAM to normalize or for RAM compression to be fully used/optimized isn't ideal. To Hugh's point, the M1 Mac Mini squeezes a LOT out of 16GB RAM. It's frustrating if you're approaching it as a "power-user"... and expecting that level of performance/flexibility. If you have reasonable expectations, the M1 Mac Mini is a slick, elegant, small-form-factor machine.

Certainly no apology necessary. I should have figured that one out. 🤪

How do you like it for more traditional DAW use?

Hi Larry, What product is this?

It wouldn't affect the amount of RAM used by sample-libraries. I'm sure it would be further CPU optimized.

It has to take some amount of CPU... but it's not hampering performance in the singer/songwriter example.

Now, let's push the M1 Mac Mini... and see what happens when you purposely load it down with large sample libraries (that consume a lot of RAM). Here's a screen capture with the M1 Mac Mini loaded down. The purpose here is to find out where the RAM scheme starts to break down... so yes, it's purposely loaded to the gills. Studio One Pro v5 - Set to maximum drop-out protection Superior Drummer 3 - Ayotte kit Kontakt - The Grandeur Kontakt - Scarbee MM Bass Amped Kontakt - Scarbee Pre Bass Amped Kontakt - Symphony Series Percussion Kontakt - Session Strings Pro Kontakt - Symphony Series String Ensemble Kontakt - Symphony Series Brass Ensemble Kontakt - Symphony Series Solo Brass Quartet Kontakt - Session Horns Pro Kontakt - Symphony Series Woodwind Ensemble Kontakt - Symphony Series Solo Woodwind Quintet Audio track for guitar - Helix Native loaded (using same patch as in singer/songwriter project) Audio track for bass - Helix Native loaded (using same patch as in singer/songwriter project) With the RAM compression being implemented, it takes a good while for this project to fully load. I'd say a good couple of minutes. Note that this isn't reflected in the Studio One Project, you have to watch the results in Activity Monitor. With the same 96k 32-sample buffer setting, there's regular buffer overloads (glitches). This isn't surprising given the load at 1ms total round-trip latency. To eliminate the buffer overloads, you have to increase the buffer size to 256-samples. At that point, you can play The Grandeur and it's completely glitch-free. Notice that the Memory Pressure graph is now well into the orange. This is about as far as you can push the RAM scheme with the 16GB M1 Mac Mini. To push things even further (RAM wise), I opened Chrome with several tabs. This is when the M1 Mac Mini started to use the VM Swapfile It starts paging ~35MB... and over time creeps significantly upward (it's now up to 2.66GB) ≈

On to a few audio project examples To achieve as much disk-speed as possible, I connected an external M.2 NVMe to the second Thunderbolt port. Audio tracks and samples are streaming from this drive. Note about memory: The M1 Mac Mini isn't making use of the VM Swapfile... until you load it down pretty heavy. (More to come on this) As expected... at that point performance goes down significantly. What the M1 is doing is making use of RAM compression... to eek a bit more out of 16GB. I've got several instances of a stress-test... from heaviest load to more of a simple singer/songwriter demo. Here's a screen capture working on a simple singer/songwriter type demo. Studio One Pro v5 - Set to maximum drop-out protection Superior Drummer 3 - Ayotte kit Kontakt - The Grandeur Bass (recorded DI) using an instance of Helix Native Rhythm Guitar (recorded DI) using an instance of Helix Native Guitar Lead (recorded DI) using an instance of Helix Native 12.45GB (of the 16GB available) is being used.I The Studio One project is running at 96k using a 32-sample buffer size. With one (of three) instance of Helix Native being monitored in realtime (to record the guitar lead), it was pushing the M1 Mac Mini just about to the point where it'll glitch. Note that Studio One's green Z button was enabled (for lowest possible round-trip latency. After overdubbing that last guitar part, turning off realtime monitoring of Helix Native drops CPU use down to about 25%. That would give you plenty of headroom to overdub vocals/etc. The M1 Mac Mini performed very well in this example. I was able to record all the above with zero glitches... at 1ms total round-trip latency. In the above picture, notice that the Memory Pressure graph is in the "comfortable" green zone.

Studio One Pro v5 loaded (no project loaded... just the DAW app itself) Only other thing open is the Orion Studio Synergy Core's control panel applet. RAM use is 8.21GB

Back to the M1 Mac Mini with 16GB RAM Standalone instance of Superior Drummer 3 with the Ayotte kit loaded. Only other thing open is the Orion Studio Synergy Core's control panel applet. RAM use is 9.8GB

This is borderline silly... I got the 16GB model to test... because I know the 8GB version would be limited (by comparison). Hmmm... why would Apple offer a 16GB version of the M1 Mini... if the 8GB version offered identical performance/capability??? The reason is obvious... I've built audio/video specific machines professionally for nearly 30 years. There's no way paging the VM Swap-file (on M.2 NVMe SSD) in lieu of enough physical RAM comes at zero performance penalty. Unless Apple has re-written the laws of physics, it's not possible. Clearly, the onboard SSD is not performing at ground-breaking speed. What would be different if I tested the 8GB version? The difference is that it would start hitting the VM Swap-file sooner. In either case, I'd push the M1 Mac Mini to use more than the installed amount of RAM (causing either to page the VM Swap-file - which makes it a moot point). Currently loading large sample libraries onto an external M.2 SSD (attached to the M1 Mac Mini). Detailed performance examples to follow...