We make sure that our protection system does not noticable impact real-time audio.

Yeah, ravez, that behaviour of the Synchron Player has given me cause for puzzlement too.

Is it that that sometimes certain samples haven't yet been placed in RAM by Preload (either because the Preload size is a bit too small or perhaps because the machine just ain't got enough free RAM to satisfy Preload) and so have to be fetched from storage first? Then perhaps it's a catch-as-catch-can game between the various tracks and CPU threads who all want their samples ready preloaded in RAM but not all can be satisfied?

I find it hard to deduce what exactly is going on there.

@ravez said:

I wonder why if the synchron player is inside audiogridder, switching from one track to another becomes instantaneous again.

I guess the decryption happens only at the first load in this case?

I guess the app does not close the UI and instead preserves it in RAM. Most DAWs and VEP will unload the UI to preserve RAM instead.

Ben, appreciate your two comments above.

I'm still unclear as to what exactly happens where, when and under what circumstances, since even knowing the realtime privilege priority level of each process still doesn't help us predict the order of asynchronous realtime event processing - any more than merely stochastically.

And since I'm not in a lab with very expensive analytical lab instruments at hand, of course I'm not expecting to arrive at any exact answers to my investigations.

My broad-brush postulates and questions at the top still stand, however.

I can't comment more detailed, not only are we're under NDA, but also is it in our best interest not to reveal details regarding our copy-protection.

Like I said, real-time performance is not degraded by our copy-protection; it's important to us to provide the best user experience and that's why we make sure it stays that way by regular internal testing.

Thanks for that, Ben. Understood about NDA and VSL's own commercial confidentiality. I wouldn't expect it to be otherwise. And there's no suggestion here of the quality of VSL's development and testing being at any time less than the usual high standards we've come to know and respect. I'm talking about certain exigencies that arose and had to be faced and promptly dealt with by VSL - namely, the impending discontinuation of E-Licenser.

The hard evidence that got me started on my current experiments and thinking came in the form of 3 readouts from the Synchron Player's random-access speed meter. All 3 of these SSD speed readings were pre-iLok (2 from Stephen Limbaugh; and 1 embedded screenshot in the Synchron Player user guide that I seem to recall from back in the days of Synchron Strings 1).

It appears to me that those Synchron SSD speed test results are pretty much impossible to replicate now - even roughly - with iLok in the game. As many Synchron users have already noted in this forum since the introduction of iLok, something is - or some things are - very different in streaming performance between then and now.

Also, the essentials of my basic understanding of iLok's security system comes from iLok's own published information.

I'd still appreciate a word from Paul tomorrow or soonish if possible. This isn't an urgent matter, but I do believe it's important for many VSL users and, ultimately, for VSL itself.

@Helmholtz said:
The hard evidence that got me started on my current experiments and thinking came in the form of 3 readouts from the Synchron Player's random-access speed meter. All 3 of these SSD speed readings were pre-iLok (2 from Stephen Limbaugh; and 1 embedded screenshot in the Synchron Player user guide that I seem to recall from back in the days of Synchron Strings 1).

The player measures 2 different kind of disk speeds, it might be that the other value is now shown. Regardless, this doesn't change performance or how Synchron Player handles things.

@Helmholtz said:
with iLok in the game.

Again, nothing to do with iLok, a lot else has changed in the meantime, and if I remember correctly the streaming code was refactored and optimized post iLok launch. With the latest version(s) you will have better performance compared to any eLicenser build.

@Helmholtz said:
As many Synchron users have already noted in this forum since the introduction of iLok, something is - or some things are - very different in streaming performance between then and now.

I have not seen any complains or discussions of this kind in a long time, and last time I experienced streaming issues was with eLicenser variants of the player.

@Helmholtz said:
I'd still appreciate a word from Paul tomorrow if possible. This isn't an urgent matter, but I do believe it's important for many VSL users and, ultimately, for VSL itself.

I have no idea what you expect from Paul to add to this discussion tbh 😊
And I also don't get it why this is an important topic. If you experience unusual performance issues you should contact support@vsl.co.at. This is not a support-, but a user-forum.

I hear what you say, Ben. Many thanks for your comments.

What I'd very much like Paul to address if he gets time is my pair of questions at the top ... "if VSL can envisage ..." etc.

(My thinking behind the 1st option is that it would probably require a pretty radical redesign of the anti-piracy system - with or without iLok. The 2nd option involves a tradeoff - do we wait a bit longer for preset loading by making preloading take care of decryption in order to speed up subsequent realtime streaming, or do we put up with the current streaming performance limitations due to the current extra CPU burden of stream decryption in realtime? And of course I would certainly never be asking Paul to frame any sort of answer in such specific terms.)

Sorry, I thought that my explainations have already answered this question. Let me try again:

@Helmholtz said:
In all of VSL's iLok libraries, all sample audio is PACE(iLok)-encrypted prior to download and installation.

Our samples contain copy-protection.

@Helmholtz said:
A fresh or moved installation of a VSL iLok library does not finally decrypt the sample audio.

Our samples are downloaded and installed on your drive.

@Helmholtz said:
Decryption of a sample takes place only as and when that sample is required for realtime audio processing and streaming as a component of one or more patches engaged by the user's playing or programming.

Whatever we do, as you can hear, the Synchron Player outputs audio data your DAW can use 😊

@Helmholtz said:
Encrypted sample audio is first fetched from RAM as and when required for realtime streaming - given that the (user-adjustable) RAM-Preload size is big enough to include all of the samples currently made available in the Player for realtime streaming; otherwise it is fetched from storage into RAM - and then it is decrypted and processed according to the active Synchron Mix Channel inserts, routing, etc settings for each patch being streamed in realtime.

Again, your DAW gets usable audio data. We / I can't confirm or deny anything else regarding this topic.

@Helmholtz said:
Compared to the above, in the case of VSL's E-Licenser libraries, either no decryption takes place as a normal part of realtime sample fetching, mix-processing and streaming, or else only a trivial amount of such decryption takes place and is much faster.

Neither is true.

@Helmholtz said:
If my assumptions above are substantially valid, I'm asking if VSL can envisage, at some future time, moving the weightiest part or all of sample decryption into either

the Install function, or
the Preload function.

Answer: No.
Reason: Whatever we do or not do, there is no significant difference in performance in regards of streaming and real-time performance.
In case you experience streaming issues it might be caused by your hardware / setup, configuration, or a bug in our software. In this case please contact our support via mail. Right now I'm not aware of any such bug/issue.

Ben, thanks again.

I don't believe I'm dealing with any sort of bug or bugs. I do believe my Player software, DAW & computer hardware and software are operating as designed and intended.

I'm simply expressing thoughts and ideas as a user to other users as well as to VSL.

Now I must sign off for the day - it's getting very late here.

@Ben said:

@ravez said:

I wonder why if the synchron player is inside audiogridder, switching from one track to another becomes instantaneous again.

I guess the decryption happens only at the first load in this case?

I guess the app does not close the UI and instead preserves it in RAM. Most DAWs and VEP will unload the UI to preserve RAM instead.

I see, I just wish i could switch tracks with the Synchron player GUI open without waiting 1-2 seconds for it to re-draw, just like when wrapped in Audiogridder or like any other player (Opus, Kontakt, Sine, Spitfire etc).

wonder what the ram difference actually is to justify such performance lag, is this really how the player is designed to work?

made a video to show the issue

@ravez said:
wonder what the ram difference actually is to justify such performance lag, is this really how the player is designed to work?

* your DAW designed to work

And yes, the additional RAM usage is noticeable, especially with many instances.

Ben do you recommend using as much RAM as is available in the Synchron Player? So if I have a template that uses 52Gb, but have 128gb total, then setting the Synchron Player to use more RAM will increase performance in a noticeable way?

@stephen-limbaugh said:

Ben do you recommend using as much RAM as is available in the Synchron Player? So if I have a template that uses 52Gb, but have 128gb total, then setting the Synchron Player to use more RAM will increase performance in a noticeable way?

Yes, it might increase performance, especially CPU load if it is already working hard. If your CPU has not much to do you will not notice a difference.
Still, the downside will be more RAM consumption and significantly longer sample loading times.

I'm back-and-forth with VSL support helping me on some performance issues, but booting things up this morning and changing my Synchron Player preload size from 3072 to 8-thousand-whatever caused the Synchron+VEPro tab CPU meters to drop by ~50% literally.

In fact, using VEPro, that problem session from the other thread (the locked one) now operates perfectly EXCEPT for the single-core Logic Pro thing when it's a buffer of <256 and a recording track is highlighted during a tutti passage.

Anything at 256 buffer and above, a highlighted track remains playable live without pops.

For reference, this is a tutti passage with Synchron Series instruments with 5+ microphone positions enabled, some VI series instruments in MIRpro 3D, totaling ~54 tracks with various FX plugins engaged. Machine is an M3 Max.

Stephen, very glad to hear you're now back in business with your new MBP. That's great news!

It seems to me your 128GB RAM allows your system to cache a much larger amount of sample files in RAM during Preload, now that you've whacked your Preload Sizes up to 8192.

When I reboot my system then launch my Synchron Orchestra Stress Test in Logic, I can see VSL's Preload cache files building up until they're using the maximum that my 64GB system RAM has to spare for caching - which turns out to be only just about sufficient for my test orchestra. And that's probably why, if I increase my test orchestra's Preload Sizes to 8192 then reboot and relaunch, I'm not seeing any increase in cache size, nor any reduction in CPU load. My maxed-out 64GB RAM just ain't big enough for any of that good stuff.

I'm going to experiment further, e.g. adding VEPro, and using patch changes during my test runs, so that I have some sort of benchmark with which I can check for the performance impact of using various different libraries, of software updates, and of various different configurations and automation. I just wish I'd set up a benchmark test like this before all the iLok and Apple Silicon upheaval took place.

You will only see performce improvements if your CPU is the bottleneck and running at full load during playback.

It will also depend on the drive. The slower the drive, the larger the noticable performance gain. Also you will notice them more with SATA drives compared to NVMe drives. It also hugely depends on the library and how you use it.

A preload buffer size of 8192 will load exactly the same amount of data into RAM on a 128GB RAM system as on a 64 GB system.

If you don't have any performance issues, then measuring/tweaking these settings is a waste of your time/life.

Thanks Ben. Interesting perspective.

Aren't many if not most users apt to tweak or 'fettle' their systems now and then, always looking for improvements? I'm certainly one of those.