Here's what the Synchron Player's speed test reported back in the pre-iLok days when Synchron Strings was released; this screen shot is still included in the current Synchron Player User Guide. I defy anyone to match these results now for an iLok Synchron library (especially the amazing ratio between 64k and 4k results):-

However if, as Ben noted above, the Preload software has been substantially revised since then, it's probably not sensible to try to make any meaningful deductions about the then-vs-now difference in terms of the burden added by iLok. So I won't.

I've found that manually adding to Preload Size in the Database does nothing significant in terms of relieving CPU workload on playback.

My total RAM use is well within my machine's maximum (64GB).

In my Synchron orchestra stress tests, the iMac's Activity Monitor shows no noticeable fetching of samples from storage during playback, either with or without my additions to Preload Size.

Of course the hugely critical factor in CPU streaming workload is how many mix channels are switched on in the Synchron Players. To get an idea of how well or badly my system performs under various conditions, I've been experimenting with a Synchron basic symphony orchestra under various different levels of stress. This test build in Logic doesn't use VEP; there are no plugin Fx running in the Synchron Players or in Logic; and just 2 stereo audio routes between each Synchron Player and Logic.

Stress testing the whole of this basic orchestra (27 Synchron Players) consists of running a looped 1 Bar chromatic scale of nearly 2 octaves for every Synchron Player, every note a 1/16, played as fast legato at various different BPMs and with various numbers of Synchron Player mix channels switched on.

At my fastest sensible tempo of 110 BPM and with only 1 mix channel switched on in all players, I get this:-

With 4 mix channels switched on in all players, at the same tempo, this:-

No audio plop-outs and no CPU crunch-outs anywhere.

Not too shabby for a 2017 iMac 7700K - helped along by recent addition of a couple of very fast Samsung SSDs via Thunderbolt 3.

Two kinds of computer system 'fettlers': those who love to fiddle around in very techie areas such as BIOS or the guts of the OS; and those - including me - who can't be arsed to wade into the deadly boring geeky detail (which is why I've always bought Apple), but who nevertheless like to know what it is we're dealing with and what can and can't be done with it.

These days personal computing is nowhere near as straightforward as it was back in '77 when I first got into microcomputing. But no matter that computer and software companies nowadays are ever more determined to make customers believe they shouldn't worry their pretty little heads about what goes on under the hood, I'll never be the ideal consumer type. Lol.

"OLD, NOT OBSOLETE" ~ me, imitating a famous Austrian Terminator, describing my ancient iMac. (2017 is really ancient, right?).

I've pushed my stress-test Synchron orchestra harder, adding a Synchron D-274 track for live use. Now I can use an I/O Buffer Size as small as 32 samples, along with Medium Process Buffer Range, with all Synchron instruments playing back on just 1 audio Mix Channel each, while playing the D-274 live. (I'm not a pianist but that doesn't mean I can't knock out plenty of 2-handed chords at speed.)

The result:- live piano latency is nice and short, AND with at least the bare bones of full orchestral accompaniment. Of course it's not as full-on as you're now getting with your M3 MBP, Stephen. But what it means for me is that I won't be contributing to Apple's revenue as early as I'd previously thought.

Here's the evidence (One mix channel switched on in each Synchron player):-

Strange thing now is - I'm getting less total RAM pressure than previously, even though in both cases I rebooted immediately before taking readings once the whole orchestra had fully completed its preloads. Whatever!

Also, I've found that I can run all the orchestra players with 4 mix channels switched on and still at I/O Buffer 32, but in this case I need Large Process Buffer Range selected. Curiously, the total CPU load is in this case not far above what it is for the similar (4 audio channels each player) case at I/O Buffer 512.

P.S.

I forgot to say what recent major change I believe has helped hugely with my Synchron tasks.

I now have all of my Synchron and Synchronized libraries in a new external SSD on its own Thunderbolt 3 port. That SSD is a Samsung 990 Pro 4TB M.2/NVMe/PCIe module (up to 7.5GB/s max speed) that I popped into an Acacis TBU405Pro M1 enclosure rated at Thunderbolt speed of 40Gb/sec max bidirectional transfer rate. In practice that means in sequential read and write tests, the Thunderbolt port maxes out at about 2.5 GB/s unidirectional (as normal). That's a downside (compared to internal SSD) only for clean installs and first-time app loading, etc; but certainly not a problem for the usual random reads during operation of the sample libraries. In the latter case, the ultra low latencies of the SSD and its enclosure still apply and provide market-leading speeds for random reads (as shown in an earlier thread).

Yep, a somewhat expensive addition, and yep, I know the prices will fall. But I was indulging a bit of impatience and enthusiasm after I'd already replaced my Thunderbolt boot SSD with a 980Pro SSD (similar details as above) in an Acasis enclosure (same model as above), and noticed excellent results.