[cheat codes]: v1.2.2 (April 10, 2020)

[kasselvania]

Hell yah! Gonna watch this when I have a break! Which, given my life will be next week. lol

Thanks for all the hard work Dan. This is huge.

Yo, this timing tutorial is freaking ACE. Holy crap. This plus that Polyend Track and my OP-1 and I’ll just never use anything else ever again. Throw that rack in the garbage, I’m done!

[gnome666]

+1 for Arc walkthrough

[chorus7]

Thanks for this Dan! Exactly what I needed…

[Deru]

Amazing video (and features) Dan. Thanks!

[hypnosapien]

Great video. Super helpful. I think there’s still something really basic I’m missing, so please excuse my extremely naive question. How do I load a loop such that it is equally sliced between the 16 pads? Or are the 16 pad divisions always equal divisions of the 8 second total buffer time? Sorry, I need a little hand holding now and then. After extensive use of hand sanitizer, of course…

[dan_derks]

hey hey, happy to help! thanks for sanitizing

@hypnosapien

How do I load a loop such that it is equally sliced between the 16 pads? Or are the 16 pad divisions always equal divisions of the 8 second total buffer time?

a fresh session will always load with the pads incrementing half-second chunks, which is 4 full bars of quarter notes at 120bpm. the [loops] page (+ arc) gives total control over start/end-point adjustments. I like setting the encoder resolution to 0.01 in PARAMS, to get real fine. then, it feels really canonical to just mpc-style tap+adjust your pads to the slice sizes you need.

the roadmap for clip loading has goals for mapping arbitrary lengths of imported audio across the 16 pads. i really feel the hurt when I load a 2 second sample into a fresh session and only have 4 pads of runway unless i make adjustments, lol. so, i’m with you – this’ll take some architectural doing, though.

does that help?

[21echoes]

does that division scheme change as we change the bpm in the timing settings? e.g. if we increase tempo to 180, then each pad would increment 0.333-second chunks to get four full bars of quarter notes?

[kasselvania]

Presumably yes. It breaks down in which it is 16 equal divisions across the 8 second buffer. So, if the BPM speeds up, the divisions, while the same amount of time, are no longer the same quarter note cut. Jeez, that gets to be a mouthful.

[hypnosapien]

Yes, this makes total sense. It’s more MPC-style sample cutting than MLR-style sample cutting. Thank you!

[dan_derks]

@21echoes

does that division scheme change as we change the bpm in the timing settings?

the length of the 16th note division provided by Zilchmo row 4 [ ] [ ] [x] [ ] totally changes.

but the first-load default config of 16 0.5 second slices is solely just to get 16 even slices of the 8 second buffer. in many ways, it was one of the earliest non-UI design decisions – I wanted folks to be able to see a clear relationship between the 8 second buffer and the 16 pads.

(an aside: cheat codes was first conceptualized to live sample only – I guess I originally just wanted a super playable freeze pedal, lol)

while this default isn’t bpm cognizant, I just figured knowing what the default state was equal to in bpm would help with loop pre-making

@kasselvania

if the BPM speeds up, the divisions, while the same amount of time, are no longer the same quarter note cut.

right – the pad’s durations don’t change if the bpm changes. in fact, the bpm at first load is 110, so those pads really don’t care

generally, I didn’t want to impose bpm-centricity as the primary mode – I like that cheat codes supports a weird, un-clocked, wandering style of exploration.

but I also wanted to stretch its capabilities in clocked contexts…and that really came together in this last update. so…

bpm adjustments influence:

• distro, quant and quant+trim Pattern rec modes (how are notes distributed across the Pattern, since they aren’t loose)
• the rate that a quant or quant+trim Pattern plays back at (so like, if you record a q or q+t Pattern at 90 bpm and then increase the bpm when the Pattern plays back, the Pattern will speed up to match! the video was long enough so i didn’t mention this there, but it’s in the manual)
• the slice length that Zilchmo 4th row [ ] [ ] [x] [ ] gives (1/16th of the current bpm)
• the delay time factor
• pace of external clock signal

so, generally, when I change the bpm during a cheat codes session that has quant'd or quant+trim'd Patterns playing, I also do a quick ALT + Zilchmo row 4 [ ] [ ] [x] [ ] so that my loop windows adjust (then maybe I use the new focus hold function and Zilchmo row 4 [ ] [x] [ ] [x] to 2x a few of the loops). having this gesture be an easy-to-execute choice made sense for the most expressivity.

hope this helps clarify? lmk if you have any other q’s

[rdfm]

I saw someone on Instagram describe cheat codes as something along the lines of an elektron style p-lockable loop mangler. Anyways I was deeep in a session last night and that popped in my head, then that led me to the thought of being able to set delay sends per pad. It would get weird and groovy and so so cool. But it’s already so so so cool and we really don’t deserve all the hard work you’ve put in to this wild script. But… maybe…

Thank you Dan, you’re the best. Maybe I’ll share some sounds soon. They’re piling up

[dan_derks]

@rdfm

set delay sends per pad

ah! the infrastructure for this is already in place! there are actually separate variables for left_delay_level and right_delay_level per pad. I just put the breakout on the backburner. [delay] in general needs a little love.

when I can, these will get exposed, thank you for reminding me (and for your very kind words – share those sounds, please!!)

[CarlosUnch]

Is there a way to connect TouchOSC in this as a Grid, Arc or just convert it to MIDI over wifi?
MIDI mapping doesn’t seem to work over TouchOSC.

[dan_derks]

this might be of interest (if you haven’t seen it yet): TouchOSC templates for Grid and Arc

fwiw, i’m currently rewriting MIDI interactions for cheat codes – not as a replacement for grid or arc, but as a separate performance modality. trying to identify + celebrate the idiosyncrasies of each control paradigm feels like a more holistic approach and i’m excited by how using only a faderbank and the on-screen controls completely changes the way I play.

there will be an accompanying “gridless” video once it’s all wrapped

edit: @CarlosUnch, this convo led to a series of TouchOSC template experiments. I was able to replicate the essential grid gestures (pad selection, pad loop on/off, rate/direction, levels) on an iPad. I’ll be cleaning it up this weekend to include loop points + loop windowing, but was really encouraged by the experience (tbh, I was dreading midi faders / no-feedback-knobs when it came to a lot of these parameters). it won’t replace formal grid interactions + there won’t be a zilchmo panel, but it should get folks a lot further than the current gridless workflow

[ludvista29]

I could see the trusty nanoKontrol2 being pretty nifty in this situation as well! excited to dive in to 1.2… I have a lot to catch up on.

[swhic]

Hi, there is something I don’t get with the alt+f key + screen functionality. Usually it takes me to the filters screen. I’d like to have access to pad rate screen. What do I miss? Thanks

[dan_derks]

@swhic

I’d like to have access to pad rate screen

this screen?

it’s (only) accessible with a norns K1 hold when you’re in [loops]
(fwiw, it’s a screen primarily designed for gridless play, so it felt right to have it be norns-hardware accessible screen rather than thru grid. though, lots of fun stuff to be done here while also using grid!)

does that help? just lmk

[CarlosUnch]

That’s amazing news for me! It’s definitely what I’m looking after with CC. Currently I’m using the faders of my Akai mini since I’m missing parts on my faderbank to finish the build; set to levels, pan and rate playback of each loop. I’m not using pattern recording, timing or anything to do with pads (just set to a1 b1 c1, each one nicely tuned though), yet it’s an incredibly rewarding instrument.

In my experience, since to me CC is more based on feeding different sounds to it and looping them, I’d love to have MIDI control over:

1. Record ON and OFF for each Live buffer separately. This way I could toggle record on more than one buffer at the same time. Just a fader (per buffer) going over 50% would be fine to toggle record ON.

2. Map 6 faders to the starting and end point of each loop. I play a lot with this to create polyrhythms and would be amazing to have direct control of the three loops at the same time (I’m seeing myself using faderbank vertically alla Grid). Visual feedback from the screen would be enough to know if you are reaching the end point with the starting point.

I also thought that could be cool to have a crossfader to swipe across the three loops, like a master level blender.

Pad selection with a regular MIDI grid would be nice to have some instant preset pitch and pan shifting (with the faders you may end up tuning a very high pitch sound, or make it disappear if you are not careful), but we are entering in the wide realm of what CC is meant for. It is control I don’t currently need.

I’m really exited about what you are cooking here Dan. I hope I can give you some useful feedback.

[CarlosUnch]

Ah, would be also great to have a bunch of LFOs assignable to everywhere and having “depth” control MIDI mappable as attenuation. That would be THE thing.

Granular style for example, randomise the position of the playheads.

Maybe that’s easy to add just copying the code from scripts that have assignable LFOs. I have no clue

Edit: yes, I see there’s a randomise position of playhead command by using Grid, I have no idea if you can automate that though.

[okyeron]

@dan_derks

this convo led to a series of TouchOSC template experiments

Wanna compare notes on this? I should revisit those grid/arc templates.