Utilizing the reasoning presented in this thread, logic leads me to the following conclusion.
If a Mac is more stable than a pc because the system is not as open. Meaning hardware & software has to be tailor for the system due to apple presenting restrictions on both.
Then a piece of electronic music equipment, with hardware & software in an entirely closed system, and everything tailored exactly for its specified usage, is ultimately the most stable thing.
I think the only thing I miss from switching from Mac to PC is no âaggregate audio interfaceâ available on windows.
Apart from that windows 10 is rock solid
I think everyone agrees that hardware can achieve more stability for these reasons.
IMO what is interesting here is not which solution is ultimately the most stable, but deciding if these devices are stable enough for critical tasks like a live show where failure is not an option.
Speaking from my experience, the probability of having an issue with my W10 computer, blowing a string on a cello, or bricking my Digitakt is not SIGNIFICANTLY different.
Another point
If you run your computer with 15 VSTs + Rewire 2 sequencers on a live show , failure probability is higher than if you run 1 VST, this is obvious.
But to give a fair hardware vs software stability comparison , what is the probability of failure of the hardware equivalent : 15 boxes of hardware, 2 sequencers. each machine with its own OS, plus a proper sync?! For hardware the rules of statistics are the same as for software, stability will highly deteriorate.
Usually when we go hardware we simplify and have a fixed setup, which is great for stability.
When we go software we are tempted to pack sessions with VSTs, try something new each time ⌠leading to a higher failure probability
I reckon lower reliability in hardware these days is partly that the hardware/components (and programming methods) being used are sometimes a bit more computer/OS-like in the first place, and the OS itself often more complicated than older gear was, but also very much to do with the whole approach to the firmware/software development.
Nowadays you can release with a âgood enoughâ build and say youâll bug fix and add features later. Of course that ends up meaning bugs that hang around like a bad smell for longer than they should, and rare / hard to reproduce bugs being left because of the effort they would take to track down in internal QA, when itâs easier to do so with a larger pool of testers customers using it.
In the old days when the firmware was locked down before it left the factory, it had to be as right as you could possibly make it because you couldnât fix it later. You could still make sure the OS & firmware is rock solid - and thatâs easier to do on a fixed hardware configuration than on a PC/mac - but it would most likely mean longer development, fewer features, or a higher retail price. Imperfect reliability, where it occurs, exists because it is considered an acceptable compromise by the manufacturer.
I donât think this thread would be a topic of discussion if that was the case.
I dont remember days like that.
The way i remember it was, we got a product as ready as we could. It would be done with levels of prioritized bugs. âKnown shippablesâ.
While the product was in production and dustribution we were werking on patches and bug fixes to be released when the product hit the shelves.
Once those fixes were done, we were either werking on more fixes, of lower priority than the first batch, and updates, for the second patch post release.
Indeed, it certainly was much more difficult when manufacturers had to ship EPROMs for OS updates. Itâs sad that people have been conditioned to accepting bugs and âfeatures not yet implementedâ as business as usual.
I definitely do not miss having to open a machine and swap chips to do a firmware upgrade.
Speaking of software stability, this seems obvious to me thoughâŚ
I seriously doubt that a combat aircraft or a nuclear plant runs on windows 
I donât know, have you not noticed the increase in naval crashes lately? 
What is obvious to you (and I), may not be obvious too all. Itâs quite apparent if you read this and the many hardware vs computer threads on this board that people do not agree on this subject
Itâs not only about bugs/crashes⌠the fact that most computers canât even provide a steady midi clock to a serial port is enough for me to question the reliability.
Well with the impatience displayed on this forum alone, its no wonder companies do that. With poeple cancelling and threatening to cancel orders during DT release cuz it was late. With people losing their cool over OB.
What would you prefer. Get it on a âprojectedâ time, with some bugs or wait for everything to be werked out.
People do their best to hit deadlines. But unforeseeable issues arise, that need to be addressed.
What do you do. The ire displayed in this forum was so unreasonable, it was embarrassing. But what do you do lose some customers over bugs or over dates.
I was quite content to wait for a finished product. As ive been in the position of being forced by investors to push out a product based on a deadline.
Its easy to sit back and armchair direct a company. Just try to understand some things happen that are out control of the production pipeline that need adjusting for. Its not by design.
Computers never really have. Thats why there are werd clocks.
Theres a sweet little one, i forget the brand, for about $250 i think. Thatll keep all your gear TITE!
Granted, an expert sleepers usamo will do the the job nicely. But itâs not very convenient to me.
I agree, it would be really nice if a company like arturia or roland included the midi clock sync featured by usamo, ERM and others in their audio interfaces!!
The day will come, youâll get this in a usbc powered audio interface i am sure! 
Good idea !
hehe 
horrible USB MIDI jitter in general purpose OSes (even Linux) was the main reason why i got rid of laptop in my rig.
