Multi Rhino interference

[carterbennett]

After way more help than I deserve from carterbennett, all we've really been able to determine is a) it's not my imagination, and b) it's not just my mix. He's walked me through every conceivable software and setup variable.

Of course, then the week started and he got behind in replying.

Sorry I haven't been back to you in the last couple of days, Doug!

But further news to add to the discussion:

I went through all the screen shots you sent of the driver configuration. You and I are now running the same settings in our Delta drivers--on the same version of the same driver. I can also add there are no issues in the M-Audio knowledge base that fit what you're seeing. So...I think we can reasonably, safely conclude that it's not a sound card configuration problem. If it were a driver problem, I think we'd be seeing many mentions of this problem.

It's pretty clear that this is happening in Cubase SX 2. So...next puzzle is why it's doing it in your Cubase but not in mine. FWIW, I'm running the Cubase 2.2.0 build 35 patch that came out in May of this year.

I have to go along with wrench--a complete uninstall/reinstall of Cubase might not be a bad idea. Not a bad idea to start from a baseline install--just to be sure.

[Big Tick]

I know it's not Rhino.

... and for this I'm thankful
'Tick

[Robert Randolph]

Happened to me in tracktion... Only once though, I wonder what it could be? I havent tried since.

[Doug Nelson]

The synth that caused the most problems like this for me was Synth1. I finally uninstalled it, I got so frustrated. It also happened with Triangle II (tried to figure it out then, Rene was stumped). Neither one of those was a clipping problem, in fact the Synth1 prob was LFO overlap. I'd load a nice, gated trancy-sounding patch, then load another instance and the trancy-sounding patch would suddenly go all irregular and wobbly, even sometimes becoming a steady tone.

[carterbennett]

Neither one of those was a clipping problem, in fact the Synth1 prob was LFO overlap. I'd load a nice, gated trancy-sounding patch, then load another instance and the trancy-sounding patch would suddenly go all irregular and wobbly, even sometimes becoming a steady tone.

Wait a sec....you mean you've had instances where an instrument was loaded and something like the LFO or envelope on one instrument was affecting the LFO or envelope on another?

Y'know...once long ago, I vaguely remember loading a z3ta+ and having the effects section of one instance seemingly affect the other instance. I couldn't reproduce the problem so I wrote it off as something peculiar and let it go.

But if this is the case, it sounds like there may be a problem in the code sharing mechanisms that Cubase might be employing to load DLLs.

Tick? Can I run a notion by you?

I've never worked in the VST framework. I gather it's not like an ActiveX/OLE loading since the DLLs don't have to be registered. So is it more like a classic Windows DLL loading mechanism with a descriptor in there to be polled?

Here's the hypothesis I'm starting to form. When a DLL is loaded, each process accessing the DLL gets a pointer to the shared code location, but each process is supposed to get its own data segment. Now...do we suppose it's conceivable that Cubase loading VST components might be sharing data segment data incorrectly? My impression is that Cubase has been rather heavily optimized, so resource sharing might be coded by hand instead of calling on a Win library.

Or...here's something I've seen from time to time: An Cubase data offset pointer that should be resolved at run time may have been inadvertenly resolved at link time--so a data segment pointer which should go to a second instance may be going to the first instance loaded. I've seen that a lot in hard-to-reproduce stuff.

I'm theoreticizing about a framework I haven't worked in, so could you give me a reality check, Tick? Possible?

Daniel? Can you check your Cubase version and let us know which build it is? I'm going to see if I can find reproduce something like this in either Rhino, z3ta+, Synth1 or Pentagon.

We already seem to know this isn't restricted to one VSTi. It might affect all of them. or all of them with a data segment over some given size....or smaller than some given size.

(he plods back to the studio lost in thought and muttering to himself)

[Big Tick]

I kinda doubt it. Rhino does share data between instances, for instance the user interface bitmaps. Vst hosts load a plugin using a call to LoadLibrary, so the allocation of data area is fully managed by the OS - only data declared as static will be shared by the various instances.
I don't believe Steinberg would change anything in the way the OS loads .dll. That would be a nasty mess to get into.
'Tick

[carterbennett]

I kinda doubt it. Rhino does share data between instances, for instance the user interface bitmaps. Vst hosts load a plugin using a call to LoadLibrary, so the allocation of data area is fully managed by the OS - only data declared as static will be shared by the various instances.
I don't believe Steinberg would change anything in the way the OS loads .dll. That would be a nasty mess to get into.
'Tick

Oh, geez! Thanks for saying that, Tick! Your reminder about LoadLibrary just made me realize I was thinking about that from the wrong side, anyway.

It's not sharing a DLL between multiple process, it's a single process running the same DLL for multiple instances.

But there's a reason this is all nagging at me. I just went back and looked this up that I remembered from a while back.

I notice that in the Cubase 2.2.0 release notes, under changes made since 2.0.2, "Fixes", they list

VST Instruments: In cases where multiple instances of the same plugin are present
and the order of plugins is being altered (e.g. by removing an instance from a lower slot
number), problems can occur on loading the project: - wrong assignment of the VST Instruments
- no connection to the automation. These problems have been fixed.

So...at the very least I'm wondering about their data management between instances of a given VSTi in a project. I take the above to be a matter of resolving stored references in the Cubase project file (.CPR) against DLL names...but if they have cross linked those in the past....

Anyway...just brainstorming. Thanks, 'Tick!

[Doug Nelson]

I'm running 2.2.0, May 25 build. I do believe my most drastic versions of this problem were pre-2.2 (though I've never used anything earlier than 2.0).