Hi,

I'm creating a loop station and I've got several questions about different issues.

1. Latency
2. Fading/Cutting recorded samples at start and end
3. Metronom settings

1) Latency
I'm using the latency tester from the repo.
http://www.pdpatchrepo.info/patches/patch/92

Latency might be calculated with different methods:
a ) Connecting the output of the soundcard directly to the input via cable. This way the lowest possible latency is received. (Around 440 samples in my case)
b ) Calculating via microphone and speakers. Latency will be higher compared to a ). Also the bigger the distance between mic and speakers, the higher the latency will be.

Which calculation should be used?
(To me it seemes to be logical, to use the latency calculated by b ), as that is the method which reflects the real circumstances. But I'm not shure and it's very hard to tell by what I hear.)

2) Fading/Cutting recorded samples at start and end

When the recorded sample contains a phrase which is completly finished before the next 1, doing a fade with [vline~] sounds OK. But when you record a continuous sound (like a string pad) you will always hear that fade of [vline~].
Compared to Reaper: Cutting a sound and looping it, will result in a continuous sound. To me it seemes like some kind of crossfade between the beginning and the end of the sample is done.

Does someone know more about this? How should it be done correctly?

Crossfading seemes to be a quite difficult task in my eyes, as a lot of calculation has to be done. (Recording has to start a bit earlier and to stop later, sync has to start earlier, and so on)

3) Metronom settings

This loop station depends on a metronom and works similar to Ableton Live. As pd uses blocks of 64 samples, the tempo is corrected to a tempo which corresponds to an array with a size multiple of 64. So playing can easily be kept in sync.

I'm not shure about this. Is it a good idea to do it like this?
But changing this to a manner, where the tempo might be chosen freely, will result in much more complicated calculations. Is it worth it?

Thanks for any comments in advance,
Xaver

My patch is still in development and can be found here:
https://github.com/XRoemer/puredata/tree/master/loop-machine
(downloading from github: go up one folder and use the download/clone button
https://github.com/XRoemer/puredata/tree/master)

loop-machine2.zip

@xgr I am not sure that latency will matter much. All the work will be done in Pd in real-time and you will just hear the result with a small delay that should not be enough to be disturbing for your brain.

The biggest problem with (not noticing) an edit will be a difference of volume (power). Our ears are very sensitive to that.
The second biggest problem will be the quality.... timbre..... but as you say a crossfade could help. But the bigger the difference the longer the crossfade needs to be.
In a real music environment it will be less noticeable if it is right on the beat.

If you zip up your complete patch and post it here it is easier for us than downloading all of the raw files from github.

Here is a looper that I built (in a hurry) for live performance with a violinist (very aware of latency).......... it has no [vline~]....... it just cuts directly.......
loop.zip
(probably "extended" sorry.... but that can be fixed........ there is nothing very unusual).

I mix it with the direct sound at the mixing desk. No complaints in the 2 years or so that I have been using it.
It sends a "click track" for the musician to stay in time, and can be controlled from my phone. It stops automatically at the end of a measure (I called it a pattern because I didn't know better) after the "cue seen" button has been pressed, or it can be programmed to stop after "X" measures.
You can set the length of the "count-in".
David.

2. Crossfading can easily be done like this:

I put the slider there just for clarity's sake--you'll obviously want to use the [vline~] or some other audio input instead.

3. I don't understand exactly what you're describing here, but it might help to know that [vline~] is sub-sample accurate, meaning that it can be triggered between blocks.
   This is not the case with the older [line~], however, which can only be triggered on block boundaries.

I changed my first post and uploaded a zip at the end.
Works with Purr Data or pd (plus zexy)

@whale-av
Thanks for your patch. I tested it with extended, but I get latency issues. When I record saying something like "tik" on the beat, the "tik" is heavily delayed to the metronom on playback. But on pd extended I can't set the latency lower than 24 msecs. So there might be some issues with extendend on my machine. (pd or Purr Data let me set the latency to 5 msecs without problems.)

You wrote: The biggest problem with (not noticing) an edit will be a difference of volume (power). Our ears are very sensitive to that.
The second biggest problem will be the quality.... timbre..... but as you say a crossfade could help. But the bigger the difference the longer the crossfade needs to be.
I thought about starting recording a little bit earlier and stop somewhat later, so I can crossfade between these extra samples. And maybe it's easier than I thought.

@LiamG
Thanks. How can I trigger between blocks? I thought messages are only send once during a block, aren't they?
About 3): I was wondering, if it is a problem, not to be able to set the exact metronom tempo

And here's a little screenshot to see what it looks like:

I would say, anything above 5 ms latency between the metronom and some voices starts to feel strange. And when you start to change your reference - say you start recording with the metronom, change to first recorded line as a reference, than to the second etc, - the latency will sum up and increase.
I wonder how latency is treated on hardware loop stations.
And I'm still asking myself how latency should be treated to get it right.

Regards,
Xaver

@xgr The problem will be your soundcard. I use a Motu 828 hybrid for my in ear monitoring system...... and an ESI U24XL for the looping.

The Motu will accept a Pd -audiobuf setting of 2ms without dropouts...... and the U24XL will work well at 3ms....... both running through Asio4All as the driver.
You will absolutely need asio or whatever the equivalent is for your OS.

My violinist is monitoring through the Motu....... with the loop on the ESI.......... and the local desk is nowadays always digital...... so you can add 2ms for the desk.
So you can reckon 2+3+3+2+maybe 2 for the computer/Pd?......... so 12ms. For my violinist with the acoustic original sound stuck to one ear and an earpiece in the other ear it seems to him as though he is playing with another "himself" 12 feet away...... and he doesn't notice.

Echoes from the back of the auditorium upset him sometimes...... so he has to remember to stay with the click.

The latency will not add up within Pd. The latencies are in the adc and the dac.
Hardware solutions software are written in assembly language for minimum latency.
David.

@whale-av
I'm using a RME Fireface uc with it's own Asio driver on Win7/10. On Purr Data or vanilla I can set latency to 2 ms as well, but the roundtrip latency tester gives me the same results for 2-5 ms (around 440 samples measured with cable). With a 48 sample buffer instead of 64 on my soundcard I receive even worse values.
But on pd-extended it just doesn't work. Don't know why, but as it's not updated anymore, I prefer working with vanilla and Purr Data.

Anyway - in the manner I'm trying to loop, latency doesn't really matter, but you have to know it's length. Even with a latency of 50 ms or more you won't notice any offset in the recorded loops as long as you know the exact length of the latency.
Tracks get recorded and shifted by the latency afterwards, so latency should be compensated.

You're right, latency won't add up in Pd. But I don't use an in ear system. So if you change your reference from a metronom to a recorded track and from that track to the next recorded one, you will add up latency when the latency isn't compensated.

Xaver

@xgr I will have to chew on that while I sleep...... and look at your patch tomorrow.
Extended should not behave differently than vanilla with asio....... they both just chuck out streams of 64bit chunks.

At first it seems to me that the only latency problem is that after playing along the new recording will be effectively delayed. But you can fix this later at mastering. You could record the click track to a second channel (having sent it out and back in) to aid with re-syncing. The distance from ear to monitoring you can measure physically and calculate the delay. That delay could then even be added to the recorded click track making the re-sync very easy......... just match the peaks........ could probably be automated.

Will that help? I have worked with musicians where we had to cut and paste every note later. They don't necessarily play in time anyway.
David.

@LiamG
Thanks. How can I trigger between blocks? I thought messages are only send once during a block, aren't they?

My understanding is that blocking only affects audio rate objects, not messages. Audio rate objects can only be triggered on block boundaries, but [vline~] interpolates to create line where it ought to be.

There are some good threads about this on the mailing list. I can't work out how to link to them, but go to the filing-cabinet icon at the top of this page and search for "vline sub sample". In particular, check the thread "[PD] Sample-accurate sequencing techniques" from 2011.

@whale-av

They don't necessarily play in time anyway.

Well, nor do I.

But you can fix this later at mastering. You could record the click track to a second channel (having sent it out and back in) to aid with re-syncing. The distance from ear to monitoring you can measure physically and calculate the delay.

And when I know the latency in advance, I can record while I play along and shift the recording afterwards, so it'll be in sync again.
I'm not shure, but I think, when I use Katja's latency patch, it measures the latency between speakers and microphone. Only trouble might be too much ambient noise.

@LiamG
For now I tried to crossfade at the end of the sample. I'm mixing a fade-in of the start of the sample with a fade-out of the end of the sample.

Maybe this picture is helpfull for a better understanding:

The startsamples are taken from $0-temp, which is recorded first and which is delayed by the latency.
$0-sound is the array used for playback.

I tried to use a crossfade of equal power, but still I can hear a little dip when the sample is restarted.
This is the calculation: expr ( 1 - cos( $f1 * (3.14159 / 2) ) )
with 0 < $f1 < 1

This is, what it looks like in a scope:

The first row shows the cutted sample $0-sound. It's start is around 112800 samples. On the left side you can see the end with a fade out.
The second row shows the fade-in of the start sample.
The third row is the mixed result.

Here's the new patch:
loop-machine.7z

Are there any ideas of how the mixing can be done better?

Xaver

Check out the mmb abstraction library: https://github.com/dotmmb/mmb

It has some good tools for mixing and might give you what you're looking for.

Also check out alfaloop, I think it is using a crossfade loop.
http://www.pdpatchrepo.info/patches/patch/155
Cheers~