#67

I see. How do you feel about my suggestions?

#68

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.

#69

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?

#70

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
#71

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
#72

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
#73

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!

#74

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
#75

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
#76

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
#77

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?

#78

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
#79

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

#80

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
Teletype 3.2+ feature requests and discussions
#81

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:

#82

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
#83

always great to see more people contributing to teletype dev! :black_heart:

let’s use this thread for new features and beta builds so that it’s easy for people to find: Teletype 3.2+ feature requests and discussions

(i think this thread is actually about firmware development, not the firmware itself)

2 Likes
#84

Would it be wise to add a .gitattributes file containing * text eol=lf to the Teletype repo root? This should help Windows users avoid converting line endings when cloning.

I know it is easy in Git Bash to avoid the EoL conversion with a --config core.autocrlf=input argument during clone, but it is not currently possible in GitHub Desktop. :man_shrugging:

EDIT: Testing this out on my own fork, it looks like we would need to call out which types are binary so that it doesn’t screw with the line endings. It looks like this is limited to .png, .jpg, and .ttf right now.

* text eol=lf
*.png binary
*.jpg binary
*.ttf binary
1 Like
#85

Time has passed, I started working with esp N.S and I find it very useful. But I always seems to need a lot of supporting logic code to work with it. Two things that I feel could make it much easier to use:

  1. have it 0-indexed (first degree is not “1” but “0”)
  2. have it span multiple octaves (including negative values)

I know changing this (esp the 0-indexing) would break peoples code, but I have to ask: any chance we could change this?

Alternatively I could make a “parallel” OP that does what I want, which letter would be the least offensive to use over “S”, so N.Q or N.T or something? I’m thinking both in terms of my local version not clashing with future firmware and the prospect of it possibly making it’s way into the official firmware.

2 Likes
#86

After some discussion here last summer, the N.S and N.CS scale degrees were changed to 1-indexed. This matches the music theory they are founded on where degree I is the tonic. Can you share an example of where you are needing extra math to account for the off-by-one issue?

The breaking issue is already on the table for the upcoming numeric release, so that is maybe less of a concern. BTW if this change is made, please change the OP’s code and not the table it draws from. The table is shared by QT.S and QT.CS.

This seems like a decent change to me; basically you would trade the currently common need of calculating the octave for the potential (rare?) need for modulo math if you want to strip out the octave.
E.g. X + N.S Y * 12 / Y 7 becomes X N.S Y, or potentially X N.S % Y 7. As a bonus, this fixes the issues with octave math when you cross into negative octaves.

1 Like