Mixing in Scope - Device latencies/phase problems

[garyb]

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...)

midi sync and audio sync are two completely different things. the samplerate does not affect midi. of course midi is handled in packets. all digital data is in packets. networking is networking.

midi = jitter, period. it's never sample accurate.
computer midi, ANY computer = more jitter than dedicated hardware for reasons explained above.

as to the "48k comment", MANY Scope internals are at 48 BITS. if i ever wrote 48k, it was a typo.

[Yogimeister]

Oh ok ..
(Makes sense as at the time I was also inquiering about the same regarding to bit depth - and whether I should record scope as 32bit float in order to better capture the full "SCOPE SOUND"

(albeit I understand that with 24-48bit we are talking about the realms of the theoretically inaudible ...)

[garyb]

well, if you mean going from 24-48bit or back, then yes, inaudible.
processing in 48bit will probably sound better than processing in 24bit, but of course, the algorithms themselves are just as important as the bit depth.

really, a lot of this is interesting, but meaningless as far as making great music goes...

[astroman]

back to square one...
iirc correctly member scopus preferably uses Modular and Adern extensions for his Psytrance/Chillout stuff
(that enviroment is practically uncontrollable regarding inner-device sample offsets - but does it really matter ?)
give him a listen on soundcloud (for my taste among the best mixes ever done on this system):
https://soundcloud.com/alon-chen

cheers, Tom

[djmicron]

i tried scope sdk pci v5 for the first time today and i see that we have the option to allocate a device to a specific dsp number as it is for the xite version, so it is possible to create for example a specific aux insert device for each dsp available on the scope system.

The problem with this is that we have to load only devices that fits on one dsp on the pci cards and that we have to manually check the dsp load on the desired dsp and make the calculation for the device that we are going to load, but after that, it will be saved with the project and will be the same at the next project reload.

[Yogimeister]

Thanks Tom, informative read - although it doesnt seem to have any new ideas ...

Reagrding the other answers,

Lets avoid diving back in to the debate on whether 3 and more sample differences in parallel processing , or 3 ms MIDI jitter is audible (they are) - and whether you can make music/psy with Scope (of course you can)
(And definately not go into whether in some cases, it makes an audible difference to sum (many quiet) tracks as 32bit rather than 24b (before the actual summing - e.g. via the ASIO interface)


Lets focus on the pains of "realtime"/external MIDI triggering in cubase

the possibility of syncing it to a dedicated hw clock in/via scope and should that help MIDI jitter?
- as well as suggestions of workflows for these situations ...
Anyone ?

[djmicron]

try inside cubase to reduce the ppq resolution, also try to avoid sending midi clock over scope sequencer destination, it can be due to an excessive data flow over midi.

[astroman]

Thanks Tom, informative read - although it doesnt seem to have any new ideas ...
...
Lets focus on the pains of "realtime"/external MIDI triggering in cubase ...

sure there are no new ideas - it's all been said and experienced thousands of times
those references were 'just in case', it's up to you to draw conclusions ...

if you looked at that hardware list you found sample jitter from zero to > 100 samples
on HARDWARE without a crappy OS, completely undisturbed from all those services amd management stuff
only a handful of dedicated devices is capable at all to reliably reproduce their output with less than 5 samples offset

the SOS article explains the different clocks for midi and audio in regard to PC hardware
I didn't read it - but kept the line in mind that there's a startpoint with both in sync
while the system is running, the clocks drift from each other

imho that's enough to simply sack midi as a trigger IF you are after sample accuracy
use an audio track for critical parts (as suggested by Gary) and you'll have 1 precise timing source

cheers, Tom

[fra77x]

Use the sequencer modules of the modular in scope to drive your ext midi hardware
or to trigger the envelopes at the modular, it has excellent timing as scope is a real time system.

There are also other procedures to achieve sample accurate timing for midi (with minimal jitter) but these are way to advanced to be discussed here.

[Yogimeister]

Thanx fra77x,

I am actually looking for a way to "slave" my cubase (I dont use any "external midi" hw - my scope synths are what I consider "external midi" for this case.)

My problem is that cubase midi seems to jitter/wander ...

In cubase there are options to sync to external clock and to sync to ASIO2 clock .... But I am not sure how to generate/send clock signals to cubase from scope... (I dont think I have a syncplate .... But not sure ...

[Yogimeister]

There are also other procedures to achieve sample accurate timing for midi (with minimal jitter) but these are way to advanced to be discussed here.

Thats exactly what most of this thread is about ...

Can you give me a clue as to how to achieve this ???

[fra77x]

First you have to differentiate between the "external clock" of the sequencers and the midi timing/jitter.

The external clock is so to be able to "synchronize" the playback of 2 sequencers or 2 midi devices (or more). It can transfer information like midi tempo, start stop condition, and is generally used so to put 2 devices in the same tempo and perhaps make them start at the "same time". That function has nothing to do with the midi timing of the individual machines. Each one uses it's own way to create the stream of midi data. It just makes them to play together in a specific tempo.

The midi timing/jitter issue is different. It is about how accurate is the midi stream. That is what you experience with cubase when you try to drive scope synths via midi.
In general the midi timing of any computer suffers because windows or any popular OS is not a real time system and because midi is abandoned as a old technology that is replaced by the sample accurate vst instruments. In the past some manufacturers have addressed that problem by creating midi interfaces that get the midi stream from the computer (time-stamped) and then re-sync it and send it to the instruments. (old logic interfaces). A simple arduino with it's 8-bit microprocessor can create very good midi timing because it is a real time system.
In general through the years developers have somehow managed to provide better midi accuracy (reaper has quite good midi timing) but none of it is as accurate as a dedicated sequencer that uses a real-time os. And none of them is able to create a tight midi sequence as some electronic genres require. Several people address that problem by sampling, or recording audio and then "cure" it by repositioning the individual events but all these methods are very frustrating.



For better solutions pm me if you'd like.

[Yogimeister]

Yeah,

Now I am starting to understand why Ive seen so many psy producers trim and position each "synth hit" in the Re-recorded audio ... (And thats what Ive been doing too - for example when trying to use saturn to generate an offbeat HH at 145BPM) - this is more of a problem when having synth lines that are legato and dense - but still have audio transients (like a running TB)

In any case, Cubase used to have a "MIDI sync reference - time code or audio clock" option (in cubase vst) - but I cant find anything like that in cubase 5.5 .... (Maybe it has to do with the "system timestamp" thing ...


What cubase does have is an "audio clock source" selection - which can be "internal" or "external".
(There is also the syncing options - in which I am not interested in the MidiMachineControl - and dont need "position specific timecode" - I was just thinking that maybe using an external "clock source" will help to reduce midi jitter ... (As long as the jitter is not cause by PC/CPU overload and/or MIDI congestion - but the thing is that the jitter happenes on a fairly empty project, with the MIDI channel soloed (and the midi performance is very sparse - e.g. Quarternote HH)

I have been reading alot about the subject (cubase had a Midex peipheral that buffered and synced midi like you described) - but besides reducing MIDI data

[Bud Weiser]

... midi interfaces that get the midi stream from the computer (time-stamped) and then re-sync it and send it to the instruments. (old logic interfaces).

and Steinberg LTB MIDI interfaces Midex-3 and Midex-8.

A simple arduino with it's 8-bit microprocessor can create very good midi timing because it is a real time system.

Yep.
What do you think about ATARI MIDI timing ?

And none of them is able to create a tight midi sequence as some electronic genres require.

My old Yamaha QX-1 is pretty tight and a (older?) AKAI MPC is too for sure.

... but all these methods are very frustrating.

Yes, that´s why I hate almost any DAW MIDI sequencer.
It´s all good a s long it all goes to the VSTis, but when it goes out of the box to hardware MIDI modukles and synths,- it sucks more or less.

Bud

[Bud Weiser]

... Maybe it has to do with the "system timestamp" thing ...

When I used Cubase SX3, it was essential checking "use system timestamp" !
There were USB-MIDI-driver issues in that aera and only the latest USB-MIDI-driver which came for the LTB MIDI interfaces was stable.

I think in Cubase 5.5 this should be sorted out, but usage of system time stamping is still essential.

I´ve found out that rules for Presonus Studio One Pro 2 too.

The main issue w/ computer mainboards is, you never know what´s the reference clock for you DAW application and external USB-MIDI interface is,- QPC (query performance timer) or TGT (forgot what the shortform means, sorry).
In fact, it´s all trial and error ...
I know old Emagic Unitor-8mkII and AMT interfaces (I heard, RME too) use TGT as their reference clock and other interfaces using "system timestamp" use QPC as their reference clock.
So, some MIDI interfaces prefer "system timestamp" unchecked while others prefer it being checked.

Both clocks, QPC and TGT exist on every mobo,- but you never know which is the most stable one on which mobo,- there´s the culprit.

In fact, the procedure is, find the DAW application you prefer, find the right USB MIDI interface, find the perfect mobo (which is almost impossible) and when you did, you have something good for MIDI but eventually shows flaws in the audio department or compatibility issues w/ realtime system DSP cards or whatever unforseeable crap.

I imagine and/or hope MIDI over LAN, p.ex. w/ Copperlan,- might improve or eliminate these issues.
The network system inside a machine has much higher priority in the OS than USB has and ethernet switch latency and jitter is in the nano seconds while it is in the millliseconds range w/ every other MIDI interface,- parallel port, serial port or USB, where parallel port in my experience was/is the most tight solution up to now,- depending on drivers by nature.

Bud

[Yogimeister]

@bud

Well, ive always gotten best results with "use system timestamp" - but im a newbie at using external MIDI (running scope synths and recording them).

And my audio system is SCOPE PCI (duh)



I imagined that since SCOPE has a buffer (of several ms) it could get the (timestamped ?) MIDI packets and trigger them in time - even if they arrived a bit late ...
(That seems to be what the midex does)

In any case: tgt, qpc ... I am trying to sync cubase to a SCOPE clock (instead) - if thats possible (which might have less jitter than the OS clocks provide - and might work better at correcting the packet timing when they arrive into scope ...)


Or is this thing totally not feasible ??
(Can I use the ASIO2 clock input for that - for example ??)

[fra77x]

"and Steinberg LTB MIDI interfaces Midex-3 and Midex-8"

I have Midex-3 and i can hear the sync process itself. It doesn't suit my purposes. I haven't used Midex-8.

"What do you think about ATARI MIDI timing "

I haven't used that by i like ATARI MIDI timing because people swears that it works right.

The same applies for your old Yamaha QX-1 and the older AKAI MPC for sure. I have a mc-50 (roland) here but it is so old that the oscillator is not accurate any more. My 15 euro arduino beat it easily.

Copperlan at least for communication with a virtual box on the same computer is not accurate enough.

It's very funny the whole midi jitter problem. Just google it and it's still around in all modern sequencers. Unfortunately i can't say how i solve that problem, it is part of my sound

[Bud Weiser]

"and Steinberg LTB MIDI interfaces Midex-3 and Midex-8"

I have Midex-3 and i can hear the sync process itself. It doesn't suit my purposes. I haven't used Midex-8.

Can be all works just only like a standard MIDI interface now since Steini discontinued older hardware incl. Midex-3 and -8.
Nothing indicates LTB technology in software still exists in Cubase versions higher then v4 and since they discontinued the hardware MIDI interfaces.
If it doesn´t work satisfying w/ Midex-3 it also won´t w/ Midiex-8 because that´s only a larger MIDI interface being designed as a USB-hub.

I haven't used that by i like ATARI MIDI timing because people swears that it works right.

Well, I found it to be more accurate than any USB MIDI interface solution, but also not really accurate.
It won´t be (sample-) accurate anyway, not yet and not in the past or future.
It´s MIDI ...

My 15 euro arduino beat it easily.

So,- what´s that little Arduino project your talking about ?

Copperlan at least for communication with a virtual box on the same computer is not accurate enough.

I just hoped it would be more accurate than running MIDI over USB and when you mean the Oracle VM Virtual Box I didn´t even think of such usage at all.

It's very funny the whole midi jitter problem. Just google it and it's still around in all modern sequencers.

True !

Unfortunately i can't say how i solve that problem, it is part of my sound

Cool statement !
Have some good music and probably noone will recognize any timing problems at all,- up to a certain degree.

When we worked w/ the ATARIs in studios in the past, we recognized minor timing issues w/ MIDI too,- but that were the ears of the "makers", not the music consumer´s ears and feel,- and the "older technology reference" were CV/ Gate and clock pulses of different resolutions.
CV/Gate and clocks were always tighter than any MIDI.

But I´d say, some glitches, coming w/ some kind of human factor, are welcome too.
If it´s all extremely accurate, it might be unpleasing to the ear and mood too.

Bud

[fra77x]

"So,- what´s that little Arduino project your talking about ? "

It is not a project...

MIDI_ard.png

"probably noone will recognize any timing problems at all"

It is always the style. Fast paced music with fast parallel lines like psy trance is difficult to create with real time midi without proper midi timing. Of course there are always several workarounds. Pretend that no one cares or senses it is the worst between them.

"But I´d say, some glitches, coming w/ some kind of human factor, are welcome too.
If it´s all extremely accurate, it might be unpleasing to the ear and mood too"

I have to disagree. I need to have the absolute mechanical when i need it and introduce the glitches on purpose. I can't compromise with the inaccuracies of equipment. At a final resolution i will design it again so to fulfill my aims (the equipment). My ears and my sense of rhythmic repetition are extremely sensitive... Poor me!

[Bud Weiser]

@bud

Well, ive always gotten best results with "use system timestamp" - but im a newbie at using external MIDI (running scope synths and recording them).

And my audio system is SCOPE PCI (duh)

Any issues come up only w/ external (OUTGOING !!!) MIDI.
Internal MIDI works,- p.ex. a MIDI track in a DAW feeds a VSTi.

When you talk "external MIDI" and "running SCOPE synths and recording ´em",- you have SCOPE on a different machine and your DAW sequencer on another one,- or have ´em both on the same machine, the DAW streaming MIDI via the MIDI Sequencer Source into the SCOPE environment ?

I imagined that since SCOPE has a buffer (of several ms) it could get the (timestamped ?) MIDI packets and trigger them in time - even if they arrived a bit late ...
(That seems to be what the midex does)

In opposite to the Emagic Unitor mkII and AMT USB MIDI interfaces, at least the MIDEX-8 interface worked like a hardware sequencer.
Emagic Logic Audio Platinum up to version 5 (last one supporting PC) and Steinberg Cubase/Nuendo up to version 4 at least,- worked different, even there was the same intention in the ballpark.
BOTH, LTB or AMT MIDI interfaces, required the support of the software which was technology wise,- AMT (advanced midi timing) for Logic and LTB (linear time base) for Cubase/Nuendo.

In Cubase/Nuendo and because every DAW application has a hidden pre-roll time of size "X" the user won´t recognize as long as the GUI followed exactly the tracks running,- all MIDI events in the song were collected and transfered into memory of the Midex-8 within pre-roll time and before the sequencer ever reached their positions.
These events were time stamped and the Midex-8 itself was able to fire these events to the outside world when the sequencer application reached that position, just only by comparing the time-stamp list and the position of the sequencer timeline.
That way, the events itself had allready passed the multi-layer drivers of the Windows USB system before they became part of the song running (cannot explain better, sorry).
It really worked, now also w/ large MIDI sysex strings, w/ the latest driver (IIRC v1.92), the Midex-8 and Cubase SX-3.

The Emagic AMTs followed a similar idea which was developed earlier,- but even the MIDI events were transfered to the AMT interface before their position in that song was reached,- they needed a trigger impulse from the software to be fired to the outside world from Unitor-8mkII & AMT.
That was what killed the timing w/ a PC (but not a MAC !), just because that trigger impulse had to pass thru Windows multi layer drivers too.
In fact, that was the real reason why Emagic stopped supporting Windows.
They found it just too cumbersome programming around Windows´ flaws.

In any case: tgt, qpc ... I am trying to sync cubase to a SCOPE clock (instead) - if thats possible (which might have less jitter than the OS clocks provide - and might work better at correcting the packet timing when they arrive into scope ...)

I fear, also SCOPE is addicted to some mobo/OS clocks too,- the PCI cards as well as the PCIe card of a XITE box or a XITE-PCIexpress card connected to a Windows laptop,- they all use computer reference clocks.
That´s why I mentioned RME in my former post.
P.ex., you have a RME audio card may it be PCI or PCIe ...
The card offers a MIDI I/O,- just like a SCOPE PCI card (or XITE box) ...
The RME card will use TGT and will probably work better w/ system time stamp being un-checked.

The SCOPE card may behave different when you use it´s physical MIDI I/Os in standalone mode only, but when Windows comes in the ballpark w/ Sequencer MIDI Source/Destination which are nothing more than drivers, you will run into the same scenario than w/ any other MIDI interface out there and it will use some reference clock.

Or is this thing totally not feasible ??
(Can I use the ASIO2 clock input for that - for example ??)

Don´t understand.

ASIO time stamping is totally independent from MIDI.
ASIO is for audio.

Bud