nmSmartyPants

nmSmartyPants

if you regularly fail at elementary school math, then this script is for you

nmSmartyPants

lol yeah, so you wanna impress those cool nerds in the cafeteria, but the thought of solving a simple math formula, or whatever that stuff is called, like 1+5*10/2, is making you stress sweat like there’s no tomorrow, then expand your measly attention span for just a minute and read on.

Wequiaments

you need a norns! and external audio! can you get that done?! you can connect a MIDI too, but I’m not going to waste my time by attempting to explain that

Documentation

you wiggle E1 to select a thing and then you wiggle E3 to change that thing. easy enough, right? there will be numbers! and math! it’s going to be wrong, but you wouldn’t know the difference anyway.

r stands for “record head position”. oh boy. I’ll let you guess what the p stands for.
t is time in seconds, which will count up constantly in a loop from 0 to 100. t is the basis of your calcluation. similar to those bytebeats (don’t click that link, it’s not for you).

okay, one thing I do need to explain (unfortunately). this thing here % is the modulus operator. it makes stuff loop! so for example something % 6 will never rise above 6, but wrap around to 0 instead and go on climbing up again. + does offset, * does speed. That’s it.

if you get nothing done, then press K2 or K3 to randomize r and the p and feel ashamed.

hold down K1 and E3 will change stuff faster.

hold down K1 and press K2 or K3 to reset r or the p.

wiggle E2 to fade between … ah, whatever, you’ll hear it.

Release History & Download

v0.0.3 - just another number
v0.0.4 - stuff got refined
v0.0.5 - more math

download gitHub ZIP drive

Installation

in Maiden:

;install https://github.com/TuesdayNightMachines/nmSmartyPants/

okay, you got that far. congratulations, I guess. now show off to those nerds that you can make noise with many impressive numbers. if this script finally gets you laid, I demand you post the juicy details in this thread. nothing better than some awkward nerd love stories in the morning.

23 Likes

just making sure the bytebeat reference isn’t confusing me- is softcut the only sound source in this script?

1 Like

yes. bytebeat is too much math

EDIT: sorry, yes. to expand: the bytebeat reference is just there as it was an inspiration to me. this script here also relies heavily on a constantly rising value and the modulus operation, but in the context of sampling.

You’re like a machine at the moment!

3 Likes

Haha, yeah. I’m traveling for work since two weeks and am sitting alone in hotel rooms every night due to covid. perfect way to learn norns! I probably won’t be able to keep that release rate up, but it’s so much fun and I still have a bunch more ideas. Somehow the supercollider side hasn’t interested me yet. Softcut is just so much of a joy to work with as a beginner.

10 Likes

I love bytebeats but find the results hard to work into my own music, so this looks amazing!

1 Like

I think (hope) that it will serve as a simpler and easier graspable playground indeed.

The tape strip in the bottom half with the moving play and record heads helps a lot to visualize the formula results. And since the tape strip is 100 seconds long and doesn’t loop at a blazing 8kHz, one has a lot more time to look at what’s happening. Also, the script might output some encouragements every once in a while to keep your mood up :wink:

3 Likes

loving your scripts my friend! heres a challenge, since I love your serge videos so much (and I;ll likely never see that panel in real life)… could you make a script based on Infinite melody music ??? :pray: :pray: :pray: :pray: :pray: :star_struck:

3 Likes

Oh wow, that’s a great idea and I think it would totally be possible with Norns putting out MIDI CC or MIDI Notes instead of CV. I’ll need to dig into the MIDI side of Norns a bit deeper, but I’ll tackle that challenge!

6 Likes

i’'ll def buy you a coffee or beer or whatever equivalent floats your boat :beers:

btw, the post you did on “modwiggler” explaining infinite melody music was totally mamazing, in depth, and any one interested should definitely check it out

4 Likes

Super fun! Been having fun listening to how the sounds get mangled with just the shame buttons. I’ll try to understand the maths but probably won’t cuz math.

1 Like

Thank you! Maybe this will serve as a mini tutorial:

  • multiplying by a number greater than 1 makes the head move faster
  • multiplying by a number smaller than 1 will make it move slower
  • multiplying by a negative number will play reverse
  • adding/subtracting will shift the head on the tape
  • using modulus (%) will loop the head

Example: t * 2 % 10 + 10
… *2 will playback at twice the speed
… %10 will play in a 10-second loop
… +10 shifts the head on the tape by 10 seconds

The expression is simply solved from left to right, so no rules like “multiplication before addition”, etc. I.e. the math is wrong :wink:


Thank you! I’ve also posted my guide on gitHub:

5 Likes

thanks for that explanation it make more sense. I noticed some zipper like sounds occasionally, similar to what can happen with my Er301 loopers when the play head and record head overlap. Maybe happening for the same reason with SmartyPants. I don’t think a fix has been found in the 301 environment. Have you noticed it?

Anyway very cool script. Here’s a noodle with it.

1 Like

I love it! Thanks for the performance :slight_smile:

The zipper noise does indeed happen when the heads either cross or run in sync too tightly, in which case the play head reads data at the same time as it is written. I’m not aware of a fix (but I’m a total noob here), other than elaborately checking for these situations and then adding some sort of skip just before the heads cross. I’ve actually tried this with my mnQuadroDubber script once, but that leaves the question what to do with the little gap in the recording that would result in these cases … but yeah, I’m only coding for Norns since two weeks or so, so maybe somebody else knows of a good solution?

Two weeks…wow!

I think I’ve notice it only in the “sync to tightly” scenario. I don’t hear anything when the play head is moving fast across the record head. It happens so infrequently, it’s not a big deal. The fix does seem difficult, maybe there is no solution for this one.

this possibility will for sure exist whenever you have two voices that are referencing the same buffer region with arbitrary position and rate, and at least one is recording.

if you really want no clicks, point the voices at different regions, accounting for fade times. of course this limits the weirder possiblities.

(arbitrary point of terminology: the softcut voice abstraction manages both a read and a write head - actually a pair of each for crossfading. read and write heads maintain a fixed phase relationship that is updated per sample - hence no jitter between them. it looks like in this script you use two voices, each of which has both record and play heads engaged.)

(in the next version we’ve implemented a “ducking” behavior, where any voice (call it A) can be given a duck target (voice B), and the level of A will be attenuated when pos(A) is close to pos(B). typically B would be recording. this works well to replace clicks with smooth dropouts in plaback (not in recording), except in the edge case when A and B are both in their xfade regions, which i’m still working out.)


anyways at a practical level i’d recommend adding some kind of option to the script if you want people to be able to decide to point the two voices at different buffer regions and avoid clicks that way. you can still route audio between the voices to do weird stuff.

4 Likes

Thanks for the clarification! :slight_smile:

I wanted one freely moving record head and a freely moving play head, so I indeed used two voices. One for recording and one for playback (and a third “hidden” one to have at time reference and to trigger update_position). I was under the impression that softcut.play(v,1) is needed for all voices to “move” along the buffer region, so both heads are “playing”. Only one is recording though.

I’m not sure if I understand this. In this script the idea is to record and play from the same “tape loop”, but move the record head and play head arbitrarily around on this loop. So both heads/voices would need to be set to the same buffer region, or not?

yes - if that’s what you want, then that’s what you got. its clear that there will be playback glitches when they cross, or when they move closely together (such that the 4-sample interpolation windows overlap.) (glitches will not be recorded though.)

i guess my suggestion (and not the same thing at all) would be to consider having both voices reading and writing, but on “separate tape loops”, and have audio feedback between them. that should be glitch-free. you can also use the asynchronous buffer commands to arbitrarily copy+mix material between the loops if that is interesting.

sticking with the current design, you could try a rough version of “ducking” by comparing the results of a phase poll on each voice, and lowering play_level for the playback voice based on the distance between them. (i guess kinda like you already are exploring with just having a position jump. but position jumps are less immediate and the glitch will still occur within the crossfade period.)

(i also want to be able to do glitch-free simultaneous R/W addressing of the same region with independent heads, but yeah it’s a non-trivial problem to make it work totally perfectly, given the varispeed controls and things like arbitrary preserve levels in the crossfade period.)

not quite. enable is what controls whether a voice’s heads are moving or not. the play flag just enables/disables the read head. honestly there is probably not a lot of point to disabling it vs just using play_level, but it does save some CPU if a voice is only ever going to be recording. (
(sorry that these API names were not exactly chosen with perfect foresight.)

(rec and rec_level are analogous, but disabling rec will save more CPU since varispeed writes are expensive and the expense is proportional to the phasor rate.)

2 Likes

Thanks again!!! Very valuable insights and ideas for a newcomer like me! :slight_smile:

np. it is helpful to know where we can improve documentation. (i’ll PR a change to the docstrings right now to hopfully clarify usage of rec, play and enable.)

and of course it’s always cool to see the system being pushed in interesting directions, that’s the whole point of the game to me. none of these functions are super novel from a DSP perspective (though we are working on a couple new tricks) but we want the programming interface to be really natural and easy.

6 Likes