Hi! While playing keyboard I noticed it looks like that recorded notes result behind the time they were played.
So I tried to play in sync with allready recorded midi notes. Every time new recorded material appeared behind previous.
I tried then to just record midi notes from one track to another. Don’t know how accurate is this type of test is but here is what I got.
Upper track is the source of midi messages, and lower one (“hh”) records them. You can see that recorded material is behind the original. I can see how after recording is stopped notes get shifted back. and at different takes this interval might be different. I got something like 567 and 760 samples so far.
How can I affect this process and make it shift recorded notes back properly? Issue is fundamental.
Ardour version is 6.7. And here are the routings
The problem is that hh/midi in is connected to both a physical input as well as the an Ardour track’s output.
Since JACK merges the MIDI event Ardour cannot tell if the MIDI data comes from the LaunchKey Mini or the Ardour Track.
In this case Ardour picks the worst case latency, assumes that data comes from the LaunchKey. Ardour compensates for the latency between pressing a key on the device and the data being visible by Ardour and hence moves the MIDI event back in time at rec-stop.
Simply disconnect the physical inputs when bouncing MIDI. In your case make sure that neither “General MIDI Synth Track” nor “hh” is connected to any external sources.
And more generally avoid allmany to one connections.
–
PS. you can override this from the “hh” track-header context menu, Capture Alignment.
Hi Robin. Thanks for your time. I disconnected the keyboard and still it appears before original. And its different time interval at every take. may be I should calibrate things somehow?
That is unusual. Can you do a quick test if this also happens when you use Ardour/ALSA (no jack)?
There are is anecdotal evidence that with jack2 specifically latency is not correctly reported for newly created tracks, but it’s not reliably reproducible (also jack1 is not affected).
with alsa it’s much better I can minimize the drift to couple of samples. What I mean by that is when I reopen the project and do the same track to track midi recording (same tracks different playlist on recieving track) alignment might become different from previous session.
When I record audio from midi track with instrument to another audio track though, audio appears later than midi messages on midi tracks piano roll
Couple of questions: If I select alsa there is a calibration dialog. can I use it’s result with jack somehow?
generally, I see (and probably not only me) MusicN <-(jackd)-> DAW system as most flexible instrument for music production. But are those timing issues resolvable? Like sending Ardour’s midi messages to Supercollider and recording Supercollider’s audio back to Ardour, without nudging audio manually. Would I be better off with jack1?
when bouncing track → track. It should be +/- 2 samples (rounding errors when converting music-time (bar/beat) to sample-time and back.
This could be synth-plugin related, or even instrument specific e.g. a slow attack time. How far off is it?
No. JACK does not support systemic MIDI latency, but for the case at hand that should make no difference. When you use Ardour → Supercollider → Ardour, no hardware MIDI device is involved.
Might be worth a try, that might fix the MIDI → MIDI track bounce issue.
But now that I think of it, there is a circular dependency:
jackd calls Ardour
Ardour produces MIDI output
jackd wakes up supercollider
SC reads the MIDI, and produces audio
All JACK clients have been called. Next process cycle begins.
jackd calls Ardour, the resulting audio from (4) is only now available to Ardour. 1 cycle late.
I don’t know if SC sets its jack port latency accordingly; check with jack_lsp -l if the supercollider jack port has a capture latency equal to the buffer-size.
It is currently not possible to manually override a port’s latency, but you could add a “virtual/artificial latency” plugin to the target track. There’s a LADSPA one from swh, and nodelay.lv2 can also be used to that end.
Here’s a hack: You could use Supercollider as plugin inside Ardour!
Sadly SC doesn’t currently offer that anymore (back in the day there was a AU), but you could use Carla as bridge.
Load Carla as plugin in Ardour, then start Supercollider from inside Carla (it can expose JACK clients as plugins). – I don’t know if that is viable, but might be worth a try.
I record from midi track with it’s default General Midi synth (“Stereo Grand”),
I made several consequent takes and every take had recorded audio differently delayed: 12, 26, 54, 64, 32, 35, 61 (samples)
What I think, in my case it would be better to align manually. So I would have predictable delay ± jitter. Is it possible to disable that midi/audio alignment in ardour (maybe Mixbus) ?
Yes this one aligns perfectly in my setup as well, be is alsa or jack both align presicely.
But again with SC things are much more complicated and running it as a plugin I think is not a solution. I’m ready to align manually, but ardour’s auto-alignment kind of stands in a way, doing routing dependent calculations. Thus again my question (could not find while googling). Is it possible to turn this alignment off, so that I’ll have more predictable (transparent) dealys, that not depend on routing?
Yes, in the track-header’s context menu: set Alignment to “Capture Time” and Ardour will place MIDI notes or the region using the current sample-time as-is.
However you also play MIDI into SC, and Ardour will read-ahead data if SC’s jack port reports a playback-latency. This cannot be disabled.
if midi messages come from midi keyboard, there is no readahead, it will be placed as it is?
if I disconnect master from hw now recorded midi notes appear just right under original ones (pic). What is the procedure to make them appear like that with master connected to hw.
There is capture latency (how long has it been since the signal arrived). At record-stop, Ardour places the region earlier on the timeline to align it with existing material that is being played back while recording.
You can override this as described above by using “capture-time”.
When using “Auto” Ardour picks existing material for all ports with physical (hardware) connections, and capture-time otherwise (usually JACK clients, or ardour tracks).
This concerns playback latency (how long will it be until the signal will become audible). There is no way to override this. As far as I know, disconnecting the output is the only option.
You could perhaps whip up a JACK application that passes through data as-is, but always reports zero playback latency for all writable jack ports.
I guess I found a solution, so in case anybody faces same I did following.
Download jack_delay from Fons Andriansen’s site. Extract and compile (run ‘make’ in it’s “source” dir)
Connect audio card’s physical output to input
Start jack_delay with -E -I -O, where:
-O playback port connect output to named port.
-I capture port connect input to named port.
-E show excess latency instead of full latency.
Example from my system:
jack_delay -E -I system:capture_1 -O system:playback_1
port names taken from qjackctl graph
jack_delay will report latency value. half of it should go to jackd’s -I option,and half to -O option.
If you use qjackctl “Latency I/O” options in Settings/Advanced tab are the same thing
