This would be super useful!
And thanks for the upcoming live buffer saving feature.

2 Likes

@dan_derks This script makes me very happy, a thing of beauty. The simplest modular patch sent into CC = intrigue city.

A humble request: You mentioned it briefly in the previous thread, but I’d love to try to emulate Arc controls using midi (specifically a midi fighter twister AKA 4x4 encoders with light ring indicators). Would It be difficult to break out loop start, end, window position, and filter tilt controls for midi mapping? It’s more coarse grained than the arc but could still be fun. Also if those parameters send MIDI CC’s to the controller it would indicate and update position on the encoder’s light rings and prevent value jumps. Bonus for pattern recording!

3 Likes

Hi @dan_derks I have had a bit of time to play with this new version today and had an extended live exploration with a friend inputting modular and acoustic instruments (hope to share soon) and had the following thoughts…
The resolution of the sends for delays in params is 1.0. We discussed this and I was thinking more 0.1. Not sure if this is potentially a typo? But it would be nice to have varied amounts of delay per bank (as was your intial intent)
I’d really love a “return home” operation per bank for the filters. (Maybe there is one and I missed it) I find if I go a bit extreme then I can’t find my way back without working through each pad. It is also quite easy to go a little over the top, which is good but per bank undo filters op would be perfect for live work. Otherwise I’ve had to restart sessions.
Again, beautiful work

1 Like

hey y’all!

so stoked to hear what you’re making – I had the pleasure + honor to watch @zanderraymond perform a short set with cheat codes on friday at the opening of his solo exhibition, webmaking:

it was super humbling to watch an artist I love so much use the tool!

detailed "hmm"

i’ll peep what this looks like with the upcoming system-wide PARAMS overhaul. this is a bit secret complex because those parameters have a pad focus – 16 pads per bank means there are 48 loop start variables, 48 loop end variables, etc. of course, the PARAM entry can set to “give me the one in focus”, but this becomes a bit difficult to make useful for folks who might be using a faderbank which wouldn’t display changes across pads as you play – all of a sudden, your faders wouldn’t represent the actual current values. arc made sense to build this functionality out for, because it’s part of “the ecosystem” – but doing anything further specialized in the main distro might not be in scope.

tilt is also the most complex parameter in cheat codes – the lp/hp filter required a lot of fine-tuning and detailed handling of the curve for the best playability, plus slewing.

so, tl;dr: it’d be pretty straightforward to roll your own version that has the loop point manipulators mapped to midi fighter twister and I’d be happy to provide guidance on how to do that – it’s just outside the scope of the main distro.

the core of the arc interaction is three macro encoders that allow you to manipulate those parameters without having to jump around the UI menus.

so what about a [macros] page that mapped the same parameters that arc controls to the encoders on norns? so you can navigate to the dedicated menus to change the deeper params, but this page would give direct performative control over the four most likely manipulated performance parameters. this could be the most sustainable solution that isn’t additional-hardware dependent.

oh! dope, yeah, can easily adjust. going to also spend time on the [delay] page for the next-next update – it could use some love :slight_smile:

I have a few ideas toward addressing this – some that would hopefully let you avoid getting into tight spots and some that would help reset.

for now: you can force all the pads back to the same filter state by cranking global tilt (so, no ALT on [filters]) either left or right – after a few turns, all the pads should be at full -1 or 1 (depending on left or right) and then you can raise them all back to neutral.

apologies for the delay getting the update out this weekend – some stuff required a bit of extra care. will be releasing today :slight_smile:

7 Likes

im running cc on a grid 256 - getting some erroneous lights when pressing the unused side of the grid - not sure if worth looking at

hey hey! that makes sense – some commands look for presses in a single row / column, so if there’s something unexpected that extends outside of a standard 128, then weirdness will ensue.

no way to test this in-house, so it’d be awesome if you could collect any occurrences and log a github issue: https://github.com/dndrks/cheat_codes

:revolving_hearts:

1 Like

a bit confused about the snap to bars / linearize functions

does the K3 / 1 [+K3] mean that I need to press k3 after recording a pattern for it to snap to bar?

I’m try to record just a simple pulse that is actually in time and not micro drifting

snap to bars retains your original timing, but stretches the distance between the notes to snap to a single bar loop – so this will include all your drifts between notes, but the “1” of the pattern playback will be the “1” of the metronome.

linearize takes your original timing and nudges the timing to the closest multiple of the specified quant resolution (on the ALL page) at the specified bpm.

so if we have 4 pad presses recorded with these durations:

0.47999095916748 sec
0.49550008773804 sec
0.33601188659668 sec
0.4467670917511 sec
total: 1.7582700252533 sec

linearizing them at 1/4 quant resolution at 120 bpm will get:

0.5 = 1/4 note
0.5 = 1/4 note
0.5 = 1/4 note
0.5 = 1/4 note

if you want this nudging to happen automatically, then in [timing] > ALL, turn linear recording? to yes. this will do the linearization on the pattern as soon as it starts playing back.

so, if you want to lay down a steady quarter note pulse with the least amount of menu-diving friction:

  • [timing] > ALL
    • linear recording? > yes
    • quant resolution > 1/4

then record your Pattern!

if you want super-extra assurance that things are gonna get clamped down steady, then turn quantize pads? to yes and you’ll only be able to play notes at the specified resolution and that the Pattern recording will be locked to that resolution.


yes. i’ll be adding a “snap recording?” function similar to linear recording? soon :slight_smile:


something fun

if you open up maiden with these various settings + actions, timing adjustments will print to the console.

here, I’m playing 5 sloppy notes into my Pattern recorder (pads are NOT quantized). I have linear recording? set to yes and a quant resolution of 1/4. you can hear me enter the notes and then the notes get nudged to 5 true quarter notes at my specified bpm (120):

[my original notes totaled out to 2.7664229869843 seconds and then were linearized to 2.5 seconds, which is the length of 5 quarter notes (each = 0.5s) at 120bpm!]

this is technically 1.25 bars, though. so if I then apply a “snap to bars” set to 1 bar (by hitting K3 with that function selected), my 2.5 seconds is scaled down to 2 seconds – so my 0.5s events are also scaled down to 0.4s events, so I have 5 equally spaced events in a 2 second Pattern:

so now, the duration of the Pattern matches 1 bar at 120bpm – important to note that the events aren’t on quarter notes anymore, though, to make up for this timing shift. this is by design – so maybe a truncate option, which will just cut off anything past x bars, would be a useful addition?


I’m going to continue refining these particular tools, which borrow from different quantization methods but sometimes are totally weird. this feels in the spirit of the script, though – there’s a “fuzzy clock”-ness to working with samples + loops that I really wanted to honor. linearizing and snapping are meant to supplement the flow, not dictate it.

hopefully the words above help reduce the abstractness! super glad you asked :slight_smile:

8 Likes

Oh great workaround. In fact that is probably sufficient and could be used creatively too!

1 Like

I used Cheat Codes in a live performance last night and it went well! Thanks @dan_derks

2 Likes

op-1 > cheat codes > 3 live buffers > clouds > oto bim > dan derks > gratitude :paperclips:

9 Likes

Beautiful. Interested if you are sharing clock with cheat codes and OP1? I tried briefly but had the pesky OP1 ground noise issue and moved on to other things.

thnx, ahh no just using the internal clock within cheat codes. i tend to avoid having the usb plugged into my op-1 for that exact reason:/

i wonder if a BeatStep Pro splitter cable would help with that.

i run into the ground noise if i plug both norns into a powerstrip with USB power connections.

i have to plug one into it’s own USB power brick or one of them will whine with ground noise.

just got a grid and norns today. i had to come say that this script brought me back to monome after many years. it’s a freaking incredible concept. simple and insanely deep. so much about this script is blowing my mind. thank you

16 Likes

:blush:

what an inspiration
share when you make some new beats w/ cheats

3 Likes

thanks man! will do. really dig your stuff!

3 Likes

woahhhhh @edison, welcome back!!! BIG BIG feels, thank you so much for sharing this note :revolving_hearts:

2 Likes
what i've been up to

next update has basically been ready to release for a week+, excepting this one external clocking thing that just kept nagging at me.

the way that snap to bars works (as detailed in a post a few scrolls up) feels really musical when using the internal clock. it gently nudges your Pattern’s actions + inaction and feels subtle. 50% of the time, though, this wasn’t translating the way I’d hoped on the external clocking side of things – so, this week I broke external clocking into its own function and finally got things tuned up!

now when clocking externally, snap to bars turns into trim to bars – it’s a hybrid of the snapping function but with a much stronger pull to the tight syncing that MIDI + crow situations necessitate. starting from the end of the Pattern, pauses are uniformly removed to prioritize the pad actions. if the counter gets to the start of the Pattern and still needs to remove events to fit in an [x] bar loop, it starts removing the pad actions from the end, working back to the beginning.

this fits way more holistically with DAW-oriented workflows and after some final testing tomorrow (basically to confirm that any Patterns in your collections made before the update won’t break), it’ll be rolled into the main distro – along the fixes + improvements discussed over the last two weeks.

apologies for the delay, but this was driving me nuts :slight_smile:

the resulting Ableton Live MIDI-synced cheats:

22 Likes

11 Likes