Mixing in Scope - Device latencies/phase problems

[Yogimeister]

Thanx guys ...

Astro - I definately hear a difference when bouncing SCOPEsynths to wav in cubase and playing it back (I thought it was just due to a different phase of the audio (I mostly noticed it on phattt low sounds like C4T and stuff ... But I dont have THAT much experience with the Scope Synths (Yet) ....

I know that 24bit and (never heard that 32bit is 24float ...) is plenty of depth - but besides the additional magic sonics (if any) , I was also wondering what would be the most efficient in terms of cpu/dsp loads (avoiding extra float/bitdepth conversions, etc ... )




Dante- its a good idea to try and "force myself" to use mono channels ...
(Im not sure how I feel about the prospects of collapsing stereo tracks to mono though .... I think I would rather narrow the stereo field ...

[garyb]

no, using more mono tracks will improve the overall stereo field. in the real world, very few things are recorded in stereo when they are part of a bigger mix. also, in general, you should always record ALL audio sources to "tape" before mixing.

[dante]

Dante- its a good idea to try and "force myself" to use mono channels ...
(Im not sure how I feel about the prospects of collapsing stereo tracks to mono though .... I think I would rather narrow the stereo field ...

No collapsing of stereo to mono here : Check the following :

Note the double tracked guitars on 9 and 10 are not hard left / right, neither are vocals on 13 / 14. Synths and the B3 (tracks 27 and 28) is hard panned due to allowing for the rotor effect.

Drums, bass etc are all mono except Toms which is a stereo sub mix and same with room to give wide impression of space.

I used to think having no stereo tracks was a nuisance, but now I like it, its good for placement discipline.

Yes, all the synths (17 - 26) are hard panned stereo, but they are not all happening at once.

Track Mix

tracks.jpg (202.59 KiB) Viewed 3251 times

[astroman]

...Astro - I definately hear a difference when bouncing SCOPEsynths to wav in cubase and playing it back ...

same here - thing is you can even phase cancel some files, but it still sounds different...
when my native system renders a track, I could swear it always slightly changes from what was monitored
(no big deal tho - I've become used to it and try to anticipate as much as possible)

since you can't avoid the DAW and (numbers exchange) anyway - choose a format that's easy to handle in your environment
it's really not that important which one...
when I recently asked someone which of 2 tracks he preferred, he choose the version with almost no processing
I use to color sound by microphone: not necessarily by the 'best' one, but the one that 'sounds' right to my ears.
adds some natural overtones, no tubey plugs required... etc... so after all it wasn't really that 'unprocessed'
but the result was quite obvious in a simple 16bit file, a higher resolution wouldn't have improved things
(as the difference was in the method applied)

cheers, Tom

[Yogimeister]

Thats why I was thinking maybe its a bit depth thing ... (The synths via scope sound more full with detail ... And dont forget that when you bounce to your daw you might have two conversions (to your daw and back through scope)

Another clue for me is that when I dither down to 16 bit inside scope it noticeably degrades the sound (much less than with native dither plugs ...) (Which is not saying theres anything bad with the scope system, perhaps even to the contrary ... But yeah, still working on figuring it out as I go ...

[Yogimeister]

P.S.

Thanks dante for explaining .... I will try to put it to practice ....

Gary - I get what you are saying - but to be honest , I havent been doing that (when bouncing offline in the box) and reluctant to do it now too - but doing more and more of it (especially now that I started using scope and scope synths ...)

My old DAW is getting fuller and fuller (maybe I should check if I can add another HDD and then go bonkers

[RA]

I started reading this thread and saw some question on sampledelays and phase problems while mixing, parallel processing and using for example the stm mixers.

I came across this problem while developing the dNa-MasterComp. That has a parallel path which you can mix with the processed signal. The problem is in all digital mixers/processing actually and at all stages it is possible for compensating the introduced delays.

On the scope platform it there are three rules:
-DSP processing on 1 dsp chip introduce no delay
-signal travelling between 2 dspchips ON THE SAME BOARD introduce 2 samples delay
-signal traveling between boards (for the older PCI boards) introduce between 2-6 samples

The problem that occurs...if you keep the placement of the individual DSP blocks internally to a device totally dynamic, you can't predict what the introduced delay is, and thus cannot compensate for this by itself. Now....what does this all mean for example in the mixers? Here we come across the limitations of the DSP chips....it can only do "so much". It is not possible to run for example 24 compressors on 1 single chip. So a 24 track mixer is impossible to make without manual compensation or intentional DSP placement...for example 8 channels on chip 1/ board 1, another 8 on chip 2/ board 1 and so forth. This gives serious implications to the project, because i don't know if there are other devices designed this way, which would give placement problems > compatibility problems. For inserts on that mixer this problem really get's interesting, because that on itself is a device in a device. Soooowwww........It is not possible to automate/keep track of all these delays, and keeping the project dynamic. That is the key to a good plugin for all boards and the xite boxes.

The dNa-MasterComp is internally ALWAYS phasecoherent with it's unprocessed signal, this is why the parallel-function exists on that device. I personally use the MasterComp on busses and/or master on the outboard mixer dm2000. With it's own internal compressors this is not possible without sacrificing a second buss which you should delay.

This is only a problem if you have 2 or more sources which should be kept phasealigned....in a recording studio there is probably no need keeping the guitar track phasealigned with the bass....that slight delay is sooo minor....don't mention this to audio purists....unless you use the mike at the guitaramp as an ambience mike for the bass....and if you took time for aligning it at soundcheck time. Between drum mikes phase is important.

dNa-Super8Tracker is also designed to keep ALL the channels aligned at all times, on all boards, with all setups. That was a real challenge, since the analog function is DSP intensive. Thus it is limited to 8 channels, and there is NO INSERT function on that device. From an audioengineers point of view there is no problem with thinking in blocks of eight, so you can still oversee multiple instances of the Super8Tracker.

Hope it clarifies some of the problems Yogimeister was describing.

[RA]

The best solutions i find for aligning phase between two signals is having your monitoring on MONO, inverting/flipping the phase of one of the signals and delay one of the signals by moving that mike, or delaying one of the signals until maximum cancellation/attenuation (best to have both levels more or less the same)

[Yogimeister]

Thanks for the detailed reply RA ..

Ive had some time to think about the issue (and workarounds) as this might relate to alot of different issues in a "workflow":

1) DSP placement
- is there any way to do specific (or force single dsp/board) for an effect in PCI5.1 ? (No SDK)
- Will using an insert INSIDE the STM (while the stm is set to "board rpiority") keep the inserts on the same board as well ?
- will a loaded multifx (or other) be treated as a "single device" and will be placed on 1 board/dsp ? (Probably not, but asking

This relates to all "manual" phase compensations (e.g. will I get 6msecs delay per insert next time I load the project because the placements have changed ? ... I think that this is the problem I had with my project that I couldnt really replicate ... Because I was adding some compressors and eq as final effects on a loaded project - which was mostly loaded by summing and a "mastering chain")

2) FX-send tracks coming from the sequencer (that are made up of audio from many many different tracks (at different levels) - like a reverb.
Once I introduce (differing) delays to some of the original tracks in scope - those tracks are out of sync (in differing amounts) from the vrb - which can cause noticable artifacts .... Currently the main workaround I can think of is houncing each original track with its send returns and then summing the effected track - but then that means any vrb I add in scope will "vrb the vrb" already on that track ....
If I dont - I have to keep all tracks phase-coherent throughout the summing .... At first I thought I will process them all "symmetrically" (adding a compressor and eq to all busses - even if they are not effecting the audio) - but then there is issue#1 ... Which can change delays each time you load/optimize the project ...


How do you guys deal with this ??

3) synths - im guessing they might be spread out on different boards, right ? Can that scenario cause delays if the signal needs to bounce (maybe several times) between boards ?
(Currently I am getting timing irregularities with most of the recorded synth lines I scrutinized .... But they are not a fixed delay - but rather some sort of "jitter" - I will look deeper into itmand try to meausre the "timing jitter amplitude" to try and understand where it comes from ...





On another note (and one of my suspects of the synths issues )
- Gary said scope works at 48K internally - now, in a 44.1K project - does that means it converts my sequencer's 44.1 audio to 48 - process it - and reduces back to 44.1 ? (Where do these SR changes take place ?)

[garyb]

this "timing jitter amplitude", do you mean midi?
midi is far from sample accurate, you know...

i NEVER, EVER said that Scope works at 48k internally. the Scope environment samplerate is whatever the system sample rate is if Scope is slave, or whatever is set in the samplerate setting window, if Scope is master. maybe you are confusing bitdepth with samplerate.

[Sounddesigner]

Yogimeister , The MIDI timing of your synthesizers should be adjustable in your DAW. Whenever the timing gets off a bit it should be correctable. In Sonar it's called Time+ and it allows you to add or subtract Milliseconds of delay/time to the MIDI being sent and received.

[Yogimeister]

@Gary - no no, definately SR I wanted to try to eliminate SR conversion and/or SamplingOffsets

@SD@Gary - I am not talking about MIDI latency (where its a constant delay) ... (Though I did not consider MIDI "jitter" ... I dont seem to have such problems when exporting "offline" in cubase which is mostly how I do it ... I will check some "realtime" VSTi exports ...

In any case - I havent gathered alot of "statistics" but so far this "jitter" is in quantizations of 3 ms (at 145 BPM, 48K - * need to verify units) - this is what I mean by the "amplitude" - amount of jitter and the quantization (e.g. if its off by increments of 3 - i.e. +3, +6, 0 , +3, +9 , 0 .... Then the "amplitude" would be 9)



Not really sure about a cubase version of time+
(Cubase can manually offset MIDI and can offset for "record latency" - but again - that should be a fixed amount - and disabling that does not affect the jitter)

My Scope is the MASTER clock (in the cubase settings). Is that the best setting ?
Should I activate the VST sync page ? (Its totally inactive in my cubase)

Do you have any Idea what the average midi jitter is ? (Is it scope specific or is the main jitter due to the MIDI protocol ?)

[astroman]

as Gary mentioned: the (clock) timing units of Midi and audio are a completely different dimension
if you want to deal with sample accuracy (on the level you describe) you HAVE to kick Midi out
it cannot work, because even the best digital system has a +/- 1 unit jitter by nature
(at one point it has to decide between upper and lower bounds... time is not continous here)

Windows is an extremely unreliable host in that sense (people keep using MPCs for that purpose)
Midi has a fairly low priority from the OS point of view
running on it's own it's completely lost - sequencers fight this situation by time-stamping data packets
whatever: if just 1 midi frame slips to the 'wrong side', the respective audio is several samples off

regarding latency changes in saved/loaded projects: that's on the sample level as RA explained
(the displacements due to chip loading and board changes)
from my own experience I remember 2-3 samples off, but that was usually 1 project which was constantly modified
(I rarely load 'real' setups - it's more a hardware box for routing on the fly etc)

this may be more reliable with setups that change on a per song/project base
and of course with more 'modern' device design, as in Scope's early days not all developers were fully aware of the situation
(today they usually care about DSP placement)
inside a synth that's not a problem at all (imho) - analog hardware is way more 'drifting' in that sense...
it's even considered a feature there

cheers, Tom

[RA]

If i recall correct, it is possible to make an insert-container with an option to place it manually on a specific DSP (but don't pin me down on this;-)....IF.......the plugin is able to be executed on 1 DSP, and internally kept dynamic and not with dedicated DSP placements....else it will fail/give problems saying DSP full/overload. So....is it wise creating such a forcing container?.....probably not. Do you know where the other channels or the source are/is placed??? Scope distributes the DSP dynamically.

I don't think the STM mixers compensate for an insert's delay (thus applying a delay to ALL THE OTHER channels, since you need 1 delay per channel....simple test....does it increase DSP load if you enable the compensation? Because if you disable that, there would be no need occupying the DSP chips with unneeded delays....(I try to program the dNa plugins so it will unload the unneeded functions from DSP if you don't need them....therefor there is a range of DSP load described on the productpages of the dNa plugins)



In the analog world and analog outboard indeed VERY MINUTE delays are introduced through the components (for example a capacitor) but it is way less that 1 sample in the digital world, is my gut-feeling. I have never compensated analog signals, i could always parallel process and never had the typical phasing sound you get in the digital world even as minute as 1 sample....and 1 sample @48khz is around 21 us if i recall correct. (leave that to the mathematicians)



And as far as jitter...isn't jitter something which applies to digital>analog or analog>digital conversions? Or two seperate digital devices? That is why a lot of studios use a masterclock, which will definitly benefit the freqencies and the stereofield. Jitter is a irregularity in the clock of digital devices, which can be caused by faulty cables, heat etc....(at least so far that is my experience)



There is one trick which you can try to solve timing/phase problems....delay the processed signal even more....like 15-25 ms...which on itself can give chorusing....but it is worth a try. All this best heard listening MONO! this way you can hear clearly what it does on the freq spectrum/bass/highs....

ps....nice discussion here

[garyb]

why would there be a samplerate conversion unless you were running a downsampling plugin?

[Yogimeister]

I thought that maybe SC runs on a faster internal sample rate or oversamples ... It was that "48K internal processing" comment that threw me off ...

In any case, Im trying a 48K project now (to see if I can capture the scope synths sound better


Regarding syncing my daw to the scope clock (having cubase externally clock) - is that more about the sample rate or midi ? (Does it sync midi signals/packets ?)
(My "jitters" occur on monophonic and sparse midi tracks with no automation and a low cpu load ... However, these issues seem to stem from jitters with the output midi from cubase (hence I am thinking of externally clocking it - or going into the "vst system link" settings ...)

Any thoghts/experience on how this would relate to this problem ?

(P.s. I corrected myself, the jitter is in ms , not samples...)

[Yogimeister]

And thanx dNA

I think i can seperate my problems ...

1) internal SCOPE (sample range) latencies that hinder "parallel processing" inside scope - including vst send tracks

2) MIDI jitter (probably in ms) - that causees phasing/pops/transientsmears and general inconsistencies (the main point being this is not a fixed/consistent offset


Seems like the MIDI jitter is a cubase/DAW thing (though there are many links in the chain)...

#1 is probably more about changing my workflow in some instances ....
#2 seems like it could benifit from a configuration tweak ...


Any thoughts/experience ?
(Specifically - see my specific questions in the previous post )


P.S. - @dNa - compensation does increase DSP load - but what Gary said is that it phase aligns the mixer at the inputs and not the outputs ...

@Gary - can you confirm that phase compensation does NOT include the internal channel fx (eq and dynamics)?

[RA]

If i recall correct, the external sync in cubase is just about mtc or a timecode related thing....NOT about the interface syncing. That is handled by scope! So use the samplerate settings in Scope, and if you see a value (in slave modus) it is receiving correct. (else it will display no samplerate)

So external sync in cubase is for external stuff (as in external outboard midigear), being more specific midigear with sequencing in it....if you use outboard midigear just for sound, it has no sync issues. If the outboard gear is just used for sounds you don't need external sync or mtc or mmc etc....It can be that midigear is slow in reaction, that is what midi time correction is used for. If two different sounds(explicitly is state different sounds) are 20us(being MICRO seconds) not in sync, you cannot hear that! A slower developing sound (slower attack) is doing more to the ear than that neglectible latency.

[RA]

Some other question or statement some here.....Why does Scope sound better than native....? I think that has something to do with fixed point calculations(Scope) and floating point calculations (native)
I read some interesting stuff on that by John Watkins (slaying dragons column in Resolution magazine) or maybe an article by Bob Katz or Daniel Weiss....dunno....I cannot reproduce that story....and do i need to....Scope just sounds better Use your ears, since your listeners will do the same whahaha Luke....use the force!

[astroman]

a bit old but that's Midi anyway...
http://www.soundonsound.com/sos/dec07/a ... h_1207.htm
among lots of detils some background about (drifting) midi clock sources

that one contains a list of external devices and their respective midi clock results (measured)
with some prominent members - long list with some surprising content...
http://www.innerclocksystems.com/new%20 ... itmus.html

cheers, Tom