#144

oh ha, woops, i’m dumb.

i get that - but i don’t think literally streaming many channels to disk all the time is a realistic feature request for norns. IOW:

no, i don’t think that’s an easy win at all. coding effort would be minor (routing is trival, thread sync and buffering are not) but it would tax the physical limitations of the device… (i will investigate the write speed of the actual emmc part, but it can’t be more than 400MB/s and is likely much lower. you’re asking for 1MB/s right there, and we would need to be very careful to amortize the writes.)

i’d encourage the train of thought that focuses on working within the provided capabilities, or at least seriously investigating how to expand them safely and efficiently.

for example - it doesn’t really look like you’re using 3 of the softcut voices (am i wrong about that somehow?) or most of the buffer length. so you could always be capturing the output of the 3 playhaeads you are using, into longer regions, and then save those “record regions” to disk using the existing API. requiring no massive new demanding changes to the DSP structure,

woops again, @dan_derks sorry i see that you actually already said this above. (the other voices are used for delays.)

oh, ha again. all the level params do have slewing, but there are no commands to change the slew time for level_cut_cut. so i’ll add those. adding commands is trivial if they are just exposing parameters that already exist.

i’ve mentioned it a couple times here - filter parameter calculation is expensive and that’s the reason they are only updated once per block. but yes, they definitely should be updated per-sample if it can be made feasible. there are several things i can try with varying levels of complexity. 1) just try it naively and see if the CPU hit is as bad as i think it will be. 2) use a linear tan approximation, which is OK but is a bit of a bummer because the low frequency range gets nonlinear. 3) use something like spline approximations for the whole coefficient function, which could work well but will be kindof a PITA. 4) something weird, like have accurate coefficient calculations at each block but then just slew the coeffs directly in between (instead of applying slew to the inputs of the coeff calc.) it’s on my list but it’s work.

3 Likes
#145

ach, ok: yes you can run supercollider code written for norns, on other platforms.

you can also build and run the crone and softcut processes on mac.

user scripts like the cheat codes logic run in a scripting layer. the scripting layer interacts with abstractions like grid and screen provided by the system layer. the system layer is highly dependent on POSIX-compliance and somewhat dependent on hardware. so there are several layers of difficulty in porting the whole stack to other platforms: easy for linux, bit harder for macos, very hard for windows; in all cases nobody has put in the substantial work required to emulate the screen and so on.

1 Like
#146

for sure, thank you for guiding the convo! and for navigating our reckless theorizing :slight_smile:

sweet, thank you so much!

gotcha. makes sense + i’ll explore doing this with metros for now, just to see if dumbly muscling it is even viable. thanks for the guidance!

also, @zebra, it’s gotta be said again how amazing softcut is. there’s no tool within my abilities to do what it does – this script really hits it hard and it’s a fuckin’ champ. so, thank you a fourth time this post.

#147

eh… i dunno if i’d bother? i didn’t mention a fifth possibiliy, which is very easy: i can make filter parameters slewed at the block rate instead of the sample rate. this is super simple. i didn’t mention it because it’s not awesome. it would be basically the equivalent of using a metro at ~3ms, but without the massive amount of OSC traffic that would generate.

#148

ah, yeah, thaaaaat’s p much what i was gonna do. well, i’ll hold then! thanks ez

1 Like
#149

Thanks for the responses. I believe that we’re thinking of the same thing but just to be sure – in my mind Norns wouldn’t be recording ‘all the time’ but only when enabled (i.e. I’ve got my performance down, now I want to record it). But I get that that might be too much for the hardware.

:+1:

#150

right, and to clarify: norns does this with two channels of audio. it just can’t multitrack, which is what you’d need if you wanted norns to print individual stems of your performance across three (to five) softcut voices in cheat codes.

it all sounds real good in stereo tho :slight_smile:

2 Likes
#151

Indeed! :wink:
I’m looking forward to digging into it.

1 Like
#152

is the K1 alt button supposed to work on the panning & loops screen ?

#153

not on loops – since the norns controls are different than the loop controls on grid, i didn’t want to muddy things.

no good reason why not to do it for panning, must’ve been an oversight! will add to the list, thanks dude :slight_smile:

to clarify: the grid alt button deffo works for all the grid things, tho, right? for example, hold it and hard pan a pad in the bank to L ([x][-][-] on row 3 of zilchmo) and all pads in the bank pan hard L, yeah?

(edited the pan command)

1 Like
#154

i don’t think it does atm? would love some live panning that could be recorded from zilchmo. also i’ve been noticing some crackling coming from this script specifically and was wondering if that had something to do with not being on the current update? i’m using a fates

#155

oh! woops, mistyped! hard pan is [x][-][-] in the 3rd zilchmo row. holding grid alt + pressing the far left grid key in a 3rd zilchmo row definitely pans all the pads in that bank far left.

once we get pattern overdub sorted out, this will be viable. otherwise, it doesn’t really improve on just changing the panning on the fly or just programming your panning onto the pads.

mayyyybe? i’d imagine if you had a TON of modulation happening in addition to the reverb + compression, you might be pushing things? i haven’t experienced any issues tho – but the new softcut update does clean up the consumption, so it might be worth upgrading when you’re able.

1 Like
#156

edit that would be amazing thank u once again for this script and all your quick assertive modifications and responses.

hmm i’ll have a look to make sure the next time i’m cheating…

1 Like
#157

for sure, i think this would be nice. thank you for engaging with the script! your energy + creativity are super duper appreciated :slight_smile:

out of curiosity, how long are your patterns + how do you work with them? i ask because here’s how I’ve been approaching balancing patterned playback w/ dynamics:

  • record the basic pad pattern in “classic”
  • while it plays back, each pad’s parameters are totally reassignable
  • use zilchmo gestures as the pattern plays back to change a single parameter for the pad currently playing in the pattern
  • use grid alt + zilchmo gestures as the pattern plays back to change a single parameter for all the pads – really dope to quickly do grid alt + [x][x][x] in zilchmo row 3 to randomize ALL the pads’ panning while a pad pattern plays back, or grid alt + [-][x][x][-] in zilchmo row 4 to randomize the loop window positions for all the pads in the bank, etc

as we write, I think there might actually be room for a third pattern record mode to supplement “classic” (only pads recorded) and “rad sauce” (pads + zilchmo recorded at same time; a gesture looper) – one that records only zilchmo gestures, which can be played back at the same time as “classic”. cuz my hesitations around throwing all the zilchmo gestures into pattern recorders with the pads is that you end up getting static loops. they sound neat and dynamic, but they just end up looping a performance of gestures which can still be tracked/anticipated over time. so it might be super fun to have two patterns running on the same bank – one for pad movements and one for zilchmo changes. then, if they’re out of phase, you can get some really dynamic results.

this, in addition to some of the pattern linearization stuff planned for v1.2 (or v.1.1.1.1.1.1.1.1?) might make for some spicy 'za.

anyway. thanks for rubber ducking!! <3

5 Likes
#158

oh damn i didn’t know about this, this is vv clever!

1 Like
#159

yeah! this is why I opted to keep “classic” around, cuz i found that once you start recording zilchmo gestures (“rad sauce”), you need to return to a pre-gesture state once the pattern starts playing back – otherwise, you would get painted into a corner. without pre-gesture restoration, you’d get into a situation where if you record enough upward octave jumps into a pattern, you end up topping off at 4x with no way to get down (because the zilchmo playback is continuously trying to double your rate).

beyond whether zilchmo gestures are recorded as part of the pattern, this is where the real split between “classic” and “rad sauce” comes in: whether or not you are overwriting the pre-gesture state of a pad. so classic asks “what is the current state of this pad?” (leaving you free to reassign the state of the pad as the pattern plays back) whereas rad sauce says “this was the state of this pad and here is what it changed to”. so in rad sauce, you can make in the moment changes to a pad as a pattern plays back, but they’ll never stick once the loop comes back around.

3 Likes
#160

yes this would create some dynamic maneuvering and spacialization. especially with certain gestures to panning while pushing the delays. makes me think of sitting in the middle of a quadrophonic arrangement with two scripts running at the same time😌

1 Like
#161

makes a lot of sense. you had the foresight not to paint yourself into a corner. reverting back to “classic” is helpful as it can help you restart when things get too chaotic. this is also really helpful from a compositional standpoint. it gives you time to reflect rather than panic and provides some needed space to appropriate some new gestures.
“pre gesture restoration” a formidable tool in itself

  • thought i’d report back - i 'm up on the newest norns update, my reverb and compressor are off yet i’m still experiencing these intermittent clicks which are similar to the ones @ypxkap was/is having…any ideas what this could be? thanks
1 Like
#162

If i load up something in my tape as a sample and then sequence it I also am hearing clicks and pops while having no reverb and compression on and no extra sequencing of filters or anything. The clicking and popping only comes in after the pattern recording and its not consistent.

I did create some recording yesterday that have these pops and clicks but its drenched in reverb.

This script is very awesome and fun to create with.

1 Like
#163

folks mind sending me yr samples? it’d be good to have a consistent starting point :slight_smile:

additional steps to reproduce would be rad – actually, if you can save your settings which produce clicks as a collection, then send me the collection data file so i can load on my device, that’d be awesome.

i just tried a basic test and got no clicks / pops:

  • loaded a long sample from TAPE into clip buffer 1
  • recorded 9, 32, and 68 step patterns in “classic” mode
  • played them back
  • adjusted panning and rate and levels as they played
  • recorded to TAPE for 1.5 mins

obvious potential cause: there’s a chance that if a pad’s loop end points are at the edge of the buffer, that the audio in the buffer might not extend all the way to that far edge and there’d be a resulting click when the audio drops off.

here’s what it sounds like:

around 10 sec, i pull the loop point back 100ms and it resolves.

as @robotboot mentioned , patterned pads that have different filter settings will likely pop if the differences are drastic due to no slewing on the filter parameters. that’s getting addressed on a system-level. i know that wasn’t your specific trouble, but looking to see what others are experiencing too.

fwiw pt 2: if you’re doing Live and recording over a section that you’re also playing back from, especially if the loop windows are small on both the live and playback buffer, the playheads will be crossing over the record head and will create a pop. i have a ducking method i’m testing rn to help in the future, but this should also be mentioned.

edit: @robotboot, oh right, you’re in chicago!! oh man, we could also just meet up to debug :slight_smile:

1 Like