Weird Thing Happening

[Jerry Gerber]

I'm not sure if this is a hardware or software issue.  When I open a file and play it, the first time it plays there's a glitch in the cellos and/or basses at measure 69 (the work is in progress and I am up to around measure 130 or so).  But if I go back and play just those measures or the entire sequence, it plays fine for the entire session.

I've done a check on my hardware in terms of how well it's able to handle audio and everything looks good.  Though I've been managing a studio for nearly 40 years, I'm really stumped as to what causes this.   My DAW is connected to one other machine that is dedicated to the Vienna Symphonic Orchestral Cube. 

DAW:

Windows 10, i7 CPU, 32 GB RAM, 2 SSD drives

2nd Computer:

Windows 10, i7 CPU, 32 GB RAM, 3 SSD drives

The two computers are connected via ADAT, each machine has a dedicated sound car, the DAW has an RME UFX II and the 2nd computer has a MOTU  LP32.  I've tried changing the audio buffers from 512 to 1024 but that doesn't resolve it. 

These are dedicated computers, used for nothing but music production.

I really don't know if this is an audio glitch or a MIDI glitch.  It sounds like a note gets cut off and I hear a little short "pop".  As I said, this only happens once, when I playback the file the first time after I turn the computer on and begin work.  

I could try reinstalling the samples of those instruments, but if the sample file(s) got corrupted, I'd think they'd not play back correctly every time.

Any thoughts from what might be causing this?  

Thanks,

Jerry

 

[mettelus]

23 minutes ago, Jerry Gerber said:

the first time it plays there's a glitch in the cellos and/or basses at measure 69

Are you using a VSTi that is actively pulling samples "as needed" at that point in the project... such as a VSTi that first comes online at measure 69? Once those samples are loaded into RAM, they will persist for the session, but when first loaded that glitch may be from pulling the samples into RAM.

[Jerry Gerber]

3 minutes ago, mettelus said:

Are you using a VSTi that is actively pulling samples "as needed" at that point in the project... such as a VSTi that first comes online at measure 69? Once those samples are loaded into RAM, they will persist for the session, but when first loaded that glitch may be from pulling the samples into RAM.

That sounds plausible.  I'll have to check to see if the VSL player has an option to load all samples at startup.  I'm pretty sure though that the pizz basses and cellos do come in before that point.

Thanks for replying!

 

[Starship Krupa]

From the symptom, I'd say that the instrument is trying to use data that it doesn't have fast enough access to. After playing through the first time, it's been cached, so no problem. We trace it upstream to see what's going on.

@Jerry Gerber, when you say that the non-DAW system is dedicated to the Vienna Symphonic Orchestral Cube, what exactly to you mean by that?

Are you using the dedicated system as you would an external MIDI synth, where you send MIDI data to it and route the audio back to the DAW system? I assume that the cellos and basses are being played back by the VSOC system.

If so, that narrows it down to the issue being with that system, since the DAW is just telling it to play the note. Does this project use the VSOC for instruments that occur before the cellos and basses kick in (probably so).

You're loading samples from an SSD, so inherent disk transfer speed shouldn't be a bottleneck. Have you tried running your SSD diagnostics? The programs that you download from the drive's manufacturer, that is.

When the glitch happens, is it the first time in the project that those instruments (or specific articulations) are used in the project? If you turn on the system(s) and play a cello or bass note from your controller before loading the project, do you get the same glitch? If so, that might indicate an issue with loading those specific samples, but if not, it could be that it only happens when VSOC loads all of the other samples first. It may be out of room for pre-loading.

Finally, what does Vienna's support forum have to say about it?

[Jerry Gerber]

1 hour ago, Starship Krupa said:

From the symptom, I'd say that the instrument is trying to use data that it doesn't have fast enough access to. After playing through the first time, it's been cached, so no problem. We trace it upstream to see what's going on.

@Jerry Gerber, when you say that the non-DAW system is dedicated to the Vienna Symphonic Orchestral Cube, what exactly to you mean by that?

Are you using the dedicated system as you would an external MIDI synth, where you send MIDI data to it and route the audio back to the DAW system? I assume that the cellos and basses are being played back by the VSOC system.

If so, that narrows it down to the issue being with that system, since the DAW is just telling it to play the note. Does this project use the VSOC for instruments that occur before the cellos and basses kick in (probably so).

You're loading samples from an SSD, so inherent disk transfer speed shouldn't be a bottleneck. Have you tried running your SSD diagnostics? The programs that you download from the drive's manufacturer, that is.

When the glitch happens, is it the first time in the project that those instruments (or specific articulations) are used in the project? If you turn on the system(s) and play a cello or bass note from your controller before loading the project, do you get the same glitch? If so, that might indicate an issue with loading those specific samples, but if not, it could be that it only happens when VSOC loads all of the other samples first. It may be out of room for pre-loading.

Finally, what does Vienna's support forum have to say about it?

Thank yo Starship Krupa for responding.   Yeah, other instruments are playing, including cellos and basses before the glitch happens.  I'll have to check to see of the articulation that has the glitch was played earlier in the piece.  I mean that the 2nd computer is dedicated only the VSOC samples.  It's connected via MIDI over LAN, with the DAW sending MIDI data to the 2nd computer which plays back the samples and sends the audio over ADAT back to the DAW. 

I'll investigate further and I posed on VSL's forum.  I am not sure if VSL is even supporting the Cube anymore...

Jerry

[Starship Krupa]

33 minutes ago, Jerry Gerber said:

It's connected via MIDI over LAN, with the DAW sending MIDI data to the 2nd computer which plays back the samples and sends the audio over ADAT back to the DAW.

That's how I read it. So you're almost definitely looking for an issue with VSOC on the dedicated computer. I hope there's a way to pre-load the samples.

[Jerry Gerber]

I finally found the problem and resolved it.    Thanks Starship Krupa for steering me in the right direction.  The VSL library comes with what's called the Directory Manager.  In this utility, is a setting called "Pre-Load", which allows you to choose how many samples from each sample set (i.e. brass samples, string samples, etc., whatever samples you've installed on your machine) you want to load at start-up. 

At some point long ago I may have changed each sample set to 2048  samples.  I forgot about this setting. and  had never thought to change this. When I changed every sample set to load 8192 samples, the problem I explained above disappeared.  I still have over 19GB of free RAM. 

If you ever run across the same problem, consider looking at how many samples are being loaded into memory at startup.

Jerry

www.jerrygerber.com

 

 

 

Edited Thursday at 08:03 AM by Jerry Gerber