Multi Rhino interference

[carterbennett]

This isn't a good example, but it is an example. I've had others go contantly, but this one is just two or three instances on the high notes.

Okay! Good news!

I downloaded the mp3s and the Cubase files. And by the mp3s alone, I'd have to say Floyd's right about the overloading...but it's not because you've mixed them too high.

I loaded the Cubase files up and your mix levels are fine...never exceeding -5db below clipping. The individual instrument levels never exceed -6.6 and -12.2 below clip. Your Cubase project loaded up and sounds quite clean here.

In any event, it looks to be more a Cubase to Audiophile interaction than a Rhino thing. Check your email here in a little while, because I'm going to drop you a copy of this mp3 I rendered of your Cubase project and we can see what we can figure out over there.

[Doug Nelson]

I'm guardedly optimistic

Is the soundcard even involved in rendering?

If you can't send the file via the forums, send it to any address at the domain in my sig.

[carterbennett]

I'm guardedly optimistic

Guarded is always good.

Is the soundcard even involved in rendering?

It does seem rather peculiar, huh? Normally, no--you're right--that doesn't make any sense when it's all computationally calculated.

But long before you render, Cubase has already interrogated your sound card and configured its bussing, signaling chain, sample rate, and level controls to match your sound card. So while the hardware is out of the loop at rendering time, your hardware and drivers have already had quite an impact on how Cubase will be processing things.

If you can't send the file via the forums, send it to any address at the domain in my sig.

Will do! Just putting some pieces together and it'll head that way.

[Doug Nelson]

But long before you render, Cubase has already interrogated your sound card and configured its bussing, signaling chain, sample rate, and level controls to match your sound card. So while the hardware is out of the loop at rendering time, your hardware and drivers have already had quite an impact on how Cubase will be processing things.

So what your saying is that no two machines will render the same, using the same inputs? Why bother with patches, then?

I'm appreciating your help, but you'll need to sell me on that concept

[carterbennett]

So what your saying is that no two machines will render the same, using the same inputs? Why bother with patches, then?

I'm appreciating your help, but you'll need to sell me on that concept

Well, it's not quite that extreme. But there is some truth that the same project will render differently on different machines. Even when it seems like it's all in the numeric realm.

For instance: When Cubase opens up and talks to my Delta setup, it determines that there are (currently) 512 samples in the DMA buffer. Cubase calculates this to have a latency of 11.610 milliseconds in cycling through all the output buffers. It actually uses that calculation to shift the time index where certain events are set into motion. (That's what the "Constrain Delay Compensation" rolls back, incidentally.)

Or perhaps if I tell my audio card to lock the sample rate, Cubase works in that sample rate. If the card driver tells Cubase it supports ASIO direct monitoring--and it's turned on in Cubase--it changes the meaning of the "monitor" switch in the Cubase panels.

And there's a long running debate if you check around the forums about rendering delay effects and audio buffer allocation--yet another side discussion in the "latency versus accuracy" debate.

The big deal I think we're going to find in what you're investigating is the channel routing in the VST Multitrack or VST I/O setup in Cubase versus the settings in the sound card control panel.

Some of these things are factored away when you do a direct render to disk, but some of them aren't, surprisingly enough. Note in the export mixdown settings the check box for doing things in "real time"...that makes a tiny difference, too. In theory, we expect that if we don't constrain the software to real time, we get to use all the computation necessary to do everything, even if the machine isn't fast enough to do it in real time. In truth, some things aren't sensible to re-engineer to handle that task.

Even VST instruments and effects can generate or process signals differently based on what they're told (usually by us humans) about the computing power available. Hence the oversampling or rendering quality settings on some synths or plug-ins.

So to a degree--yes, it's true. Every installation could render a given project or a given preset a tinge differently. But those differences are miniscule compared to, say, the difference between the sound of my JBL mix monitors to a set of high end reference monitors--or where I have the monitor amp's EQ set. (I know my JBLs are huge improvement over the boomy 1970s-vintage JVC bass reflex pair just outside them, though. )

[Doug Nelson]

This is going to take some time for me to digest. But the short version is there's a setting in Cubase I need to change?

[carterbennett]

This is going to take some time for me to digest. But the short version is there's a setting in Cubase I need to change?

Sorry about that. I've been accused of being a bit long-winded at times.

But yes...short version is: From what we've seen so far, I'm feeling pretty strongly it will be fixed by either a setting change in either Cubase or the Audiophile control panel.

Should have this email ready to send your way in just a few minutes. It'll pop up at the address listed on your contact page.

[Jeremy_NSL]

just a thought. how about trying another host to see if the problem is cubase-related? Download something free or a demo.

[Doug Nelson]

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.

Any other ideas?

[Robert Randolph]

I just experienced something very similiar to this a day ago when I was getting heavy into rhino... Had a couple instasnces open and hrm... odd.

[Doug Nelson]

Ok, here's a weird development. I soloed the bell patch, verified that it wasn't distorting, and froze it. Then I froze the 2nd patch. Then I played back the two frozen patches and the distortion was back.

[Big Tick]

Hmmm, Rhino isn't involved any more once you've frozen the patch... Could it be something with Cubase ?
'Tick

[experimental.crow]

i have been unable to reproduce this problem in FLS ...

i ran four rhino2 tracks , with two of them being 'bell dreams' , plus two
algorythymics , all fully chorded ...

no distortions ...
no hung notes ...

[wrench45us]

wow.
this is by far the most interesting problem I've come across in all the forums I attend.

it happens once frozen -- that's truly very odd. it definitely puts it in the host's configuration somehow. and well down the processing path, because it's all audio processing then.

i'd reinstall Cubase. It may not do anything, but it gives you some time to think

i've had multiple instances of rhino working in P-5 and Sonar and never had any such problems.

somewhat related:
There can be a similar symptom with Tera 2 -- multiple instances of Tera can interfere with each others 8-d control settings -- so one or the other instance can modify the sound of the other. Tera is multi-instrument multi-timbral so there's no 'need' for mutiple instances, but there's also no need for multiple instaces to interfere with each other.

[Doug Nelson]

I suspect either Cubase or something in my audio, though I have no idea what.

My working theory is that too-similar oscillations "excite" each other, causing weirdness. That's the only reason I can imagine that explains the fact that it's only multiple instances of the same instrument.

I know it's not Rhino.