Mixing in Scope - Device latencies/phase problems

[astroman]

... Technically there is no reason for midi jitter (as far as I understand) BECAUSE its not realtime events ... Its just metadata about upcoming "events" - it should be handled with ease with a small buffer and a timestamp ....
But again - Im not trying to make up logic in this scenario ...

but you're getting closer...
original midi was strictly realtime, clocked by a 38 kilobit/sec (iirc) serial dataline
the timestamp thing is kind of an extension for 'modern environments' where bits travel at almost arbitrary rates

but at the end of the chain (with Scope) those bits hit in fact a realtime system
a strength on one hand - but sensitive to certain errors on the other...
it's worth considering that Scope's design is from a time when it was lightyears ahead of PC hardware
(I bought my first Pulsar about 2 years after the first release... for a Celeron 333 system)
the design phase (for obvious reasons) was even earlier...

'timestamping' itself is valid only in it's own 'grid'
once the border is crossed some method to adjust sender and receiver applies
... obviously (as reported earlier) not all such 'sync-code' is created equal...

midi bits in the software domain are 'unclocked' - just like digital audio is safe from jitter while in a buffer
when they are converted back for action some errors are unavoidable
... and the source of that error may be on either side of the connection
(just because a timestamp looks more 'sophisticated' doesn't make it more reliable by default)

cheers, Tom

[RA]

I stumbled upon a site which might shed some light again on these problems, and maybe has some solutions....
Nice articles on this subject etc, and here you can see that a lot of hardware isn't so great in timing.

Thought i'd share it here, maybe someone has experiences with these devices.

http://www.innerclocksystems.com/New%20 ... ducts.html

[RA]

And here also some info on GS:
With possible solutions and tweaks etc

https://www.gearslutz.com/board/music-c ... -midi.html

[Yogimeister]

@Astro - I hear ya,
But keep in mind that the domain I am digging in is the sw domain (between the sequencer and the scope on the same PC - no hw midi outs or cables - and no "Real" physical external hw ...


I dont know how "reliable" the time stamps are - but it seems that cubase (and live) make some effort to overcome this issue of midi jitter / offsets by implementing time stamps (system clock, or whatever)

What I am trying to do is find a way to timestamp the midi with similar precision as the audio wordclock or something similar ....
There is an example in the VRC-128 manual - but it didnt mention if this affects MIDI.
Also, the VRC-128 and VRC-S crash my scope when loading them ... So i cant check ...

I tried the scope midi clock and BC midi clock to both Seq.Dest. (Clock MIDI out) and ASIO2 (clock freq, gate, MTCtoClock) - but cubase doesnt seem to really sync - and there was no impact on the jitter ...





@RA - yeah, ive gone over those articles too
Im still trying to understand if the emulated directmusic mode adds any value (it seems, when I unhide all drivers - that scope/cubase uses emulated directmusic ports for MIDI in(to cubase) and WindowsMIDI for out ....

That being said ...
Here is a small update -
When sending out a midiclock over the midi port from cubase to scope - i see a consistent improvement of about 20-25% in the amount of jitter (as measured by the values in the midijittertest program I posted here...)

I dont think I have managed to send a midiclock (or wordclock) into cubase and properly sync it though .... The main promise of that could be a "roundtrip" sync - because at the moment I dont think scope is receiving timestamped midi that relates to its internal clock (but rather - the system clock) - but thats just a semi-educated guesstimation ...

(The IO section of the scope manual talks about syncing ADAT(as an example) with cubase using the ASIO2 clock - I did that using the clock modular modules instead of the ADAT clock - but I still havent figured out if its applicable to MIDI or if Im doing it right ... Right now I am getting no effect from syncing this way ...)

[astroman]

well, you're not entirely in the software domain
Scope has it's own timebase to sync all hardware on the PCI board
this may be clocked by external hardware, but I'm not shure if the same can be derived from Asio2
(dunno how Asio sync works internally...)

at least you're assured now that there IS a difference between Asio and Asio 2

according to the VRC manual Cubase can sync it's sampleclock via Asio2
maybe things improve by selecting the SMPTE option as suggested (even if you don't deal with video)
the manual refers to run VDAT in sync with a sequencer
but possibly it might link stuff better, too - without running the tape

I have Scope 5.1 under XP32, SP3... same stalling of VRC and SRC devices here
but I have a 2nd system with an original Alesis BRC
VRC is entirely an emulation of that hardware, which uses midi sysex for it's protocol iirc
in fact I only understood the device after reading the Alesis papers...

remote control of static functions like track selection and arming is easy and reliable...
but once 'tape transport' is involved things can get really weird
I wouldn't hold my breath on that thing in a modern environment...
(that's why I run it on a dedicated box under Win98 with nothing else on it)

cheers, Tom

[jksuperstar]

I stumbled upon a site which might shed some light again on these problems, and maybe has some solutions....
Nice articles on this subject etc, and here you can see that a lot of hardware isn't so great in timing.

Thought i'd share it here, maybe someone has experiences with these devices.

http://www.innerclocksystems.com/New%20 ... ducts.html

It would be interesting to run the same tests that innerclock systems runs on SCOPE->Hardware out. For science! and Just Because.

[astroman]

you could even simplify it by tracking Scope with VDAT and the sequencer via Asio simultaneously...

cheers, Tom

[Yogimeister]

you could even simplify it by tracking Scope with VDAT and the sequencer via Asio simultaneously...

cheers, Tom

Not sure about how to do that .... I couldnt get my clock/sync to go thru ASIO2 (and are you suggesting to loop the acope audio out back to the vdat in ?)

[Yogimeister]

And yeah, I couldnt load the VRCs (is it possible to run it or is it incompatible with 5.1?)

And I couldnt seem to replicate feeding the scope clock module or bc midi clock via ASIO2 ...

(The improvement I got is not dependant on the ASIO 2 protocol AFAIK - its about sending out midi clock from cubase to the PCI ...

My next hope was to try and sync the cubase clock and the PCI clock (if these things exist ....)

Do you know if the clock format output by the VRC/VRC is the same as the clock coming out of the scope/bc clock modules (MIDI or implicit clock output in the scope device)? (I also tried the MTCtoClock device between the clock modules and ASIO2 - but still no effect ....

[jksuperstar]

In My Knowledge:
The VRC/VDAT "clock" is related to audio, not MIDI. It is closer to samplerate(Audio Clock), and not related at all to song tempo (MIDI Clock). However, it also adds "tape" positional information (since the ADAT being emulated was a tape), so you can jump/scrub to specific points (begin, end, start of guitar solo, etc). This one clock I've used twice maybe 12 years ago, so I can't really comment on SCOPE's version of this. But the rest of this post is very accurate.

ASIO2 clock is solely for Audio SampleRate.

Its confusing because MIDI has 3 clocks:
-MIDI Clock is a simple tick, like listening to your wrist watch (but not looking at it!...there are 24 ticks per quarter note, but no other information). It is related to the tempo of the song.
-MIDI Time Code is a MIDI version of SMPTE, and was a method for syncing audio to video. It's ok for the purpose, but does not carry any info regarding tempo, so it's useless on its own for sequencing/synchronizing any devices or programs accurately, especially driving synths/delays. It's like a running song position pointer, but isn't accurate enough for tempo purposes.
-Then there is a rarely used MIDI Tick, which is a pulse every 10ms. No tempo or song info at all.

VRC I think is ok (I don't use it), but there is no 9-pin sync port on XITE for use externally. VDAT works, but you HAVE to load it on DSP2.

[astroman]

... Not sure about how to do that .... I couldnt get my clock/sync to go thru ASIO2 (and are you suggesting to loop the acope audio out back to the vdat in ?)

that was only related to the timing test, which doesn't need the 2 systems synced
you run a Scope sequencer (modular or midi) into a percussive sound device
that devices output is recorded by VDAT
the output is connected (by a 2nd wire) to Asio destination and recorded by Cubase

later you can load the VDAT track in Cubase, adjust a transient in the beginning and compare those 2 files
any deviations should be obvious

I never checked the VRC sync data in depth, but would assume it's MTC/SMTPE as that's what the hardware is about
dunno if Alesis always succeeded in real world, but according to specs the method provides sample accurate sync of several such 'tape' machines

my XP is fairly messy so I may have something in the background that the VRC doesn't like
in Win7 it works, as user MusicManiac recently confirmed

cheers, Tom

[jksuperstar]

I think the ADAT clock is more accurate than MTC/SMPTE...SMPTE is frame accurate for video...but that's 24fps - 60fps. MTC is directly related to SMPTE.

Like astroman says, ADAT is sample accurate, so it adds audio samplerate clock (ie-word clock) as well as provide info about WHICH sample (positional information).

[astroman]

while Adat is sample accurate, it still uses SMPTE for tape positioning
after the standard hours:minutes:seconds:frame number there's an extension for subframes 0-99
each subframe is divided into 15-19 'sample steps' (depending on format)

the BRC (after which the VRC is modelled) syncs this to a 48khz clock pulse, while the data information is passed by serial cable
to be honest: it's hard to imagine that (say) 3 massive tapes were able to be sync-positioned accurately by this method...
but that's what they write

not sure if those signals from the VRC are required at all
maybe it's enough to just activate SMPTE beween Scope and Cubase - to have them coupled tighter...
at least SAW suggested Scope Asio as SMTPE Source and Destination when I checked what was offered
(plus MTC via the virtual midi ports)
btw subframes seem to be a regular feature: 0-400 were available for adjustment setting

cheers, Tom

[Yogimeister]

Yeah, but somehow I am not getting cubase to recognize communications through MIDI (with the clock modules and MTCtoClk).
(The sync indicator shows "Idle")

Basically the framerate of the project should match the incoming sync - and I was thinking that maybe that is the problem (although there is an option to automatically detect frame rate changes ...)

Thats why I am digging around the VRCs and TripleDAT (which has an the option to set the frame rate) - as I want to try changing the MTC signal I am sending into Cubase ...
(Does anyone know id VCRs and TripleDAT devices should work in 5.1 ?)


Thanks

[tgstgs]

read a bit through the post;
maybe some background . .
sharc asm is cool and uses more than 32 bit for internal processing;
the outputvalues are 32 bit but the calculations are higher_

for sync signals there is no delay from out to inport on same dsp;
there is a delay between 2 dsps;
the amount of delay is samplerate dependant
but its the same for all dsps;
meaning a //blue cable from dsp1 over dsp 3 to dsp 5 has the same delay than
from 1 over 4 to 5;
a cable from 1 over 2 over 3 to 5 has more delay than
from 1 over 4 to 5;
//
this is the streght of the pci boards
for the developers the option on same dsp is enough to handle phase;
NOT for xite;
here you have different delays between dsps;
these are:
between
old dsps
old to new dsp
new to new on same slot
new to new on different slot;
that plus the different amount of connections between dsps are the trouble big old plugs have on the xite;
the only solution i found was to assign each device to a fix dsp;
the automatic dsp optimizing algo is obsolete;
you save a tweaked project load again and the algo shuffles your devices to different dsp than on the last day = different delays than on the last day = different sound;
not nessersary but possible;
if _ htan maybe not hearable but measurable;
and what i learned from musicians is that they have ears that are able to hear this nuances;
not normal hobbyists but proffesionals hear it for sure__

for midi uses async signals;
but they are NOT the same than nativ async processes;
dsp async has a fix rate that is always sync to the samplerate;
native midi is handle somewhen if there is time to_
like all the native stuff happens somewhen if there is time to if not its delayed_
thats the cpupain there is no absolute controll over the exact time when it happens;
if a notnice background process trys to call ms in the background even if no network is active your midioutshortmsg fu*s off_
in combination with the native timestamps in milliseconds = delays whenever a rounding error to absolute microsec appears;
on dsp you can exactly make a process start at a defined sample position and you can be sure that it will happen always at the same time;
if not you are not able to load on dsp__
in native the os decides when what is executed_
the fix for native is to oversize the cpu let 75percent run in idle;

scope midi suffers from some devices with a to small input buffer size 128;
if you feed to much events into some might be lost;
if it is a midinoteOFF = hanging notes;

ok are the midisource dest devices
was not able to overflow them_
so as a rule if you get trouble splitt your midi to different red cables;
and avoid merging;
if i remember right one of the merger is source of small inbufferpain here

good vibes from vienna

[Music Manic]

......in any case, yes - that would solve the reverb problem (the vrb track is 100 wet of course) - but it also means that I have to do the same for all send FX (according to this method, i cannot use and "communal" sendfx channels inside cubase (and i usually have some distortion smash, chorus, vrb, delays and the likes as send fx channels)

But that leaves us with phasing of one channel against a different channel ....


I measured the delay and it was 4 samples (bass compared to kick) - when I adjusted it - i suddenly was hit by the lowend that was "hidden" (the bass track is actually made of a bass+ sub track - so by itself it has plenty of low end ....)

When you use a DAW and Scope for parallel compression and layering you have to understand the delays caused by the plugins. There's no way around it. One you get your sound record it into an audio track. It would be great if the scope mixer could save a few channel settings to be imported in when you need the same settings.

I started this thread

http://forums.planetz.com/viewtopic.php ... 6adb1baa0b

[RA]

I stumbled again on some nice stuff about midi, latency and timing issues....

It is from the dutch wiki page....
"Door de snelheid van 31,25 kbit/s duurt het versturen van een enkele MIDI-boodschap van drie bytes ongeveer 1 milliseconde. Hierdoor kunnen noten nooit absoluut gelijktijdig aan- en uitgezet worden. "

Which says something like:
"Because of the speed of 31.25 kbit/s sending 1 midi message (3 bytes) takes about 1ms. Because of this notes cannot ever be in sync."

Thus it is not windows causing the midi shifts, it is in the midi protocol. Yes there are devices with tight timing, but i guess they don't comply with the standard midi protocol.

Thought i'd share this.