MSuperLooper massive Delay when using midi controller? Different controllers have hughe latency differences.My fault!

[mccy]

Hi!
I found a 40+ms/2000+samples delay when using a midi-controller for remote. I had the impression, that it was not perfect, but these values make me sad

I used babyface pro with 64 samples latency & nanoPAD2 (which has about a millisecond MIDI-delay, if I remember correctly from my old tests) (((EDIT: That was the problem, I did not remember correctly IT HAS ABOUT 20ms latency, the other 20ms came from 'realearn', but there is even a solution working with such controllers, see below))).

My test goes like thi in this case:
I lay a microphone next to the nanopad and knock hard on the pad which starts MSuperLooper record in toggle-mode (via realearn)). After a second I hit it again, which starts the looper)
I hear a perfect loop..... BUT!: What I hear is the SECOND hit on the pad which is found in the end of the recording, not the start-hit. Of course I would expect to miss something like 5 milliseconds (have to do the test with ableton, but I bet it's much much faster with the Live looper effect).

This is my measuring in reaper (attached picture)

MeldaSuperLooper Delay.jpg

:

[mccy]

Ableton seems to have less then 20ms delay when live-looping with the looper effect.

[mccy]

I was wrong, but what went wrong?
I tested MSuperLooper within Ableton and it shows much faster values measured in reaper...

[mccy]

... ups. Within reaper and only within Meldas MIDI mapping I get the best values

melda3.jpg

....

So AGAIN, MELDA wins!!!!????? What the fk!?!? I have to take a break.

[mccy]

So maybe it is a good idea to delay the Looper-input about 15ms, but running playback undelayed... will test that. Then there is perfect timing for WHAT is recorded. I guess the 15ms delay on the change from monitoring to looping-listenig wont make a problem. I just like it, when things are precise (and when I export that recorded tracks it really matters...)...
ah, but that's only for the first loop, which sets the tempo. the other loops will be in timing....

[mccy]

Aaaah, that works perfectly!!!!
That would be easy to build in the MSuperLooper, as kind of a delay-compensation.
It would be great, if a (setable) delay would be activated for the recording of the FIRST recorded loop, so that the timing for the first transient is perfect. That would also help when exporting the tracks. In many cases the first track is beatboxing when I make music for live-dancing-performances, so it would be great if the first transient is really at the beginning of the track!

[MrBauer]

Don't know how useful your tests are. One thing you should factor out is yourself. YOU hit the buttons and you have a human error margin.

[mccy]

No. I'm working with loopers for many years now. This really does matter. Being human is one thing, but being human & having delayed reacting gear is worse. I am able to do nearly perfect beatboxing in timing for the first loop. Now with the added delay the recordings ARE PERFECT! (For my taste, of course; I am not perfect:-) )

I have heard many using loopers which were not able to start and stop recording in time. That's ok for looping in sync to a sequencer, but not, when you build up a whole improvized setup with first loop giving the timing. For that purpose the quality of your performance really changes with the precision in your rhythm & control.

You won't tell a drummer: "Hey, you're human anyway, forget about that 20ms." 20 ms IS A LOT!

[mccy]

Is this mentioned somewhere?
When I change loops in track 1, to an empty loop, then the cursor stops moving & starts moving when hitting record, so the earlier loops on track 1 get out of timing. Seems to work correct on other tracks. Once you have finished Track 1/Loop1, the timing should be fixed, even when it's set to an empty loop and the other loops continue playing.

I know, this thing, the looper, has become much bigger than expected, but I think it is just becoming something really good. Why not changing the loops via commands like 'next/previous track' = 'next/previous loop' so one could maybe even navigate whole columns and rows like in Ableton. Maybe even beeing able to select between 4/8/16 loops on a Track. Seems so near, getting close to a really nice MELDA Audio-Looper-Sequencer.

[MeldaProduction]

Ok so I'm quite lost here . Isn't this some kind of a buggy MIDI controller or something?? I mean we cannot really cheat time

[mccy]

Oh, no, not again these thoughts. Why do I allways have to stay on these themes for so long until developer realize that I have a real point here. I'm not a newbe with looping I consider myself to be very deep in the topic, concerning livelooping and timing, because I'm working live for many years now with loopers.

My testings are absolute consistant. There is nothing buggy here.

Could you tell me, what the midi-latency in activating and stopping the recording is, in MSuperLooper? How long does it take, to start recording an audio signal from pressing a hardware-Midi-button to the first millisecond of audio recorded inside MSuperLooper?

Is there something in my tests which is not logical or consistant? So today I will start making them on MACbook with a different midicontroller, to be sure, that the results are reproducable.

What I found out is:
0. With a test I can prove that timing is not correct. First transient is swallowed, when it comes with the Midi-control-hit, but it is in the end of the recording (when the rhythm is repeating and would start with the same transient in repeat), because recording-stop is delayed too.
1. I should not use Reapers Realearn script, which seems to introduce some latency. In that case Abletons looper was faster than that solution.
2. Introducing a delay for the recorded audio (monitoring without delay!!!) makes the recording 100% perfect and predictable when starting with rhythmical loops. FINALLY the first transient is captured and I can make reliable beats in the first loop.

It would be so easy now, to solve a problem, which I have with loopers (not hardware ones, my Boss 505 is working perfectly) for so many years. I tried every piece of software I could find. Mobius still is the most reliable software-thing in timing. I'm working with a DJ and make NOT SYNCHORONIZED beats to his music (I have to resync via Restart button of course) and this works with mobius like with no other software I tried. Now MSuperLooper is such a big hope to finally have a real solution in software.

Please help me to explain, what the problems is. I do any test you suggest!!!! If I could explain it in german, it would be so easy. My english is so ugly.

[mccy]

So MACbooktest with following results:
Nearly perfect timing (babyface (notPro) and Arturia beatstep (not Pro)). I wouldn't complain about that tiny offset. So I'll go back to Windows and make deeper tests. Next one will be, if Reaper recording midi and audio at the same time will be delayed in any direction, to test if MIDI in Reaper has a problem in my setup.

[mccy]

O.K. I take a step back. Thanks for your critical comments MRBauer & Vojtech. I have a midi-Timing problem in my Windows computer which has not been there before. Grrrr. Crazy shit.

[mccy]

I'm so sorry, the problem was nanoPAD2 with more than 20ms MIDI delay (even on MAC), when sending notes. Maybe it will be better with sending control signals.
Arturia Beatstep had only 3ms (thats what I tested with MAC, now I exchanged the nanoPAD to beatstep).
Crazy, I was sure that I tested the nanoPAD once with very good results.

Anyway a delay feature for recording the first take when livelooping (with slow controllers) would make sense, but yes, I guess only handfull of users would use it.

[mccy]

Ok so I'm quite lost here . Isn't this some kind of a buggy MIDI controller or something?? I mean we cannot really cheat time

O.k. I try to summarize my delay-topic:

- Midi Controllers have latency (Up to more than 20ms in my tests) Some are nearly perfect. My live solution with a massive Midi Pedal has about 1ms latency, or my new Keith Mcmillen Bop Pad solution with about 2ms.

- when recording the FIRST Loop it really matters for capturing the first transients, while e.g. beatboxing, that this delay will be 'compensated' in the looper. So if someone uses midi controllers with some more milliseconds delay this is quite important. Of course 3ms is a value where you don't really think about such 'timing' issues. Nevertheless even these 3ms make a tiny difference to the positive, when being compensated. Yes, human errors vary more than 3ms, but human error and latency ADDs and so it gets worse.

- I allready did that 'compensating' in another situation by monitoring in 'realtime' (No added delay), but delaying the Signal to be recorded in the looper.
That way the first transient is captured perfectly in the loop. yes the whole loop will be delayed 20ms, but ONLY that first loop, which ist perfecly allright for live looping as a one-man-show. nobody will notice it.
But after that the recording delay is set off and when you make synced additional loops you really snap to that first transient on the first beat. Because of the synced recording start in following loops midi delay does not matter any more. This makes the whole session more precice when you think about exporting. I hate using exported waves with destroyed first transient.

- There would be even a better way to prevent loss of first transient caused by bad midi-timing. but that is out of reach for me. Vojtech, I bet you could do it...: like Field recorders often have a small buffer (some about 30seconds) which is constantly recorded without record being started, and then when you hit record, you can even record
noise 'from the past' .
with a few milliseconds prebuffer the first transient could be captured, although midi timing is too slow to capture it. yes there is a problem at the end of the loop, but that can be at least corrected in the recording. with a bad midi- controller you'll have a rhythmical 20ms gap after the first recording, but that is no problem in a live-situation where you are not synced to any other musician.

The first method of record delay is completely fine and very easy to implement. The prebuffer is an interesting but not necassary option.

I hope my description makes it clear now, whats it about. I will try to further explain if there is anything strange in my thoughts.

thanks

martin