For some reason, after the past two updates whenever I playback a pad on any bank from the live buffer I get a lot of aperiodic popping. I checked to make sure I wasn’t clipping when recording into the live buffer, and even if I recorded at a super low volume I still get popping. It seems to act up more the quicker I play a pad in succession. It never did this when I first installed cheat codes 2, and my cpu averages around 43% when using cheat codes 2. I was wondering what could be the cause. Here’s an example : Cheat Codes 2 Poppin' by China Club | Free Listening on SoundCloud
super strange – the last two updates, while including new features, have actually been minor in terms of the code and include some refinements which have reduced CPU utilization on my devices. though if you’re able to do some regression testing, here’s the last major version: Release rev 210208 · dndrks/cheat_codes_2 · GitHub.
let’s do some digging
so this only happens with the live buffer? pre-recorded clips are totally fine?
- are you using a stock norns, or a norns shield?
- if a shield, there’s been a bit of a rise in folks whose units are misbehaving due to their power supply and more importantly the cable which transfers power not being up to spec. monome highly recommends this one. the Pi3B has a micro-USB power port and requires at least 2A and 5.25V ideally supplied through a cable with 24AWG or less. lower AWG = lower noise & more stable voltage delivery for better performance. most consumer USB cables do not meet this spec.
- are you actively recording when this artifact occurs?
- if this occurs most often when you’re actively watching the waveform pages under [loops], is there any difference over time when you navigate to another page (like the main one)? screen drawing for those waveforms is one of the most processor-intensive function in the norns system, so i’m curious if that’s what’s throttling your CPU. typically, my CPU utilization drops 10% when i navigate away from watching the waveform drawing. (I also just figured out a way to avoid this entirely, so hopefully this is actually the root of your trouble!)
- if you’re able, please save a collection which exhibits this issue and DM me a zip of the corresponding folder which gets made under
data > cheat codes 2?
your audio clip sounds dope otherwise, stoked to get this sorted!
Hi @dan_derks - updated my Norns this morning, and everything seems to be working fine. Thanks again for all of your assistance!!
rev 210307: CPU optimization + 64/midigrid live buffer hotfix
@Placebo92: the recording issue you mentioned was actually being caused script-side, due to an over-exuberant 128-sized copy-paste. it’s now fixed! (all of the other stuff you mentioned is definitely repair-qualifying though, so we’ll [monome] be in touch tomorrow through email!)
@climatechanged: i was able to refine the waveform redraw during live recording to reduce CPU by about 10% when recording. lmk if you run into any additional troubles, but hopefully a combo of this and a beefier charge cable will help resolve any further trouble
What’s going on with the Rytm in this video?
summary: if you have
midigridinstalled on your norns, you can use a Launchpad to access the same controls as a monome 64 grid. for more information about the 64 grid controls, see this image .
Do you have a pdf version of this and what font style you’re using? Want to make a printable version of this, but OSR in Acrobat Pro is really not liking the png conversion and then recognition. Thought I was going crazy too re: live clip recording and glad there was a fix for it too!!
64: grid-64.pdf (23.6 KB)
font: 04b_03.zip (10.2 KB)
if you have access to Affinity Designer, all of the design files are here: cheat-codes-docs/assets/images/afdesign at main · dndrks/cheat-codes-docs · GitHub
fwiw: going to be migrating to an online docs platform with native printability in the next month, so don’t put in too much work!
Thank you Dan! Here’s a quick and dirty if anyone else wants it that’ll be a bit easier on your printer: grid64 CC2 printable.pdf (32.7 KB)
honestly, nothing too wild – in the video i’m mainly using the new
transport settings under parameters to sync an auto-start of the arps + patterns on the grid with a transport start message sent to the rytm. everything stays in sync thanks to the
send MIDI clock? section of those transport params.
@dan_derks Thank you so much! The issue was the power supply, I just switched it out with the one that came with my raspberry pi and the pops went away.
Please forgive me if this has been requested dan. I would love a ‘usb on side’ option in the grid settings. By the looks of it I think the space is there. not a huge deal at all just a desk space type of thing lol. hope all is well and can’t wait for Monday to hopefully snag those workshop vids! cheers
is it possible to feed the live buffer without hearing the input on Norns outs?
Thanks Hans, I knew it was in there somewhere.
Hi Dan, any tips on doing this? Could the arp play mx.samples instead of sending midi notes? Or at the same time, like the JF or w/syn outputs options (coud be really fun!).
There is commented code about mx.samples to load it into the main menu but I’m kinda lost about how to actually ask CC2 to play it.
hey hey! performance ended up taking a hit once arps got involved, but i’m sure the latest version of mx.samples with the CPU reduction of the last cc2 update will likely help.
dropping it in requires some architectural changes, which makes it a little bit of a heavier lift for home brew. all to say, this’ll be added to the main script, just need to optimize
Thank you, I actually got it to sort of work, didn’t looked into midicheat.lua before. I’ll wait for the “official” optimisations as it looks really promising!
Hey hope everyone is good! Perhaps I have missed something… But is there a way to create a blank cheat_codes 2 session? Like something in the parameters, or button combo?
hey hey! hope you’re having a good weekend!
are you asking for a way to reload the script without reloading the script? or do you have some state data that’s restoring which you don’t want to restore?
if the latter, there are two ways that data persists between sessions:
- if you save a
default collectionvia the collections parameters, then this will be the default state that loads up when you start a new cheat codes session (you know you’re loading a custom default collection when you see a special zilchmo splash screen). you can nuke this by loading the default collection and using the
delete collectiontrigger parameter.
- if you haven’t saved a default collection, there are a few “persistent states” which get captured and reloaded between fresh sessions. these ideally make life a little easier because they’re “set and forget” parameters. these get saved under
data > cheat_codes_2 > persistent_state.data. you can nuke this if you want to start “fresh.”
if the former, can you provide a bit more info about the situation where a fresh script load doesn’t help?
After hours of tweaking on a previous session, I want to start fresh and clean but perhaps my my mistake was to save the session I was working on as the default collection, for booting on it at startup…
So I wanna follow your advice, start CC, save the collection under a appropriate name, and Nuke the default collection. So after that I need to reboot and I imagine that a new default collection will be automatically created then?Again, thanks or your reactivity and support