@stephen limbaugh

Hi Stephen,

The Vienna Synchron Player only makes a VERY rudimentary check to determine whether it's a spinning drive. (Synchron Player samples require SSD storage). For a comprehensive test, the Player would need MUCH longer, which is not great when trying to start the Player or make changes to the database.

As for read speed @Cyril Blanc has mentioned:

Sequential read speeds are irrelevant for sample streaming. This is what you get when you copy a single, large file. Because the drive does exactly know which bit of data is streamed next (=sequential). It's also what drive manufacturers use to promote their products.

But this has very little to do with real-life sample streaming. Sample streaming works differently. The drive does not "know" which note (= sample) will be streamed next. The samples are streamed "randomly". Therefore, the speed that matters is the so-called "random read speed".

(And that one is much slower, due to its random nature)

@Andreas8420 thanks for the info!

So, as I am trying to optimize my new system, would you suggest that I get everything loaded up, make a piece of music, then measure the performance? Then play with the threads and preload sizes?

Also trying to decide if I want to go back to a multiport or use separate VEP instances...

Hi Stephen

I dont use anymore Synchron Player, only VI with MIR PRO 3D

try with I/O buffer size to 1024

This is my Logic setting:

To Andreas :

Black Magic test is a test to test performance of your disks.

There are no relation with Apps.

If the APP is not optimize you could get desastrous result (I was a programmer)

If your disk is Fragmented it could issue bad performance

A few year ago VI player was very bad, after modifying it /re-writing it, it was twice faster.

@Cyril Blanc oh well yeah.. if you're not using multiple Synchron mic positions and a 1024 buffer then there's not gonna be an issue even on older machines. But the idea is to use the Synchorn samples, which I like the best.

Stephen, your disappointment is entirely understandable. I'd probably be hopping f***ing mad if I'd invested in an M3 MBP and a big fast external SSD, only to see multiple CPU cores saturating on a (one of my all-time fav) full orchestral rendition. In fact I'm hanging back on my own Apple Silicon upgrade, waiting (and hoping) for the cost/benefit ratio to approach a more attractive figure.

The read speeds you quote for your internal and external SSDs look respectably substantial - especially compared to the low figures I was making do with about 5 years ago (locally-hosted VEP on my 2017 iMac 7700k)! I doubt if there's much that can be done to improve your SSD read speeds significantly.

But there is one parameter that sticks out like a sore thumb - your I/O buffer size setting of 128! That's pushing your machinery hard in this kind of work!

Despite all of Apple's optimistic hype (probably somewhat misleading here and there) about the bump up in Apple Silicon speed performance compared to their previous Intel-based hardware, I strongly doubt if the actual, practical, speed bump obtainable in our normal everyday usage of Apple Silicon warrants a BIG step change in I/O Buffer size down from 512 to 128 samples.

Yes, a 512 buffer gives a very sluggish feel to live playing; and yet - as you know - that's what many VSL users have been coping with for years. If your new locally-hosted rig can cope adequately with a 256 I/O Buffer, then frankly I'd settle for that as a win.

Stephen :

VSL did not re-sample there whole lib, it is years of work !!!

I remember VSL saying many years ago that it was a ... to use instruments recorded with reverb.

Synchron instruments are using the samples of the VI lib !*

The advantage to use MIR PRO 3D is that the load is spread into two processes.

One for Logic and another one for MIR PRO

Logic is ending the wraw sound to MIR that calculates the tails.

This explain why I do not go over 25 % on big tuty on 100 tracks

I move from an Intel Macbook Pro to the M3 for Dolby Atmos

Macker :

From what I learn you need to use low buffer size when you record fast parts

I have record a singer at 1024, no problem

May be I am wrong !

* VSL can give more details of newly record libs

@Macker said:

The read speeds you quote for your internal and external SSDs look respectably substantial - especially compared to the low figures I was making do with about 5 years ago (locally-hosted VEP on my 2017 iMac 7700k)! I doubt if there's much that can be done to improve your SSD read speeds significantly.

But there is one parameter that sticks out like a sore thumb - your I/O buffer size setting of 128! That's pushing your machinery hard in this kind of work!

Guys! So check THIS out though!

64 buffer, Synchron Pianos (Fazoli F308), with FOUR mic positions, no VEPro, MAX (1024!!) voices per mic allocation... LIVE. 🔥🔥🔥

This was in no way possible on the Intel Mac. Very, very excited about this. It means that when mixing with 1024 buffer in Logic Pro, Synchron pianos will never come close to peaking the CPU. 🤠

IMPORTANT NOTE: My (sloppy) quick rendition of the Chopin Polonaise audio was captured through the mono audio interface microphone because I couldn't figure out how to live screen record audio, plus video, and also hear the live playback all at the same time. Still, zero pops/clicks. 🤌🏻

Other details:

Logic Audio Settings:

I/O Buffer Size: 62

Processing Threads: Automatic

Process Buffer Range: Medium

Synchron Pianos Settings:

Preload Size: 4096

Speed 64k: 576.5 MB/s (Samples streaming from Sandisk Pro-G40 4TB)

Streaming Threads: 4

Loading Threads: 4

@Cyril-Blanc said:
Synchron instruments are using the samples of the VI lib !*

No, they are not. Synchron libraries are all new recordings done in Synchron Stage Vienna.

SYNCHRON-ized libraries in comparison are re-worked VI libraries with improvements, adjustments and sometimes even additional content for the new Synchron Player.

Playing with Synchron Pianos on M3 max MBP more...

Yeah, so even when I bring the Logic buffer down to 32 (!!!), and reduce the voice-per-mic to ~100, and use 3 mic positions, Synchron Pianos loaded directly in Logic are not peaking the CPU. That's more than enough to sculpt a sound as you are performing, then increase the voices-per-mic number and/or add mic positions once your MIDI performance is in. Very cool. This is great. Excellent work VSL!

Stephen, so pleased you've got that great result playing your VSL Fazoli live with 64 buffer (your excitement and joy came through wonderfully in your quick and enjoyable live rendition of the Polonaise!).

When I was talking about buffer sizes of 128 and 256 it was of course in the context of full orchestral renditions with Synchron Libraries. Nevertheless it's good to know how very powerful a single one of your M3 cores is when tackling live playing. Super result!

I'm very optimistic that you'll be able to configure a fully versatile orchestral template that won't need slaves. Hope you'll keep us posted.

You just need to enable "record" on a second track that is configured for your second mic

When I record my drums I have 12 mics

@stephen-limbaugh said:

IMPORTANT NOTE: My (sloppy) quick rendition of the Chopin Polonaise audio was captured through the mono audio interface microphone because I couldn't figure out how to live screen record audio,

Hi Stephen, there is a huge difference when you use VEP Pro with all your VSL and eventual,other libraries loaded on the same MBP and rather then loading all Synchron and other instruments directly in your DAW or scoring software.

I tested using a Le Sacre du Printemps, the first part, score in Dorico. It is availbe for download on the Scring Notes site. It really has a lot of instruments playing atbthr same time with many changes of articulations and changing fast rythms. With my 64GB M1 Max and all instruments directly loaded it pops and clicks in the busiest parts and randomply even stops playback at some points. On the other hand with all instruments in a VEP Pro template (with 19:instances with upto 16 instruments per instance, 16 instances active for this piece) the whole piece plays without issues.

With your double amount of unified memory it should even be better.

I do have most VSL libraries diredtly on my MBP (taking 3.5 GB) but I do not think that SSD random speed is an issue.

I'm having a laugh at several items of 'helpful advice' and 'pearls of wisdom' dished out above by someone, while I'm also wondering why a particular few of these all-too-busy 'advice-givers' here seem to have a couldn't-care-less attitude about the quality of their own knowledge and expertise just so long as they say something ... anything. Perhaps it's more about getting attention than giving actually relevant, sound and helpful advice?

• "Fragmentation of the disk contents might be causing a problem here". [Paraphrased.]

Erm ... lol. One does NOT defragment SSDs.

An SSD's stored data is constantly and very deliberately being 'fragmented' by the device controller's wear-levelling algorithms in order to spread around as evenly as possible the wearing down of each memory location's lifespan caused by write operations. This is why it's often recommended to avoid filling an SSD beyond about 80% or 90% or so, to leave enough wiggle-room for the wear-levelling process to do its essential pro-'fragmentation' work. SSDs with S.M.A.R.T. health monitoring and reporting facilities will flag up a caution if the "Available Spare" amount drops below a certain threshold.

(Check out the DriveDx app if you want to keep a eye on the health of your SSDs and spinning-platter disk drives - given that they have S.M.A.R.T. support).

• "Recording a singer while your I/O Buffer is set at 1024 samples is not problematic." [Paraphrased]

Sure, just so long as you don't give a damn about providing the singer with low-latency headphone monitoring which often would include some reverb and perhaps a few other tweaks personalised for the singer's cue mix. Or, of course you could set up a cue mix on a separate little analogue monitoring mixer - in which case your DAW's Buffer size would be pretty much irrelevant, but then why mention it?

So here's the point: perhaps it would actually be problematic if the singer - owing to an awful experience with terrible cue-monitoring via a horribly sluggish DAW - would never want to set foot in your studio ever again. Oh but then again, I was forgetting – that wouldn't be seen as problematic by a would-be recordist who has no empathy, would it now?

• "You need to record fast stuff with a small I/O Buffer size." [Paraphrased]

No s**t? Gosh!

Spoiler alert:- what's probably the first thing youngsters do when they first get their hands on a DAW and a MIDI keyboard? Yep, hook up a software instrument and try to play it live. Then what's likely the next thing that concerns them? Trying to get it to feel more like a live instrument. Somehow, I doubt if many if any at all in this hallowed forum are still at that stage. Perhaps this particular 'advice-giver' would do better posting such 'wisdom' in a junior school forum.

• "VSL re-uses some VI samples in their Synchron libraries" [Paraphrased]

Well that's been dealt with above in no uncertain terms, so I needn't go there except to say, what a bloody cheek to lie like that! Here!

Ok dear readers, there's plenty of other wonderful examples from our resident 'founts of wisdom', but you get the gist so I'll leave my little critique at that for now.

Fragmentation happened with spinning hard-drives, but is no longer relevant for SSDs (solid state drive).
SSDs don't fragment, and they can't be defragmented. In fact using old software to defragment can degrade or even damage your SSD.

SSDs are not accessed mechanical but instead have random access to all storage cells.

Instead SSDs need regular TRIM to free up cells with deleted content so they can be re-used.
This is something your OS handles automatically, no need to manually interfere with it.

@Helmholtz & @Cyril Blanc Would you please moderate your tone again a little, thank you. Knowledge is power, but a bit of kindness can also go a long way. 😉