I got into the habit of explicitly wrapping my counter/step variables, because I often use patterns that don’t divide evenly into the max value, or the ER pattern length. (E.g. a 3-in-8 Euclidean pattern that resets every 10 steps, or 12 steps or 15 steps, have fun grooves…)

I figure the same will be true of NR; there will be plenty of times when I want to reset it at different lengths other than 16. For instance, this is fun:

IF NR 3 0 5 A: TR.P 1     ' to LPG trigger
TR 2 NR 3 1 7 A           ' to wavetable morph
IF NR 3 1 9 A: TR.TOG 3   ' to wavefold param
CV 1 N.CS 0 5 1 - 1 A     ' to V/OCT
A % 1 A 7
2 Likes

Cool, sorry if I missed a few details, but here are a few comments:

Please make the scale degree max higher, a scale is not 7 notes it’s a mask on all possible frequencies from 20Hz-20kHz :slight_smile: It quickly gets awkward to have melodies spanning two octaves if you have to add the octave by hand. Maybe a max of 64 and a wrap that defaults to 6 and can be overwritten by the user???
And how about a few “funky” scales:

Major Pentatonic (0, 2, 4, 7, 9)
Minor Pentatonic (0, 3, 5, 7, 10)
Whole tone (0, 2, 4, 6, 8, 10)
Diminshed (0, 1, 3, 4, 6, 7, 9, 10)
Messian (0, 2, 3, 4, 6, 7, 8, 10, 11)

Nice!!!
Why stop at 7th chords? In fact, chords are just scales organized in “every other step” (what would normally be what we call a 3rd).

Suggestion: Drop N.CS and add a skip to N.S, default to 1 (or would 0 make more sense as “one step”?), changeable by the user. If the user doesn’t change skip we get scales, if the user sets skip to 2, we get “traditional chords in 3rds” if set to 3 or 4 we get quartal and quintal harmony, etc…

If you don’t feel like losing N.CS (might be simpler when the user just want’s to make a simple chord quickly), please add suggested skip to N.S, it’ll make it quite flexible…

And if you keep N.CS, making it possible to change the max of auto-wrapping degree we would have triads as well…

@Starthief Good synopsis! and yes, combining NR and ER patterns produces excellent results!

@a773 the implementation for these N ops is fairly naïve, they’re just simple tables of hard-coded scale/chord intervals and N.CS just indexes into the N.C table. Nothing very algorithmic going on.

// scales for N.S op
const int table_n_s[9][7] = {
    {0, 2, 4, 5, 7, 9, 11}, // Major
    {0, 2, 3, 5, 7, 8, 10}, // Natural Minor
    {0, 2, 3, 5, 7, 8, 11}, // Harmonic Minor
    {0, 2, 3, 5, 7, 9, 11}, // Melodic Minor
    {0, 2, 3, 5, 7, 9, 10}, // Dorian
    {0, 1, 3, 5, 7, 8, 10}, // Phrygian
    {0, 2, 4, 6, 7, 9, 11}, // Lydian
    {0, 2, 4, 5, 7, 9, 10}, // Myxolidian
    {0, 1, 3, 5, 6, 8, 10}, // Locrian
};

// chords for N.C op
const int table_n_c[13][4] = {
    {0, 4, 7, 11},  // Major 7th       - 0
    {0, 3, 7, 10},  // Minor 7th       - 1
    {0, 4, 7, 10},  // Dominant 7th    - 2
    {0, 3, 6, 9},   // Diminished 7th  - 3
    {0, 4, 8, 10},  // Augmented 7th   - 4
    {0, 4, 6, 10},  // Dominant 7b5    - 5
    {0, 3, 6, 10},  // Minor 7b5       - 6
    {0, 4, 8, 11},  // Major 7#5       - 7
    {0, 3, 7, 11},  // Minor major 7th - 8
    {0, 3, 6, 11},  // Dim Major 7th   - 9
    {0, 4, 7, 9},   // Major 6th       - 10
    {0, 3, 7, 9},   // Minor 6th       - 11
    {0, 5, 7, 10},  // 7th sus 4       - 12
};

// chord scales for N.CS op - values are indices into table_n_c
const int table_n_cs[9][7] = {
    {0, 1, 1, 0, 2, 1, 6}, // Major
    {1, 6, 0, 1, 1, 0, 2}, // Natural Minor
    {8, 6, 7, 1, 2, 0, 3}, // Harmonic Minor
    {8, 1, 7, 2, 2, 6, 6}, // Melodic Minor
    {1, 1, 0, 2, 1, 6, 0}, // Dorian
    {1, 0, 2, 1, 6, 0, 1}, // Phrygian
    {0, 2, 1, 6, 0, 1, 1}, // Lydian
    {6, 0, 1, 1, 0, 2, 1}, // Locrian
    {2, 1, 6, 0, 1, 1, 0}, // Myxolydian
};

I see. How do you feel about my suggestions?

They’re good suggestions. The skipping and parameterized wrapping seem like they would definitely be doable. For now, I’m going to leave things as they are but maybe I’ll revisit them later. That said, I’d certainly encourage you or anyone else to take a shot at it. More than happy to answer any questions that come up.

to continue from the teletype 3.2+ discussion thread:

what should be the desired workflow? something like this?

  • create dev branch in the monome teletype repo - this branch is the latest “official” beta
  • a dev starting development creates a new branch in their own fork
  • once ready, they rebase on the latest upstream/dev (in case there are new commits), create a pull request, merge to dev and post a new beta

a github action to auto build would be great, not sure how feasible it is considering the toolchain set up?

What do you think about adding two additions to the SCENE command:
SCENE.P x - Load patterns from Scene x into current scene.
SCENE.NP x - Load Scene X preserving patterns from current scene.

3 Likes

Hi all,

Hope this is the right thread to discuss. I’ve been working on a new Teletype operator that allows easy generation of exponential rhythms (think bouncing balls, strums etc). I had this stuff implemented using recursive scripts before, but I felt it could be packaged neater as an operator. The idea is that you can generate a ratchet, but one where each successive repeat has its time altered with respect to the previous repeat by a constant multiplicative factor.

What I have right now is basically an extension of DEL.R or DEL.X. I’m calling it DEL.G for now. The first two arguments are the same as DEL.R/X. The next argument (or arguments) set the factor that’s applied to scale the repeat time after each repeat.

Is this kind of operator at all interesting to anyone else? I’ve got it working to my satisfaction in my own fork, but if anyone else is interested I can try to clean it up and go through the process of an official PR.

If so, there’s a couple of questions that’d need input

  1. What to call the op? DEL.G (g for geometric) is fine, but feels a bit long. I guess it’s hard to break away from the established DEL.R/X paradigm.
  2. How to specify the factor that’s used to multiply the delay/repeat time. There’s two options at the moment. DEL.G 16 500 2 3, where the last two numbers are the numerator and denominator of the factor expressed as a fraction. Alternatively, theres DEL.G 16 500 66 where the last argument expresses the factor as a percentage. I’m leaning towards the numerator/denominator version atm.

Any ideas? I’d be especially interested in ideas for shrinking the command down, as with the long operator name and 3-4 arguments, you for sure can’t fit more than one command after the :.

9 Likes

I think I like DEL.G for the op, for consistency – but maybe DEL needs an alias?

I think a percentage may be best for the scaling factor – that gives you just enough space to fit an RRND expression for it for intentionally uneven delays, as long as it’s just a script call you’re doing.

Can the delay time go over 100% for delays that slow down?

Or perhaps break it into multiple ops:
DEL.G.SET x y z (repeats, base time, factor)
DEL.G : command

That would allow the SET to be done manually or go into an init script.

2 Likes

I would certainly use this. Could it be possible to specify the curve? Logarithmic, Exponential (or Linear) acceleration. You’d need to be able to select accelerating or decelerating too. Sorry if this is over-complicating an Op you are trying to simplify!

Yup, the multiplier can be over 100%. You’re of course capped by the max delay time of 32s though.

I like the SET idea, it’s quite neat. Only issue is that you’d really need to change DEL.R/X to be consistent, and that would break compatibility. I guess that wouldn’t be popular?

1 Like

Currently you’re literally just multiplying the previous value with the factor repeatedly, so it’s kinda fundamentally exponential only. Have to think if there’s way to shape that further. I think the other shapes would need to be different ops then though, as there’s definitely not room for another argument.

1 Like

Just wanted to chyme in and say “yes please!”. The TT is on the same case as my ADDAC503 Marble Physics, but more bouncy stuff is more than welcome. It would be great to have this in a PR and officially documented.

Thank you for your work.

1 Like

I’ve just done a quick DEL.G build for you all to have a play with (no guarantees about stability). Anyone know what the threshold is I have to pass in order to get permissions to upload files to the forum?

By default this is at trust level 1.

I don’t know if this helps with this application but there are some fixed point arithmetic routines (log, sqrt, trig functions) available in libavr32.

Super excited you’re interested in contributing to Teletype firmware!

2 Likes

Alright, thanks for the info. Guess I should have registered earlier rather than lurking :joy:

So, here we go. Feel free to try this build out. Syntax is:
DEL.G a b c d
where a is the number of repetitions, b is the initial repeat time, c and d are the numerator and denominator of the fractional multiplier.

As a starting point, try out:
DEL.G 16 200 2 3: TR.P 1
teletype.hex (620.1 KB)

5 Likes

Paging thru the previous development thread today for buried treasure, I was surprised that the base 12 tracker concept didn’t get any traction!

Love to see another powerful delay OP added to TT’s formidable rhythm arsenal; thanks @jngpng!

Are there memory issues with increased DELAY_SIZE? I might petition for another increase from 16 to 32 :sweat_smile:

Glad you like it! I’m running DELAY_SIZE = 64 in my local build and didn’t see any problems yet. I haven’t done a full stress-test though.

1 Like