Pattern record not quantized at this point?
Would a MIDI clock IN sync be hard to add (I mean, if the MIDI study covers that area)?
Having a problem with Norns, grid and MLR in so far as once I live loop and get playing, at some point my Grid stops allowing me to select the sample position (Cut page, page 2). I can then no longer loop sections either. This happens only on certain tracsk and at certain times. However once it has happened I need to restart.
Intending to use the setup live but obviously this is not the ideal situation.
Any help appreciated.
Come to think of it, patterns of selectable, tempo-locked lengths were most useful in mlr’s previous lives.
@martinmestres midi clock sync in is probably a little tricky, and i’m not sure how the results would sound. mlr already is using beatclock (a library by @Dewb) and i’m not sure it’s correctly configured to use an incoming clock… basically there are extra metros in mlr for quantization and tempo. i can check this out.
@yelsnit can you reproduce the issue consistently? there have been other reports of instability, so i’m going to tune the engine (probably drop it back down to 4 voice) in the next update as i think we’re hitting some CPU limits. we have some ideas about how to isolate CPU between matron and supernova, but we’ll see how they work.
@altoaiello right now pattern record itself is not quantized, but if you turn on quantization the output from the pattern will be quantized. it’d make sense to add set-length pattern records as a feature, like the original.
Ok i see, this is is out of my league for now. I was just working on an upcoming performance the other day and felt that it would have been cool if i could have used my groovebox in conjunction with my norns (without using it as my master clock). I hope it will happen in the future though
use processor affinity its pretty easy to setup (though, it’d need to be check that the child threads of supernova are inheriting affinity)
however, I’ll say when Ive done this in the past, Ive rarely seen gains (over letting the OS do it).
I think the reason is the OS is good at spotting ‘hot threads’ and distributing over available cores,
advantages seem to happen if there are factors the OS does know about.
a) threads are being created/destroyed regularly.
(not sure this is happening in this case)
b) you want to pin because of shared resources e.g. where cores share L2 cache.
(this is not relevant on rPI, since there is only one processor, so all cores shared same L2)
Ill try recreate it and report back. As yet, just happened twice.
Will norns mlr work with a 64 monome?
I tried working with mine and it just doesn’t seem to do anything but light up a few buttons.
I don’t think so (or not every well). The PLAY buttons are mapped to the far right row of a 128, so the norns script is looking for a key event where x=16, which does not exist on the 64.
It might be possible to rewrite mlr to fit on a 64 grid, but that seems like a small undertaking.
I was curious about how MLR would work on a 64 grid, so I sketched it out…
…and I think it would work pretty well. I’ve sacrificed a pattern slot and speed options have gone from seven to three, but I think it would still work for the most part.
Thanks for the answers!
Would this be split into a top-half and bottom-half? Or is just the bottom row those other functions? I’m still pretty fuzzy on the various mlr functions.
OK - so based on your sketch, I monkeyed around and did this:
not sure it works quite right yet, but it might be a start.
Work in progress:
yeah, I was just replicating the MLR docs. more detail on the REC/SPEED and CUT pages below. I don’t have a solution for the CLIPS page because I have yet to really use it in depth.
thanks for taking a crack at the script!
just did a quick update to that gist - I think I have the leds doing mostly the right stuff. Functionality seems OK, but probably needs someone to test it out.
@tehn, consider this ‘anecdotal’ as its quite a different use-case,
but ive been doing some development of MLR on my Linux x86 box, this requires me to restart MLR (or rather my derivative, but i’ll refer to as mlr) pretty frequently, and Ive noticed that quite often after a short while (while im amending the code) crone will have exited with some errors.
(ive Crone running so I can see its stdout)
of course, different platform , but it looked like a pretty generic SC/supernova error.
I just wrote it off (so didn’t collect output) , as something to look into once I put it back onto ARM, but perhaps related.
but I mention it now, as if its the same issue, its not cpu related. (given the power of my desktop compared to a rPI )
if your interested I’ll grab the messages next time, I see it… but don’t want to create noise, if you think this is not a useful contribution!
@TheTechnobear thanks for the data points! indeed i spent hours yesterday debugging and arrived at the same conclusion that it’s not CPU related necessarily. please do grab any errors you see next time. discourse has a summary function that works like this:
click the cog above and use the “hide details” item
very new to norns and MLR - today I decided to give it a try with my piano, and I am so in love with this app and the idea that it will get even better fills me with such excitement about music-making. congrats and many thank yous to @tehn for creating such an immediately inspiring tool.
I will say that I have had a couple crashes, which unfortunately resulted in things completely freezing up and norns outputting a pretty unpleasant steady tone of some kind. if I stumble upon a specific thing that is triggering this I will report it here.
thank you for your kind words, and for your patience and bug reporting help as i work out the bugs.