@dan_derks I’m finding that there are some steps getting dropped occasionally with the set up. For example, if I have three clips running like this, after maybe 32 or 64 bars or so, at least one of the loops will get out of sync and be a step behind the others. I can’t seem to do anything specifically that causes it to happen, though. Not a huge deal, but I thought perhaps it might be related to the arp/pattern timing issue.
thankfully, unless actively you’re seeing the distro time on the [timing] screen change to unexpected values, this isn’t related. the arp/pattern issue requires a super-specific set of actions to invoke – you need to engage a pattern recorder, start pressing buttons, engage arps, keep pressing buttons. one of the goals for the next month is to allow arps + patterns on the same bank to play at the same time and feed each other, but for now it’s best to treat them as separate ways of handling time.
as you shared, this issue is near-impossible to reproduce reliably. patterns are a hybrid of the older metro system (free) and the new clock system (distro) – expressive hand-played patterns seem to flow reliably in both modes, but this is probably why a rigid pattern like snake would occasionally get tripped up. the individual events in a distro pattern (which is what snake patterns default to) aren’t fundamentally quantized to anything – they are driven by the metro system and the only truly clock-aware event is a reset which re-starts the pattern playback after x bars. so my best guess is that these two separate timing methods are just getting out of sync with each other and that’s where the hiccup occurs.
tl;dr: i’d suggest pulling out the WIFI nub and seeing if that helps.
i was also doing some thinking about what you had proposed and i think that the snake functions actually would be better as arp modes. arps are fundamentally quantized events – they don’t record organic time, they just queue their events and then this queue is systematically walked through with each global clock beat. since snake modes are all fundamentally queued events, i’m realizing it was actually a weird decision for me to have married these to patterns – they ought to have always been arp modes
quick check – does anybody have a Midi Fighter 3D or Korg Nanokey Studio + would be willing to help me and @leolodreamland with a MIDI triggering issue? just DM <3
thank you @Philternaut for the expert and detailed assist !!!
patches 201128 (Nov 28 2020) + 201126: 64 grid compatibility + bug fixes
nb. you should see
patch: 201128 on the script info page once you SELECT the script. if you don’t, please remove the script and download fresh from maiden – no saved data will be lost.
- 64 grid support (see PARAMS > GRID): main performance and delay pages! (attn: @Clashley1 + @sademik)
- 1-shot Live rec latency offset: if you’re recording into cheat codes from another computer’s DAW, you’ll likely see some latency in 1-shot mode. this is expected, so the
latency offsetparameter allows you to compensate for this in 10ms increments, up to 1 second. ymmv, but an easy way to determine a good value to is record in 1-shot mode without this compensation and see how many 0.01s increments it takes to align an auto-chopped pad to the start of the recorded sample. match the latency compensation to this number of increments and you’ll be set for the rest of the session! (attn: @shellfritsch, from a convo we had 6 months ago)
- brought back
manual controlparameters for folks wishing to map a static slider to current pad’s start/end points (attn: @encephalitislethargi)
- laid the foundation for a
#submenu to the
[loops]menu, not accessible in this update tho
- arc window parameter now calculates correctly (attn: @vrcvs + @swhic)
- Live rec behaviors (loop or 1-shot) are unique per Live segment
- changing rec loop encoder resolution snaps all segments to appropriate values (attn: @hypnosapien)
- auto-slice zilchmo gesture now checks for pads’ segment assignment and auto-chops pads appropriately to the segment’s start and end points (previously, was just checking with the current rec focus start/end points)
- more fluid buffer jumping
man, you’re really doing the lord’s work in here. very exciting, thank you
you’re awesome dan. thank you very much!
Thanks Dan! This is awesome! Any plans to support the OG 64 Grid’s LED style? Not sure what it was called.
The latest version does support non-varibright LEDs.
thanks man, really appreciated
I don’t get this script at all. Not that I’ve spent more than 5 minutes with the documentation yet. But there seems to be a LOT going on.
But last night I seemed to have a really sweet jam just running audio into it… Working sort of as three delay loops that jumped around within the loops. I think? It was strange though as I wasn’t seeming any waveforms in the loops menu.
Maybe today I can try figure it out.
lol, i definitely need to do a “welcome to cheat codes 2” stream, but this excellent video from @DuellingAnts should get you going more purposefully:
this video from cheat codes 1 will serve as good orientation for understanding the script’s worldview:
early cheat codes 2 beta overview:
early cheat codes 2 beta delay deep-dive:
this sounds like you might’ve downloaded cheat codes 1 instead of cheat codes 2…both are posted to maiden as cheat codes 2 wasn’t a linear update to the original, it’s a totally separate script. if you don’t see
rnd on the main screen, it’s not cheat codes 2
I have both on here, but I’m using cc2. Will report back after I give this another whirl now. I’ve seen some of these videos, but never with it in front of me to repeat or follow… So really pointless haha
just to confirm what @Clashley1 said, all brightness generations (vari, 4-step, and greyscale) are supported in the GRID parameters menu
when you select a 64 grid, it defaults to 4-step, but can be adjusted to greyscale if you have an older gen!
Ok, not sure why I wasn’t getting waveforms last night. But I’m getting them now. Spent an hour screwing together my arc though, at someone’s recommendation and this sure makes more sense now, for some reason.
any chance with the grayscale that all things that are half bright, flash? then when they need to actually flash (to indicate recording, etc), they flash more slowly? this is how old max apps used to do it…
I have trouble understanding how to make op-z encoders work and where I should check if they work. Any guide regarding op-z + cheat codes would be awesome!
happy to help – can you point to where in the OP-Z setup notes and MIDI/OP-Z section of the manual things got led astray? i’m sure others have questions, so it’d help to know any gaps in the existing docs or if there’s an unexpected case
The default midi settings seem to work, as I see in the loops menu a1-16 changing. But as I turn encoders after setting midi echo nothing seems to happen. This might be user error as I don’t know where to expect encoders to work and if they have visual feedback at all
Also there are settings in op-z app for cc messages for encoders, mine is set to cc1-16 (that’s default I suppose, 4ccs per mode), so maybe something needs to be done there.
thanks for the additional detail! this helped identify a bug with yesterday’s release – please pull the latest version from maiden (you’ll see
patch 201129 in the initial SELECT screen) and you should be better able to see the encoders control the parameters listed in the docs
- to confirm that the encoder controls are working, try encoders 1 or 2 to adjust the selected pad’s start/end points
enable MIDI echo?in cheat codes 2 is toggled on and
MIDI IN ENABLEin the OP-Z’s MIDI SETUP settings is toggled on, then selecting a new pad should very obviously change the LEDs for the first two encoders for the OP-Z’s first mode (the first 4 CC’s), as those are tied to start/end point