I’m using Mixbus 32c V6.à.655 on Win10, 48k, 1024 buffersize, ASIO. I have an issue with the midiclock and/or the start/continue messages. They always start too early in relation to the grid, and this offset seems to be related to some latency compensation: if I insert a plugin that needs PDC (even the limiter on the main bus) the start/continue messages are issued even earlier but did not identify a clear sample-accurate pattern. I spent countless hours checking every possibility I could think of, and reported the issue to Harrison support. The audio latency compensation is spot on: I have correctly calibrated the audio hardware and it’s sample accurate. Very nice. But all my hardware sequencers and other time based devices start early which is a serious issue. I managed to struggle my way through my current project using LTC and a SMPTE-to-midi synchronizer I have but it’s an old device from the 80’s and is more jittery than I like for the music I make in 2020 and its tight midi timing . Before spending 550€ on a ERM multiclock (I lost all my paid gigs for this summer due to Covid …)I thought I’d turn to this forum… maybe this is a known issue and it’s already under investigation…
It should start one clock early. Because in order to define the tempo two clock ticks are needed.
That being said, I’m surprised that Mixbus 6.0 exposes those at all. I was under the impression that these settings were hidden because they were not working correctly at the time Mixbus 6.0 was released.
I have fixed MTC and LTC (both generators and slaves) for Ardour 6.0, that will be available in Mixbus 6.1.
However I have no first hand experience with MIDI-Clock and no hardware to test. That is still on the ToDo list.
Thanks for your quick response. Yes, I have configured systemic Midi latency, but that makes things even worse. I found the measured latency very high indeed: 554+554 samples. If I use those measurements, the synced sequencer’s reference click is recorded 1520 samples ahead of the grid. If I set this latency compensation to 0+0, the click is recorded around 1100 samples ahead of the grid. This is VERY audible, of course. If I record the DAW’s own metronome by routing it internally to a audio track, it’s recorded 274 samples ahead of the grid. I have not managed to get anything right on the grid during the last 3 days I’ve been troubleshooting this. (Except when using SMPTE based midi sync). What do you mean exactly by
BTW, I can I download and install the Ardour demo without messing up my MixBus install? It was my intention anyway to check if this happens in Ardour too.
One bug for MTC and LTC was a missing minus sign. The latency was added not subtracted.
(Ardour/Mixbus needs to send values early, so that by the time they reach the analog MIDI it aligns with audible audio). That’s fixed in Ardour 6.0.
No they are exposed, both generators and slaves. I can see incoming midi clock but disabled slaves, ackowledging that this is currently under development. But I wouldn’t have thought that Midi clock and LTC generators should have been disabled (to be fair, that is so essential to me that I wouldn’t even have bought the product if I couldn’t slave anything to it… Mind, this is almost the case. Only the LTC generator seems solid. (Except that we can’t enter bits in the offset, a frame being the smallest offset we can set and that’s too large a window to adjust midi alignment…)
But maybe not for Midi Real Time messages? I don’t use MTC, none of my external hardware has that implemented . I use Elektron machines, and a Pyramid sequencer, just to name a few. These are synced by Midi Real Time messages only, and SPP according to the configuration.
I will be more than willing to help out, I have a multi-decades long experience in betatesting audio software, and did some VST coding of my own too. I have all the equipment, a complex midi setup full understanding of what to look for.
Which buffer size are you using? With a 1024 buffer size, I got similar results than you. For me, calibrating MIDI does not work, and I filed this bug https://tracker.ardour.org/view.php?id=8054 Can you check if you can reproduce it?
Also, that delay in samples is proportional to the buffer size, so, if I reduced it to 512, it will be next to 512 samples.
Edit: As I noted in the other thread, I got these results with a 3 buffer periods. If I switch to 2, the calibration values are far lower, but I could not sync’d the recorded MIDI to the grid yet:
I’m using 1024 samples buffersize. Indeed, I don’t think the midi calibration works as it should. I see the diffrence, but I don’t see any logic behind the numbers-result relationship. I just filed a bug report too. I’ll check yours as soon as I can dedicate some time to it. Hope this can be figured out, it’s a show stopper for the type of music I’m producing where tight sync is mandatory.
EDIT: I looked at your bug report and there’s something we need to keep in mind: if the latency compensation for audio is not applied to the midi signals, the more we change audio latency compensations (like when changing buffersizes or numbers) the more we have the impression that the midi has moved, but that’s an illusion: the audio delay changes, but the graphical representation does not change, so we have the impression that it’s the midi delay that has changed. It has not. It’s the grid that has moved relative to " absolute time-zero"
…)I thought I’d turn to this forum… maybe this is a known issue and it’s already under investigation…