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

Hmmm. Basically all the time :slight_smile: I understand the urge to reflect music theory, but this is intended for computers and they prefer 0-indexed. Ok, I could just add one to ā€œmyā€ 0-indexed value and use the op, but things like %7 doesnā€™t play well with this. Also N 0 returns 0, which makes total sense, Iā€™d expect N.S 0 0 0 to return 0 as well.

If all my input for an op like this were coming from patterns (iow: values I put in there) the problem might not that big, but most of my values are calculated or at least transformed by code, so itā€™s awkward that N.S is different from everything else.

So no concrete example, hope you see what I mean. If I think hard + long I might come up with a concrete example later, but maybe thatā€™s not necessary :slight_smile:

Exactly! Besides that N.S is broken (or Iā€™m using it wrong) on negative degrees.

I went ahead an implemented my N.Q (had to pick a non-clashing name for now). This is basically how I hoped N.S would work, wrapping across octaves (including negative degrees) and 0-indexed. Hope you find to the time to try it out and enjoy it, it feels really good here on my teletype :slight_smile: Not heavily tested, but seems to work as expectedā€¦

Oh, and yes, it reuses all tablesā€¦

NB: patch-level 0, but youā€™ll probably figure that out anyhow :slight_smile:

NB: thereā€™s a precious attempt commented out, Iā€™ll clean that up in a minuteā€¦ (EDIT: done!)
https://raw.githubusercontent.com/attejensen/eurorack_firmware_patches/master/teletype_op_nq.diff

EDIT: Ok, the juryā€™s still out on 0/1-indexed. After working a bit with the 0-indexed version, I made a 1-indexed version, Iā€™ll report back when I hear from the jury :slight_smile:

2 Likes