not familiar with that part of code, i’ll have to check what’s the purpose of it. i think it’s related to this?

which only applies to global vars.

ya I’ve never seen anything like it before which is why I inquired. not sure if it’s because the scene state struct has so many members, or just because there’s more than one simple variable unlike execute state. I suppose it saves code space too.

i think it’s just to avoid having to create separate functions for each variable

1 Like

Yep. It’s just cheating to save lots and lots of (error prone) typing. It also keeps the code size down.

edit:

Just in-case, the warning is about something else. @sliderule put it in, it might be about how the live variable display works.

2 Likes

cool really good to know. I guess the question stands though, would this be desired for additional temporary variables in the execute state?

regarding the idea of sine cv out. if my understanding of how CV.SLEW functions is correct, then instead of adding a delta on each step in the cvTimer_callback, you could instead call the sine LUT function.

potential hurdles to overcome with this approach:

  • convert the step into an angle to pass into fix16_sin_parabola
  • convert the return value of fix16_sin_parabola into a voltage
1 Like

Wasn’t sure where the best place to share this might be, but I added a few handy keybindings to Pattern mode that let you quickly enter values from the N table.

0 = 10 is kinda obvious, but I made 1 = 11 semitones because you can already do one semitone with ALT - [ ] and by making it 11, we now have the ability to transpose up or down by any value between 1 and 12 semitones via a single key command.

Here’s a little demo video:

11 Likes

Sounds great! What’s the easiest way to apply your work to my local branch? I like to work with patches, I’m old school like that…

2 Likes
git remote add discohead https://github.com/discohead/teletype
git pull discohead pattern-mode-key-bindings

If you want patch files git will do this too:

git format-patch origin/master..discohead/pattern-mode-key-bindings

will output one .patch file per commit, or

git format-patch origin/master..discohead/pattern-mode-key-bindings --stdout > onefile.patch

will produce a single .patch file with them concatenated together.

1 Like

Thanks a lot, will try this out asap!

1 Like

@a773 let me know how it goes!

1 Like

I might need to step up my github game, but I got it working.

  1. cloned a fresh copy of current teletype github
  2. merged your work with the first two commands listed by @csboling
  3. cloned another teletype repo
  4. removed .git from both
  5. diff -Naur unpatched-path . (from the clone with your work merged)

Compiling as we speak…

2 Likes

If you just want a diff between the current master branch on origin (https://github.com/monome/teletype) and another branch you can do this with

git diff origin/master discohead/pattern-mode-key-bindings

after adding discohead as a remote.

The easiest thing for modding the Teletype source long term is probably just to put your own version on a branch and commit your own changes to it, and pull in changes from other people’s forks or from origin when new stuff gets merged into the main Teletype repo. From scratch:

git clone https://github.com/monome/teletype
git checkout -b my-changes  # make a new branch and switch to it
git remote add discohead https://github.com/discohead/teletype
git pull discohead pattern-mode-key-bindings  # pull in changes from someone else's fork
git pull origin master  # pull in new stuff that's been merged to github.com/monome/teletype since you cloned
# after making some of your own changes, stage and commit them:
git add -u
git commit -m 'added new such-and-such'
# if you've forked the repo on github, you can push your changes to your fork:
git remote add my-own-github https://github.com/my-own-github-acct/teletype  
git push my-own-github my-changes  # push the 'my-changes' branch to your fork

Generally what I’ll do is work on each feature in its own branch, then merge everything into a csboling-dev branch which is where I compile beta firmwares that contain everything. So, starting from an up-to-date origin/master:

git checkout -b some-feature
# do some work
git add -u
git commit -m 'repolarize graviton phase inverters to counteract the plasma resonance'
git push csboling some-feature  # push the branch to my fork so I can make a pull request
git checkout -b csboling-dev  # this branch already contains changes for some other beta features
git merge some-feature
make  # build the firmware with the new feature added
git push csboling csboling-dev  # update the branch on my fork that has all my changes

This makes it easy to keep each feature separate so that it can be its own pull request – which I hope you’ll consider making @discohead! Extra keybindings can be such nice little usability enhancements.

4 Likes

@csboling Thanks for all the guidance. I went ahead and made a PR. I am but a humble, self-taught, web developer who’s only ever tinkered with C so probably best if someone cleverer than I gives it a review. More than happy to make any suggested changes.

2 Likes

I made some new OPs. My changes to the docs are copypasta’d below…

[NR]
prototype = “NR p m f s”
short = “Numeric Repeater, p is prime pattern (0-31), m is & mask (0-3), f is variation factor (0-16) and s is step (0-15), returns 0 or 1"
description = “””
Numeric Repeater is similar to ER, except it generates patterns using the binary arithmetic process found in [“Noise Engineering’s Numeric Repetitor”][numeric_repetitor]. From the description:
Numeric Repetitor is a rhythmic gate generator based on binary arithmetic. A core pattern forms the basis and variation is achieved by treating this pattern as a binary number and multiplying it by another. NR contains 32 prime rhythms derived by examining all possible rhythms and weeding out bad ones via heuristic.
All parameters wrap around their specified ranges automatically and support negative indexing.
Masks

[“N.S”]
prototype = “N.S r s d”
short = “Note Scale operator, r is the root note (0-127), s is the scale (0-8) and d is the degree (0-6), returns a value from the N table.”
description = “”"
The N.S OP lets you retrieve N table values according to traditional western scales. s and d wrap to their ranges automatically and support negative indexing.

Scales

  • 0 = Major
  • 1 = Natural Minor
  • 2 = Harmonic Minor
  • 3 = Melodic Minor
  • 4 = Dorian
  • 5 = Phrygian
  • 6 = Lydian
  • 7 = Myxolidian
  • 8 = Locrian
    “”"

[“N.C”]
prototype = “N.C r c d”
short = “Note Chord operator, r is the root note (0-127), c is the chord (0-12) and d is the degree (0-3), returns a value from the N table.”
description = “”"
The N.C OP lets you retrieve N table values according to traditional western chords. c and d wrap to their ranges automatically and support negative indexing.

Chords

  • 0 = Major 7th {0, 4, 7, 11}
  • 1 = Minor 7th {0, 3, 7, 10}
  • 2 = Dominant 7th {0, 4, 7, 10}
  • 3 = Diminished 7th {0, 3, 6, 9}
  • 4 = Augmented 7th {0, 4, 8, 10}
  • 5 = Dominant 7b5 {0, 4, 6, 10}
  • 6 = Minor 7b5 {0, 3, 6, 10}
  • 7 = Major 7#5 {0, 4, 8, 11}
  • 8 = Minor Major 7th {0, 3, 7, 11}
  • 9 = Diminished Major 7th {0, 3, 6, 11}
  • 10 = Major 6th {0, 4, 7, 9}
  • 11 = Minor 6th {0, 3, 7, 9}
  • 12 = 7sus4 {0, 5, 7, 10}
    “”"

[“N.CS”]
prototype = “N.CS r s d c”
short = “Note Chord Scale operator, r is the root note (0-127), s is the scale (0-8), d is the scale degree (0-6) and c is the chord degree (0-3), returns a value from the N table.”
description = “”"
The N.CS OP lets you retrieve N table values according to traditional western scales and chords. s, c and d wrap to their ranges automatically and support negative indexing.

Chord Scales - Refer to chord indices in N.C OP

  • 0 = Major {0, 1, 1, 0, 2, 1, 6}
  • 1 = Natural Minor {1, 6, 0, 1, 1, 0, 2}
  • 2 = Harmonic Minor {8, 6, 7, 1, 2, 0, 3}
  • 3 = Melodic Minor {8, 1, 7, 2, 2, 6, 6}
  • 4 = Dorian {1, 1, 0, 2, 1, 6, 0}
  • 5 = Phrygian {1, 0, 2, 1, 6, 0, 1}
  • 6 = Lydian {0, 2, 1, 6, 0, 1, 1}
  • 7 = Myxolidian {6, 0, 1, 1, 0, 2, 1}
  • 8 = Locrian {6, 0, 1, 1, 0, 2, 1}
    “”"
15 Likes

speaking strictly from the point of view of extending the language, i would go with more verbose ops - one letter ops are the most valuable and i would keep them for something more general (like more variables or a group of ops similar to pattern ops etc)

3 Likes

NR, NS, CN, CS?
And 20

@scanner_darkly makes sense. I’ve changed them to SN for “Scale Note”, CN for “Chord Note” and CSN for “Chord Scale Note”… but feel to suggest names and I’ll use those.

… although now that you mention “a group of ops similar to pattern ops”, maybe it would make sense to have these on N? N.S, N.C, N.CS ?

2 Likes

very cool ops. i vote for the N.* notation

@tehn yea I like that too… looks like that’s done just by naming them op_N_S, op_N_C, op_N_CS… is that all there is to it?