live sample-cutting platform
- grid (2012-later 8x16)
- uses new native softcut system
- smooth rate modulation for rec/play, no aliasing artifacts
- per-voice panning
live sample-cutting platform
Maybe a silly question, but 2.0 already has this right? Or do I need to replace MLR with this one? Thanks @tehn and great job on a smooth upgrade!
correct, 2.0.0 install includes the newest version.
this thread will track future versions and support
i noticed after updating to 190405, mlr has no parameter page.
i hope i’m just missing something.
i’m dumb. turn encoder 1.
this might be a dumb question too, but what are the purpose of the 4 leds to the right of the patterns? i don’t see anything in the prelim docs that explains it. they almost seem like pseudo pattern triggers.
Hasn’t been added to docs yet
I’m having trouble loading samples on the clip page.
I can populate the first six slots just fine but anything I load in slots 7-16 will not playback.
Has anyone else had this issue? thanks!
@marcus_fischer augh, i should test this. there’s likely a very obvious bug— i forgot to account for time changes with the transition to new softcut. thanks for the report.
fantastic work on MLR though.
I love it!
Im not sure if this is how MLR is behaving for everyone on 2.0 but on track one any button I press on grid will light the button before it. The first button will light the last, 2nd will light the first and so on.
–I just reinstalled it, reset Norns and its working correctly now
I jammed on MLR quite a bit in the last 24hrs, and didn’t crash it once.
…still trying to figure out if there is a way to record long >1min per track…thanks!
the LED tracking is off a little, I will be working on it. so it’s not just you, no need to reinstall
@swhic not yet. I need to assess buffer usage.
I’ve been adjusting the script for non varibright 64 users today, and I’ve been running into the same issue, the playhead LED is one “button” off when pressed. Is it something about how the pos_grid is being called in the g.led parts in this snippet(this is modded for 64, so 16=8 etc.)? Messed around with it a bit without fixing it.
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,4) end end if track[i].play == 1 then g:led((track[i].pos_grid+1)%8+1, i+1, 15) end end g:refresh(); end
If anyone else want to have a crack at this script I’ve attached it here. Haven’t looked into the recall stuff yet. Absolutely magical script, sat around for some hours just droning with my guitar straight into mlr, pure joy.
mlr64.lua (20.7 KB)
Edit: Fixed it(I think) in my script. Removed the +1 in, but it’s still one off in reverse.
g:led((track[i].pos_grid+1)%8+1, i+1, 15)
@tehn et al, lmk if it is confirmed that the quantized position poll from softcut looks as expected / doesn’t…
seems to be working pretty well in
cranes — i have two polls running for separate playheads, which dynamically change rate and direction.
only odd thing is i have polls quantized to 1/10 second but certain steps get skipped (regardless of rate): 0.7, 1.4 and 1.9 in a recent two second loop test
@Dan_Derks can you plz open GH issue with fuller description of bug / repro steps? i have some theories but…
for sure, it might also just be the printing to screen which skips steps, though the redraw() function is called as part of the poll action. idk but i will def log when i’m back at my machine. thank you!
there’s a good chance my math is wrong in lua. i’m certainly not about to blame crone!
One more thing I just want to ask to see if this is how everything is working for everyone else or if its just how its supposed to work but it seems that now in 2.0 running MLR that the gain staging is a bit different. If I set all levels to 0db on the audio page (input, output, monitor etc.) and then record a track into MLR the audio seems to be a bit higher on the other end once it starts looping. In 1.0 I never encountered this. Is it that its monitoring audio slightly lower?