Latency between Max and Pro tools
Hi there !
In my patch (simplified to the maximum), I send a midi note, from Protools to Max.
Midi play in protools > Max midi bus > Max software.
This midi note send a bang to a play object (a short sound like a metronome), this sound goes to a bus output (here dolby renderer), to go back to protools be recorded in it.
Protools Buffer : 128
Max Buffer : 32, overdrive Checked
I'm around 100 samples latency for this loop., between midi note and audio recorded. I wonder if i can reduce latency with a magic trick or does it seems normal to you ?
And second question, a bit weirder : each time I record, latency is not the same, sometime less 70-80 samples, to 120 samples approx. Seems random. Does it mean something.
Dolby driver should be stable. as it is made to sync to go forth and back between Protools and Dolby renderer...
I've tested with "Protools bus 1-6", stil the same issue.
Is there a way / good practice to sample accurate sync two softwares ? Both are in the same mac, so I thought I shouldn't have to sync them, but it creates doubts in me.
Many thanks for reading me, if you have any thoughts or idea, I would be happy to have your feedback.
Cheers
Maybe explain why you should need max to trigger a sample for Protools - which after all has its own sample players.
Hi Florian, sure ! Thanks for asking/
I would like to do a custom metronome kind, outside protools. I'm a sound engineer and used to record orchestra. We have to record lots of music, lots of "songs" in a short time. It happens when we start a recording session and the conductor would like to change the click sound on the go, when it happens, we have to do it in every protools sessions. Could go to 50-60 sessions for a single day. So having a dedicated soft that manage the click and do not change when changing protools sessions would be marvelous :)
Getting back in protools is for rooting facilities in some situations, with analogue desk/ or large setup.
This is the starting point, thinking it as an software expander. But after that I would like to implement other functions, specific for orchestra recording. (volume followers etc).
Worst case scenario, 100 samples delay is not so bad, I can live with that, but moving delay from record to record... could be tricky.
Many thanks for reading me !
I still don't get it.
Assuming that triggers are on a separate MIDI track.
An instrument track with a sample player plugin receives this and plays sample.
Save this instrument track as a track template.
Next session, import this track.
If sample changes, save track as template again overwriting previous.
Why doesn't this do?
(for not very time-critical applications, I have used the round-trip through Max, even including Csound, and had quite some fun.)
Not sure this helps, but Max has objects for MIDI Sync and Ableton Link.
Maybe Black Hole instead of Dolby for send click sound back to Pro Tools.
Make aggregate device in Mac Applications/MIDI audio setup
You can use Dolby for 130 orchestra mics
And Blackhole (from Max) to get instantly changeable custom click tone
@Florian : Sure, currently we are doing a way like that. Works well, but when recording orchestra we have so much to do on the fly... sometimes just closing and opening a session take less than 20sec, and it is to long for the conductor. During close/open we chat about next music, mezzopiano to piano etc and we forget to load the click track.
And being honest, it is for max programming fun too :) And if I can create a more practical tool...
@Will : I've tested blackhole, IAC bus, still the same result.
@Namakemon : Thanks, I'll test that in the next days.
Any round trip of data between Protools and Max (or any other software, for that matter) will be subject to buffer settings on either side. The 'worst case 100 samples' which you report, to me seems to suggest minimal buffer settings on both sides already. Hard to improve on.
On the other hand, where did you find sample-sensitive orchestra conductors? :)
You are right, average 100 samples delay is around 2ms, so I think no conductor would ever hear it. :)
But moving window, even 30 samples, is really aukward. Unable to hear it, but I would like to understand where it happens...
And, I have found the trouble maker. It is the "play~" object
Replacing play by groove object > 64 samples fixed delay. (same midi trigger path for groove, same ouput path). So here it is.
Maybe the tigger information / analysis for play~ is not sample accurate, "calculation clock" under the hood is not precise under 1 ms, like certain object (snapshot or other). It is a supposition.
Thanks for yours feedbacks, very appreciated, and I will definitely tested link objects for other purpose.
Cheers !