Mlr (norns)

[zebra]

there are 2 buffers. each is 16777216 frames or ~350 seconds. this length is basically arbitrary but it is useful that it is a power of 2 (2^24.)

the buffers could be longer. the limitation is RAM. we want to leave a healthy amount of RAM for other things. currently softcut uses ~150MB or something which is probably conservative.

there could be more small buffers instead of 2 large ones. but this limits the length of time that can be addressed by a single voice. (unnecessarily, IMO)

i made 2 assignable buffers mostly as a compromise for convenience, so that you can have 2 voices sharing the same time-base without crossing heads. (the main application being stereo playback - it’s too weird to have to manage timing offsets for L/R channels.) but it’s also good to be able to have voices sharing the same buffer and time-base for Weird Stuff.

in other words, we require a control-side abstraction, if you want to share timebase amongst more voices that are actually pointed at different buffer regions; this decision priorities flexibility.

that said, i’d be ok with bumping it up to 4 buffers if that request has consensus (and is deemed more valuable than doubling the buffer length.)

---

finally i’ll point out that there are a lot of applications for which softcut is overkill. for example, any kind of playback without sampling, especially streaming from disk, can be accomplished very easily and more efficiently in supercollider (today), or other jack clients (tomorrow), without limitations from RAM. of course MLR doesn’t use SC now, but one could fork it and add more things that way.

[noiserock]

managed to fix my 64grid playback head forward/reverse issue with some dirty dirty code. If anyone has any feedback on a way to do this more lean I am happy to get some feedback(I need to fix this in the looping mode as well).

v.gridredraw[vCUT] = function()
  g:all(0)
  gridredraw_nav()
  for i=1,TRACKS do
if track[i].loop == 1 then
  for x=track[i].loop_start,track[i].loop_end do
    g:led(x,i+1,5)
  end
end
if track[i].play and track[i].rev == 1 then
  g:led((track[i].pos_grid+1)%8+1, i+1, 15) 
  print((track[i].pos_grid+1)%8+1) 
elseif track[i].play == 1 then
    g:led((track[i].pos_grid+1)%9, i+1, 15)
    print((track[i].pos_grid+1)%9)
end
  end
  g:refresh();
end

A bit unsure about the use of the modulo since it confines the values under the set number, and I would want values between 1-8.

Also, small update/realization on my end:
If you resize an empty clip, then clear it in the CLIP menu, you can adjust your buffer length between the set amount of resizes. Very handy. I think the standard size is 2(correct me if Im wrong). So you can up that to 16.

[sunbeamer]

Is anyone noticing some latency issues when starting/stopping playback on a track? Apologies if it’s always been this way, I’m a bit new to MLR.

When I hit the play start/stop button for a track, there’s sometimes about a half or quarter second delay between the button press and the button actually changing state for playback to stop or resume. It’s not 100% consistent on every press, but it happens frequently enough that it’s a bit annoying.

[Prnts]

That doesn’t seem normal. There isn’t dead space possibly at the beginning of the buffer is there? Are you preloading tracks or recording into the buffers?

[sunbeamer]

I’ve been live recording into the buffers, in this case. Is there a way I can tell if there’s space at the beginning of the buffer?

[zebra]

does this seem to be better or worse with wifi on/off, by chance?

(“delay between button press and state change” sounds like an event loop / lua-side thing and not like a buffer / DSP-side thing.)

[sunbeamer]

I’ve had wifi on, but switching it off doesn’t seem to make much of a difference.

After some more poking, this actually doesn’t look like an issue isolated to start/stop. I’ve just got general interface lag on almost all functions, except for changing the track focus, and starting/stopping recording.

Update: After power cycling Norns and re-recording some new stuff, the issue isn’t happening anymore. Is there a way that I can grab a sample of the process over serial if this happens again to help with possible debugging?

[tehn]

presently clip length max is set to 45 seconds. there are 7 clips available.

i can easily double this by using both buffers. the clips are spread out across the buffer at 45 second intervals— this is a constant var in the script and easy to tune.

[noiserock]

I don’t think this deserves its own thread in the lib section.

The mlr64 2.0.1 for non varibright grids(should be easy to mod for all your varibright needs).

Column 3 on Rec/Speed view only lights up if it is “time mapped”, but still functions as a focus button as well(in addition to column 2).

mlr64.lua (22.1 KB)

[Prnts]

Is midi sync currently working in mlr? I had previously in the 1.0 days synced tempo with my Octatrack with a usb to midi cable. I can’t seem to get it to sync now though.

[SPIKE]

oooo-weee!

ok MLR is working great!

question…does MLR send out a ton of MIDI info?

I have norns connected to MIDI through an old iConn USB to MIDI box thing.

the setup is with the Deluge sending out a master MIDI clock into a passive MIDI splitter and then to the Little Deformer 3 and then through the iConn box to norns.

my Little Deformer 3 would get a horde of MIDI data and then crash.

more testing tonight.

thanks for any help or info!

[audionerd]

currently mlr sends clock messages but does not send start/stop messages, which some devices expect.

actually, there’s a typo on that line which prevents clock from being sent. should be midi_device:send not midi_device.send

trigger params for midi clock start/stop might be a nice addition to mlr?

[Prnts]

Ah nice ok I don’t need it to send transport as much as I’d like to just sync the clocks up. Gonna try changing that line

**made the change and its syncing up now thanks

[noiserock]

made a drawing for 128 grids as well. Not 100% happy with how this looks if anyone wants to do some adjustments I’ve added the illustrator file here as well.

mlr.ai (1.6 MB)

[jonsimon]

I would LOVE that. 20chars

[kburwash]

What am I doing wrong? If I load a clip and play it back it slowly dies. It starts out at a good volume and slowly fades until it’s gone. I don’t have record on on that track. It also happened to a clip I recorded in, but not the other one I recorded in.

It’s as if I’m overdubbing silence, only… I’m not.

[noiserock]

Is the overdub param in the rec/speed menu anything above 0.0? And is the rec button active(column 1)?

[kburwash]

Nope. That’s why I’m confused.

[noiserock]

Try repulling the script from git maybe?

[louis]

I’ve not yet had a good look through the lua code for mlr but I did notice:

local FADE = 0.01

I’d also noticed my loops very slowly fading out but thought I was probably just imagining it. Might be worth changing the above to 0.00 and see if that makes a difference. It may well be unrelated!