latency and playback issues, a video is worth a thousand words

midi echo ...

what people omit to realize is that this can be also a CUMULATIVE latency of many light latency plugs of VSTi's that will start crippling the responsivness of sonar during writing or recording.

That's not accurate. The net latency of the project will be equal to the latency of the plug-in that needs the greatest amount of Plug-in Delay Compensation. SONAR and all the other plugs in the project will get their business done within that window.


I agree, however that it would be nice to have a status indicator showing what the current PDC value is in samples and milliseconds, and which plug-in is causing it.

Actually it is the cumulative latency of the largest plugin chain - let's say you're using 1 eq on each of the 1st 10 channels, but on the 11th channels
you're using a limiter, a compressor, a reverb and a multiband watchamacallit, those will be cumulated and used to disctate the
latency of the rest of the tracks, and god knows how many of us like to have our guitars souding pretty treated during recording -

brundlefly

Actually it is the cumulative latency of the largest plugin chain

Okay. That's true. I was thinking of plugs in different tracks. But yes, each plug in a chain has to get its processing done before the signal can go to the next plug, so that's cumulative.


In any case, to get back to your original concern. it should be sufficient to cycle the audio engine, or just run the transport to get SONAR to recalculate the PDC. I've never run into a situation where that would not do the trick.

by cycling you mean turning off/on the audio engine?

I hear some phasing going on and a change in timing. If you let it play longer do they come back in sync? I'm wondering if there might be some some difference in a quantinization setting between the two.

Finally got around to clicking on the video link.

There have been a number of issues reported with Matrix timing. I had never tried it, but just did. I ran a full drum sequence through it in parallel with the same clip driving SD3.

I get similar results, but the Matrix by itself sounds much tighter, and the phase error between the two is no more than you would get sending two streams of identical MIDI to a hardware synth. I could definitely hear the wonky/variable timing of Matrix in your video, but I'm not getting that here.

Ignoring the bad timing you seemed to get, I think the root of the minor phase error I'm getting is that Matrix works by sending its MIDI to a track which then echoes it to the synth. So it's more like real-time MIDI input vs. the way the audio for a MIDI clip in a synth track is buffered up in advance, and thus acts just like rendered audio with no delay in echoing MIDI or synth response.

Based on previous testing, SONAR takes a couple of milliseconds to echo live MIDI to a soft synth, and some soft synths do not respond instantly to real-time MIDI, so there's no way audio from a live MIDI stream and a "pre-rendered" audio from the same synth are going to be perfectly in sync with no phase error.

But in the real world, you're not going to send duplicate MIDI notes to the same synth. So I redirected the Matrix cell to an instrument track using SI Drums, and the two played in sync to the point that I'm pretty sure an uninformed listener would not realize he was listening to two layered synths. And if the patterns were different, which would be even more realworld, you'd definitely not hear any error.

I'm not denying you and other users might be seeing a bigger problem, but based on what I'm seeing in this admittedly basic test of functionality, the Matrix has no timing issues that you would notice in a real project.

Incidentally, SD3 will exhibit the same phasyness if you have it play a pattern internally that is also being played by a copy of the pattern in a MIDI/Instrument track.