Never use ASIO4ALL. Just, seriously, never.
an impression:
is not about VCV Rack (Iāve still to use it or compile it on M1)
My company gave me MacBook Pro 13 M1 8Gb
and sincerely I donāt like the memory manager
I use BBEdit and VSCode and IntelliJIdea CE (and sometimes XCode) all together adding some Safari pages + 4 or 5 terminals with shh connections to remote AWS
and times to times I have to shut down all the app, because the memory starts to do a lot swapping
(never experienced with macbookpro 2012 16gb)
IntelliJIdea grows with the use, after 4 or 5 compilations and 4~5 hours of editing starts to use around 5Gb of memory I hope they correct it and make it M1 silicon aware
(I told my son Alberto (that uses Ableton and a lot of plugins) to buy directly the 16gb)
2 Likes
Well in Windows if you want to use the USB Audio from a TR-8S alongside an ASIO interface then thereās not much option. Itās the only way I found to bring in all the different discrete per drum audio channels.
im waiting for the M1X mac mini. i have a 2019 mbp but honestly dont like it for music production. was about to get the current M1 mac mini but im going to hold off for the M1X with more ports.
Seing how well the normal Intel/Mac VCV Rack version worked in my own test above, Iām not sure a native version is needed. At any rate I would probably have it quite far down my own priority list. But for an enterprising hacker it shouldnāt be too difficult to quantify how big a difference a native version would make for Rack specifically. Pick out a couple of open source modules that would be representative for the kinds of plugin code that runs in Rack. Install the normal Intel/Mac version of Rack and also compile a native version of Rack, and the selected plugins, according to the official prescriptions. Then make a largish patch with the selected modules and measure the CPU usage of the patch on respectively the Intel version and the native version, under identical conditions of course. The percentage difference between the CPU usage of the two scenarios should give the āperformance boostā obtainable for a native version of Rack. My unqualified suspicion is that it would be much lower than most people might think, because Rosetta is that good. If I were Andrew I would think something like āanything less than 10% is not worth bothering withā. It would be interesting to know that number, so who says āchallenge acceptedā? 
I think the āgoodnesā should just be assesed by how the Intel/Mac version is working on the M1 machines right now, and then compare it to some other machine one might be contemplating. And then take any possible future speedup by a native version as a welcome extra, but donāt count on that, just measure and test whatās there now.
1 Like
I think that what you are simply describing is the inescapable truth that, if you run several memory heavy programs at the same time, you should have enough RAM for them, because swapping is always bad. This is a truism no matter what operating system one is using.
Having run both Windows, Linux and MacOS for many years, I would say that where memory management, and resource management in general goes, MacOS is far better than Windows and perhaps slightly worse than Linux, depending on setup.
Iām pretty sure an M1/native version wonāt make any difference at all to the memory usage. Sounds like the program is simply a leaky memory hog and only the developers can fix that. Thereās nothing magic about the M1 ARM instruction architectureās use of RAM. The only āmagicā, if you will, is in how efficient and performant they have made that ARM SOC and packed all the stuff in there, but thatās the same hardware package being used both under Rosetta and native.
Definately! No matter the machine and the OS, for any serious use today, donāt go below 16GB of RAM. Because you always end up using multiple programs for that at the same time, and you wanāt to think about being a little bit āinsured for the futureā.
1 Like
Thereās always waiting for āthe next better thingā but itās not a winning recipe for having something nice today 
Most of us end up having a USB hub anyway, because thereās never enough USB ports for all that crazy gear we have, and that will work just fine on the M1, as well as anything else. And if youāre crazy enough to want to drive more than 2 HIRES monitors from the M1, thereās efficient hubs allowing you to do that as well. I can supply you video links on that, if you want.
2 Likes
you are right @LarsBjerregaard, thanks to your M1 testing and also @Eurikonās info I decided to go for the Mac Mini M1 and itās an amazing machine. Combined it with a Lunadisplay hub and now I can use my iPad as a second screen and even use the touchscreen to drag cables in Rack. Love it!
4 Likes
Good to hear Jeroen! What configuration did you go for? And does it run smaller or larger patches than you expected/dreamt of? Any examples of large patches youāve run on it?
Definitely running very large patches. And after using @dimdeepā s Rack Hack it just flies! Compared to some patches on my intel xeon 3.46ghzx2 which used 115% CPU compared to 15% on the M1. I used your testing patches and itās similar to what you expect. I did go for the 1TB 16Gb version. Mostly need the RAM for using samples and some VST stuff. When those new Macbookās get announced, I am ready for the LIVE setup of my dreams, haha.
3 Likes
Oh, I understand, but itās just not worth it, and they donāt stay in sync anyway.
You can use Blackhole/Virtual Audio Cable and Asio4all in a combined way functioning as one Soundcard. I then Use Bitwig to send out a pulse sync through blackhole into VCV Rack. And use Bitwig as the MIDI sync to the TR8 or let TR8 be the master clock for Bitwig and everything syncs pefectly.
Only after hours and opening new VSTās can make the sync pulse to VCV sometimes loose, but then I send a reset pulse from Bitwig to VCV and all is instantly sync again.
I do work on a Mac, so I do this as an aggregate device, but I know you can do it also with Asio4all and Blackhole/Virtual Audio Cable combined in Windows.
I was confused at first as the only Blackhole Iām familiar with is the Eventide reverb. ASIO4ALL also means poor latency compared to āproperā manufacturer drivers and I just find itās generally less stable. I think Iāve determined to move off Windows, but Iāll see if āWindows 11ā has anything up its sleeve.
I agree that Windows in combination with multiple audio interfaces is problematic. I just donāt understand why all the manufacturers do not use the workaround which elektron for example uses with overbridge. Why not develop a VST-Adapter which inserts the audio coming from the device into the tracks? The same goes for outputs, just use a VST to route the audio to the devices. I donāt know how bad the latency issue with this solution is, but it seems to be working fine.
Sorry for off-topic, but sometimes I think they are all sleeping on their billionsā¦
2 Likes
For sure if you do use windows (I do) itās good to use audio devices with good drivers. Thatās why when I was looking for a cheap USB thing for my new PC I went with Steinberg instead of Focusrite. People seemed to like the drivers better (on windows).
Funnily enough the thing giving me most trouble now are the USB devices that donāt need a driver, the āclass compliantā ones. Everything worked great for nearly 3 years, but something recently screwed up how it deals with the devices so none of them work. Audio ones that is, drives etc still work.
1 Like
I donāt know enough about driver architectures and more to know how this stuff works, but Iām guessing that windows class compliant built in drivers donāt have native asio?
This has been worth the price for most of the USB devices that have ever given me trouble.
Blackhole only exists for MacOS as far as I can determine. How would this help anyone on Windows?
Oh, thatās neat. So that will substitute for the built-in windows driver? That sounds worth of a post of its own!