As requested in the Norns: dust thread, this thread is for users of the Norns mlr script to discuss … well …
- Performance tips
- Problems
- New features
- Delicious beverages (OK, maybe not this)
Go forth and be excellent.
had this same issue (error: AUDIO ENGINE). Was able to fix by deleting CroneGenEngine.sc as described above, thank you @okyeron ! Just noting this as i have done no development on my own as @jflee seems to have done.
Also i was stoked to see the midi_sync parameter for MLR! Though i am as of yet unable to get it (or the tempo stuff for that matter) to do anything, am i missing something? I have it plugged into my mallekko SYNC module. Should I select learn and send MIDI clock to it?
Lastly MLR is also crashing quite a bit for me. Audio plays fine but the grid stops working. Loading a new instance of MLR does not fix the issue, i have to sleep and restart to get it working again.
mostly though, thanks to everyone involved for working on all this!
Is this a new bug introduced with yesterday’s update?
Curious about this also… Never had this crash, still using the previous firmware.
mlr has clock out only, not in, presently. can you describe the crash? does it only happen with MIDI plugged in? can you simply replug the grid?
Quick question regarding the new ‘hold key 1’ menu. Save and load mean we can save snapshots with recorded samples? Or this for saving CC assignments? Didn’t get a chance to try it out yet.
so the usb connections are: grid, wifi and an A to B usb cable plugged into the Malekko SYNC module.
i start mlr and the grid lights up noirmally. go to parameters and turn on midi_sync, then sometimes it works for a few minutes other times the lights go out with a what looks like a flash of the upper left hand corner of the grid. Then the grid no longer comes on. If i was able to record audio, it continues playing. Re-pluggiing the grid does not help nor does reloading MLR. the only thing that does it is a sleep/start cycle.
As far as the midi out goes, that was what i was expecting, that when on it would spit out midi clock over usb, in my case going to the malekko module which i would use to sync to the modular.
@garethlyons save/load is for the param values. clip/etc save/load not implemented yet but coming.
@David_Rothbaum let me test this more and get back to you. i saw some weird interaction between grid and midi yesterday. can you confirm that midi sync out works on playfair and/or awake?
so, midi works great with both playfair and awake. i also got the clock out to work with mlr! but there were a few things worth noting.
- i had to plug in the usb/midi connection when norns was off. plugging it in while on seems to cause the crash.
- i had to toggle the internal/external parameter a few times to get it going.
- there is noticeable drift or stutter in the clock signal, slows and speeds back up.
also worth mentioning, while i was testing this i ended up making a piece of music. as so often happens with this stuff… midi sync makes such a huge difference to me, thank you.
4 Likes
also it seems that in order to get either awake or mlr to output clock i have to first run playfair and toggle the internal/external parameter.
2 Likes
this is all quite helpful @tehn @David_Rothbaum, so thanks for talking about it. thanks tehn for midi too. or whoever wrote it in. it’s essentially the reason i bought norns, so i’ve been waiting for this day. i shall install this new update soooooon…
4 Likes
just catching up - does the midi functionality mean that a grid isn’t necessary for norns mlr now?
grid still required and will always be required: mlr is a grid thing. that said, i’d love to make some mlr-ish non-grid things!
midi out functionality is tentative, it seems slightly buggy and i’ll work on it.
7 Likes
is this due to the new update? anyone else having issues with the update making mlr crash? i’ve been holding off on the update as i’m afraid of this happening
was this fix ever implemented in a repo somewhere?
my project has three samples that are fairly short (for me): 10 seconds, 37 sec, 54 sec. there’s no indicator that they’ve all finished loading, or how much RAM they take up (at 48khz/32bit stereo), but i definitely noticed the buffer overrun. when only one track is playing, the audio will unpredictably jump to different parts of the other two samples.
is there an easy way to keep track of RAM usage on the sample load screen, or should i follow a temporary workaround for sample size? i.e. “for now, keep all samples under X seconds long.”
for comparison, the er301 displays total memory used on its sample load/clear screen, and won’t proceed if asked to load a sample that exceeds available RAM.
i poked through the lua code, and i’m guessing that somewhere around here, i might try adding a function to display available RAM: free -h | awk '/Mem:/ {print $4}' via something like m.sys.ram, though the displayed number might only be useful in the context of how much of that can actually be used by mlr’s buffer(s). it doesn’t seem to fit in the toplevel system screen, as the existing status info lines up neatly with the left-side options.
maybe it would still be worth adding this free RAM info to an mlr status screen somewhere; perhaps the clip select page? otherwise, there’s no indication of why mlr starts behaving erratically–if it’s norns itself or mlr.
no, tracking RAM usage like that is not going to be useful. the audio buffer is preallocated. you are not running out of RAM. this seems like logic problems in the mlr script and maybe in the SoftCut engine. (but i suspect the script.)
more feedback (visual or otherwise) between lua and SC would be good, regarding the contents of buffers. there are some parts in place for visualizing loaded waveforms. it needs more work, not just in implementation but also scripting / API design. https://github.com/monome/norns/issues/74
this update was about control, scripting, and usability in lua. the next update will address more audio issues and softcut/mlr in particular.
for the record, each voice should currently have a dedicated region in the buffer of 64 seconds. (this is totally arbitrary, it could be much longer.) if voices are never supposed share the same buffer conbtents, then the endpoints for each voice should be clamped to [(i-1) * 64, i * 64], where i is the 1-based voice index. glancing through mlr.lua i don’t see that happening anywhere.
but i also don’t see why voices shoudn’t be able to share material necessarily.
1 Like
so it sounds like actually the grid driver is falling apart somehow (or matron / lua is crashing.)
opened GH ticket, please post any more information there (steps to reproduce, &c) - i for one have not noticed any instability with plugging the grid. (but also haven’t used mlr much)
thanks; this clarifies some things.
i did some quick-and-dirty additions to mlr.lua’s CLIP screen, and discovered that my samples only occupied about 10MB, and also noticed the “free mem” number changing almost every screen update, as the OS does its usual memory cleanup routines. you’re right; displaying available memory isn’t very helpful.
actually displaying audio waveforms and playhead positions on the CUT screen would be awesome, though probably pretty resource-intensive to track and update. i’ve noticed that even the various desktop spinoffs of mlr will occasionally lag behind visually, though the audio and grid remain in sync.
regarding voices sharing a buffer, would this be more resource-efficient? i.e. if the same sample is used for more than one track, but with different play speeds & direction, etc., would only one copy of it actually need to be in the buffer?
Conserving RAM really shouldn’t be a concern, there is plenty of it.
Oh man, first session with Norns and MLR was brilliant. Really found myself in an interesting place, though still scratching my head in terms of what was happening. Is there a rundown of how to use (other than the brief manual). I’m new to MLR fullstop, so maybe there’s an overview of another version that could help with getting my head around this?
3 Likes