so, does the drum loop need to properly “sliced” prior to loading? I experimented with using the quantize function with live recorded clips on MLR, and found that quantize funciton had an effect on pitch of the original recorded buffer. does quantize just take the buffer or clip and divide it into equal divisions?

quantizing will fit your loop to mlr’s current tempo, so if you recorded your loop at a different tempo mlr will change the speed of your loop to match (which effects the pitch).
if you activate quantization for your track before recording to the buffer, the loop should be recorded in sync with mlr’s internal clock.

if you want to prepare a loop to load into mlr, just make sure you have made a perfect loop at whatever tempo you wish to work in. quantize your track, load the clip & set mlr’s tempo to match the loop’s tempo.

4 Likes

Is there anyway to live record just one loop? Was having trouble with that last night.

the current implementation does not take the same approach for “grab a single quantized loop” as the older mlr versions. it would be possible to implement this if i can come up with a UI

2 Likes

Alt+record to record for only the next full loop? Would definitely make whatever i was trying to do last night much easier.

5 Likes

makes sense. thanks for the explanation :slight_smile:

I’ve found a large volume drop between the Norns input level and the MLR playback volume. This was after my first use of the 2.2.1 update. I have been using this electric thumb piano https://www.uncommongoods.com/product/cedar-thumb-pianos . The recording level is fine in other apps (I checked Otis in particular). I haven’t had this volume drop before although I can’t recall using the piano with MLR. Any thoughts? Obviously I tried the record and output levels on the tracks I was trying to record to

I had a similar issue at some point and after a few (2 I think) restarts it came back to normal, but it was before 2.2.1 and it’s been updated a lot since then so I don’t know. Also if the battery is low you might experience some strange behavior with MLR. It’s been fine for me lately though.

be sure to update your mlr as well as 2.2.1 as some changes happened

I always update MLR, and then MLR updates me.

6 Likes

I’ve updated Norns, reinstalled MLR 2.2.1 and tested with an OP 1 and still no luck I’m afraid. I just can’t figure out what I’m doing wrong. I can hear the loops just faintly.
Additionally the mixer section UI only responds to in/out on all apps at the moment. I’m not sure if that is new? Also, general load and stability issues since the Norns update. I will raise in the help thread if it continues

1 Like

My only guess is, what is the volume level, on the mixer page (or in the audio section of the global settings) for the softcut channel? I could be mistaken, but a low volume setting on softcut could be part of the issue…

Thanks. This was an early check as it seemed to me to be the obvious thing. All on max in the mixer section and correspondingly in global settings.

After a bit more exploration… the problem is lack of pre amp on the thumb piano which is obvious however the same device works with Otis. If it’s not a hardware issue can the input gain be adjusted through lua?
I have encountered the following puzzling issues in the process of working this out…
After loading a sample and returning to the “home” page enc 2 takes me back to the sample loading page in the audio library as if to load another sample. Is this intended? I need to first use some keys or other encoders before using enc 2 again.
Also, with the recent update it is difficult to clear the buffer by increasing the overdub to 1. In fact it feels like overdub is working in reverse ie 0 is max overdub and 1 is minimum. I couldn’t repeat this behavior exactly each time

Can anyone help me with a little refresher on this. It’s obviously no longer line 375 in the lua script and I’d like to make some changes again in my version

I think you might be looking for softcut.level_slew_time on line 399.

1 Like

I was having this problem where everything that I recorded in Mlr sounded like it was run through a low pass filter trimming the high end significantly, and thus reducing the volume too. Reinstalling the script via maiden did the trick to restore normal functionality for me.

Ok I’m having this same kind of problem again. It seems intermittent and across various input devices. I’ll try reinstalling again as @static suggests.
The problem is basically that softcut playback is very quiet and noisy compared to the volume and noise floor of the input sound. I’ve tried various combinations of input, monitor, softcut levels in the mixer section and can’t resolve. What baffles me is that the input signal sounds fine and that it seems to be just me with this problem across a few recent Norns and MLR updates and it wasn’t an issue previously - I feel like I must be doing something wrong

any more specific information would be good. hard to imagine reinstalling the lua sources would actually change anything.

at first glance it sounds like some softcut parameters are being set incorrectly or not being initialized. (not the parameters on the mix page, those are very limited, but the full set of params which includes filter settings and resampling rate.)

i would definitely nuke anything in dust/data/mlr for a start.

in this theory, here are some possible causes:

  • bug in MLR lua - e.g. unitialized softcut param
  • bug in softcut (reset routine or i dunno)
  • bug in crone OSC handling system
  • bug in main norns preset/params system, or corrupted preset data

if it is a simple failure to initialize / reset something, then there is probably a pattern related to whatever you were doing before running MLR.

i will try harder to reproduce these things but i have never seen them, don’t habitually use MLR, and would appreciate focused attention and debugging reports from anyone who does use MLR, is comfortable with the norns architecture, command line, REPL, &c.


alternate theory is that this is the same issue, somehow, as the corrupted noisy audio on monitor path that has been reported elsewhere. (jack connections somehow being corrupted between capture->mixer, or from softcut->mixer.)

this theory seems weak to me - i have only reproduced the other reported artifact once (maybe twice) in all the thousands of power cycles i’ve performed on multiple norns units, and descriptors like “lowpass” and “quieter” don’t really fit with that theory anyways - they strongly suggest incorrect parameter values being executed correctly.

1 Like

I would appreciated if somebody with coding chops could look at pre loaded samples in the slots being saved as a preset for recall/reload.

It’s the one thing that has been bugging me about mlr on Norns. It’s a little bit frustrating having to keep locating multiple samples in different folders and manually reloading each one everytime MLR is loaded. If you try doing that during a gig it can be show stopper.

1 Like