Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Need a hand...
#1
Hi, I've been talking to Ben already (using the support mail) about issues concerning LTC and Midi Timecode (both are "early" relative to the grid on my setup)

It's a matter that has stopped me in my work and I'm trying to find a fix for days now, and this might involve

Could someone please do a little test for me to confirm something?

Very simple: route the metronome internally to a audio track, and record a bar. Are the clicks on the grid, and if not, by how many samples are they off, and what are the details (samplerate, reported PDC, anything that might seem relevant)?

This would be very helpful.

Thanks in advance,
Dirk
Reply
#2
Recording a click to a track input click out is recorded but what you hear while recording is strange because there is a delayed sound so doubles.
the recorded has only one click but whether it is recorded before or after the generated click I could not find out.
To tell the truth after the crazy sound when recording the click I was not interested to go on....
Tassy
Win7/64, Mixbus32C, Mixbus2.5 the QueenSmile UR22, Dynaudio BM5A MKII, Pc all SSD,
Reply
#3
Hi, thanks for taking the time to do this little experiment . What you describe sort of confirms that it's not related to my specific system. Basically, what happens is that there's an issue with hardware latency compensation relative to clocked streams that are hardware independant, such as internal routings. So, the metronome starts running, midiclock starts streaming and midi start messages are sent too early relative to the grid. This means that external devices synced to Mixbus start too early to. Latency compensation for full audio roundtrips, once the hardware calibration has been properly executed, is spot on: that's great. But midi sync and internal routing is incorrectly clocked. Like I said, I have reported the issue but didn't hear back yet. It's pretty annoying, I do not have such issues with other DAW's and if this is not fixed rapidly, I have the choice to buy a ERM multiclock for 550€ or switch to another DAW. I really like MixBus, great sounding, great workflow, but it's a showstopper if I can't count on the sync. It should be "set and forget" and this is not the case....yet.
Reply
#4
(05-25-2020, 12:48 PM)Dirk Offringa Wrote: Hi, thanks for taking the time to do this little experiment . What you describe sort of confirms that it's not related to my specific system. Basically, what happens is that there's an issue with hardware latency compensation relative to clocked streams that are hardware independant, such as internal routings. So, the metronome starts running, midiclock starts streaming and midi start messages are sent too early relative to the grid. This means that external devices synced to Mixbus start too early to. Latency compensation for full audio roundtrips, once the hardware calibration has been properly executed, is spot on: that's great. But midi sync and internal routing is incorrectly clocked. Like I said, I have reported the issue but didn't hear back yet. It's pretty annoying, I do not have such issues with other DAW's and if this is not fixed rapidly, I have the choice to buy a ERM multiclock for 550€ or switch to another DAW. I really like MixBus, great sounding, great workflow, but it's a showstopper if I can't count on the sync. It should be "set and forget" and this is not the case....yet.
Is this related to your question? Using Ardour 6 which I assume is same audio engine.
Ive tried recording from a midi drum track to mix down to audio.
Routing from midi drum track direct to another track the sync is lost and the audio is early.
But... If midi drum track is routed to an audio bus and then to an audio track it is recorded in sync to the midi track...


Attached Files Thumbnail(s)
   
Reply
#5
(05-26-2020, 07:57 AM)m4granger Wrote: Is this related to your question? Using Ardour 6 which I assume is same audio engine.
Ive tried recording from a midi drum track to mix down to audio.
Routing from midi drum track direct to another track the sync is lost and the audio is early.
But... If midi drum track is routed to an audio bus and then to an audio track it is recorded in sync to the midi track...


Hi, well, it might be related, yes. My particular focus is on getting external drum machines playing in sync. They should start when we hear the audio played back from mixbus, and it looks like they start 1 buffer early which is 1024 samples in my case. That's a lot. I sincerly believe there's something fundamentally wrong here, and am quite exhausted from spending countless hours trying to find a definitive answer. If only we could set a delay on the midi start message I would be happy. There still would be jitter, but at least it would work. I can code an Arduino sketch for the RK002 midi processor to delay the message, but it would be completely disconnected from the audio: and the amount of the offset is dependent on the samplerate, buffersize and PDC. If we add a lookahead limiter on a track somwhere that needs delay compensation, all the audio moves but the midi clock doesn't so it changes all the time... we cannot compensate for that externally.
Reply
#6
Where are you monitoring the drum machine audio? You're sending a MIDI clock start from Mixbus to a MIDI interface to the drum machine, it starts when it receives that and you hear that where as being late?
Win10pro(2004) : i7 8700/RX570 8gb/16gb/970evo : RME PCIe Multiface : Mixbus 32c 4.3 & 7.2
Other DAWs: Logic 10.4 (MacBook) Cubase 10.5 (PC)
Music: https://jamielang.bandcamp.com
Reply
#7
(05-26-2020, 10:55 PM)JamieLang Wrote: Where are you monitoring the drum machine audio? You're sending a MIDI clock start from Mixbus to a MIDI interface to the drum machine, it starts when it receives that and you hear that where as being late?

Moritoring through hardware. As you say, but sequencers start early, not late. Probably because a wrong latency compensation, if any, is applied to the Midi Real Time messages (start/stop/continue). Latency compensation delays the audio, but it should delay outgoing midi as well. It doesn't. I checked: this happens in Ardour 6.0 too, so I reported it on Ardour's bug tracker. I found, via the Ardour forums, that I'm not the only one that has raised this concern.

If it's not critical for your music, and/or use small buffersizes, you might not notice this even though it's there for real.
Reply
#8
I haven't used external MIDI in 20 years. But, also I can't fathom doing what I do with MIDI in Mixbus at all. So it certainly doesn't affect me in the slightest.

I was just pointing out that there's a critical piece of info there. What if they come back and say arm a input in Mixbus and monitor? Is it still early? Thing is--when you're using external stuff like that, it can't be both....and the market has gotten...really fond of software monitoring. So really, it might be less a bug fix and an additional option they have to add. You know? Because the audio input HAS to be delayed by X....so sending the MIDI early so that it sounds in the Mixbus mixer "at the right place in time" would be a version of "correct". Do you have the option checked to handle the monitoring with hardware in the preferences? That would be the most astute thing to do--tie it in there--assume if they select hardware to delay the outgoing MIDI...if they say "with Mixbus", send it early.

It took Steinberg about 5-6 years after implementing full IO compensation to get stuff ACTUALLY working. Maybe longer--I left them in the mean time and wouldn't use it again until it passed all my tests. Logic's still has all kinds of holes. Here's hoping they get it all ironed out quicker!
Win10pro(2004) : i7 8700/RX570 8gb/16gb/970evo : RME PCIe Multiface : Mixbus 32c 4.3 & 7.2
Other DAWs: Logic 10.4 (MacBook) Cubase 10.5 (PC)
Music: https://jamielang.bandcamp.com
Reply
#9
Yes of course I have hardware monitoring checked. But what you say about montoring through software being "correct" doesn't affect this issue at all. This is a real bug: it's about synchronizing external gear. External gear is a audio source like any other. Be it a musician or a machine, both start playing along to what comes out of the speakers regardless of which method of monitoring is used, and both produce sound that must be recorded on the grid correctly. The musician takes its cue from the metronome, the sequencer cues to a "start" message. This start message is early, that's all. Here's a screenshot. From top to bottom

- a reference track with a click
- a click from a drum machine started by MixBus's MidiClock
- a click from a drum machine started by a SMPTE (LTC)-to-midi syncronizer started by MixBus's LTC generator

This is "what you see is what you hear".

   
Reply
#10
Follow-up: the issue has been confirmed by the Ardour dev team and is being taken care of. I guess the fix will propagate into next MixBus update. Here's the feedback:

Quote:This should be fixed since Ardour 6.0-44-gef94663d1c

The main problem was that Ardour just sent start/continue message instantly, and not at MIDI Clock downbeats. Nor was the clock every in sync with music-time beats.
In all versions prior to 6.0.44 Ardour just used it to indicate [clock] speed (and state).

Dirk
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)