] [Thread Prev
Re: Real-time category
Jeff Larson wrote:
> Again assuming a 256 block size example, at any moment in time,
> you are receiving audio that was captured 5.8ms in the past. If you
> are embedding looper commands in the audio stream they will always
> be delayed by 5.8ms. MIDI latency is only around 2ms, so the commands
> will arrive at the looper faster using MIDI.
But if the latency for audio and Midi is the same, I prefer it over
something which I have to adjust to each other. The overall latency is
less of a problem than the difference in latency....
> Now after waiting 5.8ms for that command to come in you start to buffer
> the sample that was triggered. It still takes 5.8ms for this sample
> to be heard by the musician so the perceived latency is 11.6ms.
This would only be an issue if you ever want to feed audio directly from
input to the output. You could just use the common zero latency
monitoring of most interfaces for that or just listen to a direct signal
with your mixer.
As we are talking about loopers, this is definitely not an issue. All I
want to hear from the looper is delayed on purpose! I never want a
shorter delay than 11ms I want more, usually much more.
> Embedding the command in the audio stream works very well for
> recording control commands like record, overdub, insert, multiply, etc.
> because it will be exactly aligned with the audio that is to be modified,
> and since we are not changing what is being played the added latency
> doesn't matter. But for triggering commands it makes the latency worse.
But we have the choice, for looping commands we can use audio, for
triggering samples we can use Midi. And if I want it really thight, I
set my block size to 64 (standard for me anyway) or even 16 samples and
if I restrict myself to what is possible with hardware loopers, I'll
never run into performance problems...
       
\\\ /|() ()|\
))))) )| | |( \\\
/// \ \_/)/ )))))
14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France
Phone at CCMIX +33-1-49 77 51 72