Thanks! Glad you’re having fun with it. It’s always a pleasure to have my code out in the world and making music.
Great ideas there. I love the idea of the clock divider per instance, I’ll put that on top of my todo list. I’ll have a think about independent probability controls; I tried to make it so that switching between samples doesn’t change the state of the grid controls so that it all feels deterministic and under your control. I should be able to change the brightness striping of the grid with a param, I’ll put that on the todo list as well. And thanks for the bug report about the step logic, that sounds like something I’ve seen it do.
I’m really enjoying this. Thank you.
@mattbiddulph - Dude, killer app! Just started digging into this one today. Looking forward to exploring more.
Seems like there’s a little lag time when controlling these parameters with arc:
One feature request! Would it be possible to provide on option to reset the progress back to the first beat when seeing midi clock in? Would be really nice to be able to have that function when working in conjunction with a DAW and playing/stopping.
Hey there! Glad you’re enjoying exploring the app.
My guess is that the latency is coming from the fact that parameters are read and all outputs updated on the clock beat. This is intentional, to ensure that all changes are quantized. Does that sound plausible from what you’re hearing?
Resetting the beat when MIDI clock begins is a great idea. In my own music I only use Ableton Link and Crow clocks, so I’m less familiar with how MIDI manifests in the Norns clock. I’ll see what I can do.
In theory you should reset on Start msg. Not reset on Continue msg.
Midi clock is all the time regardless of transport control.
There is some fog for me on Norns and start stop functionality on certain apps. this is interesting. following now. also dig the app @mattbiddulph !!
@mattbiddulph
Took a look back at how these parameters were lagging and I don’t think it reflects what you’re saying about the parameter updating every clock beat. Def lags much longer than every beat when using arc. It may be a sensitivity issue as well? Seems to be all or nothing for parameters like beat start/end. Hard to tell if its sensitivity due to the lag time when turning the knob. It may just be catching up with itself.
Let me know if I can provide any further troubleshooting. Happy to help!
i’m not super familiar with midi mapping norns. would it be possible to use two launchpads to control the two voices like it was a grid?
I believe so, yes. Each parameter of each voice is broken out into its own Norns param, so you should be able to map each one separately to a CC on one of the launchpads. It was certainly working well with a single Launchpad before I added Grid support, as you can see from the very first video in this topic.
awesome, thanks! will keep an eye out for a cheap launchpad so i can use both voices.
On my Launchpad (a Mini Mk3) it’s possible to define multiple pages of grids that send different MIDI CCs, and switch between them using buttons at the top right of the grid. This might give you some of what you’re looking for.
Multiple pages, like you’re describing, would be a neat feature for monome 64 users in future versions
@mattbiddulph i absolutely love this script. i love what it does to drums and i have been experimenting with other loops as well.
i have a question about creating loops - how do i add my own bpm?
i can see in some of the demos you provided there are bpms:
but when i add my own .wav files in a folder it doesn’t add the bpm. does it sync to the current global clock in the case its not provided?
.wav
bpm
Beets always assumes that every audio file in a folder is one bar long when it loads it. Even if you have a number of audio files with different original BPMs, they’ll be sped up or slowed down to match the global BPM on the Norns clock.
That BPM setting you found in the JSON file is just a pre-calculated reference for the softcut engine so that it knows the original BPM of the audio file (and can therefore speed or slow it to match the required BPM at runtime) without having to recalculate it every time it loads.
Edit at line 163:
params:add({ type = “number”, id = “the_bpm”, name = “THE BPM”, min = 0, max = 300, default = 120}) params:set_action(“the_bpm”, function(x) params:set(“clock_tempo”, x) end) arcify:register(“the_bpm”, .1)
Throwing this code in lets us map tempo with arcify by making bpm a param which is really cool and satisfying. However, whenever I land on my new destination tempo the loop will jump back to 1, making the smooth tempo change not so smooth. This happens when adjusting the tempo with the norns encoder as well. Its like it is finding the 1 now that its in the new tempo instead of just letting the loop play.
Finally tried this and it’s pretty amazing been using a Korg Nanokontrol for midi and still need to figure out the best way to assign stuff, but threw in some old folders of breakboeats and got instant breakcore so seems promising
edit: also I’d second the comments above that timestretching (akai style and/or modern) would be incredible. As would jungle-style pitch shifting stuff
this script is awesome. Reverb released a huge zip of drum machine samples earlier this year and this script just eats them up.
Thank you! This is the perfect mission statement for Beets, exactly what I was trying to build:
Is there a specific limit to the number of wavs you can have in a folder? While looking for loops to put on there I remembered I was on this “digital locked grooves” compilation so I converted all 237 tracks to wavs and threw them on there but it only seems to want to play the first 50 - after that it displays the number up to 237 but they are silent
adding another voice to the recent chorus singing praises of beets. super fun and immediate.
