so, in regards to the issue of scaling a fader value. the reason here is two fold.

first, G.FDR.V is calculated by dividing the full range (which is by default 0…16383 but you can change it with G.GFDR.RN op) by the number of steps available for that fader. when that calculation is made it doesn’t round the result, it just discards the fractional part.

second, when you apply SCALE to that there is additional loss of precision.

both of these contribute to what you’re seeing, and both will need to be fixed to round properly and not lose precision. not sure if the fix will make it to 2.3, but i’ll add it to my list. funnily enough, i just ran some calculations, and if i only fix G.FDR.V without fixing SCALE the result will be even worse: you’ll get 0, 2, 2, 4, 4, 6.

there is already a workaround though. if you want to use an 8 button long coarse fader to get values 0…7 just use G.FDR.N instead, it gives you the fader value in “buttons”. alternatively, if you set the fader range to 0…7 with G.GFDR.RN 0 0 7, G.FDR.V will also give you correct values in 0…7 range.

1 Like

Thanks for the explanation. Makes good sense now.

In my case I was having trouble sparing the code lines to work G.GFDR.RN in. Looks like it sets it for an entire group which would work out well in a lot of cases, I think, except that in my case, most of the faders I was creating needed a different range. Referring to the scene “Pillar” that I posted, the note/gate tiles have 4 associated parameter faders.

Note scale 0-7
Gate probablity scale 0-99
Linger scale 1-8
Gate length scale 1-8

So I think it would have required more lines of code to first create them into their own groups and then set their ranges than it would have to just create them all at once with G.FDX and scale them on demand?

i see, yeah, in your case it might not be the ideal solution. for these specific ranges though you could set the range for all faders to 0…99 (so you wouldn’t have to use different groups) and then use G.FDR.V for gate probability, G.FDR.N for note scale and + 1 G.FDR.N for the rest.

1 Like

Hadn’t thought of that. Great idea! I think that might actually free up some characters and possibly lines!

1 Like

new release candidate. i wasn’t able to reproduce the slow down issue @EqualTemperament experienced but i’ve made a couple of changes that might help with the issue (if my guess as to what’s causing it is correct). this version also improves precision of SCALE and G.FDR.V ops (with the example @EqualTemperament posted above it will now return proper values without having to use the workaround).

release candidate 4 july 2nd
2.3 RC4

teletype.zip
teletype.hex

6 Likes

The TelexO TO.OSC.WAVE Op might need a documentation update in advance of the release.

1 Like

Nevermind. @bpcmusic is on the case!

1 Like

Hi! I just installed 2.3 last night so I’m taking a look at some of the new stuff. The new P.RND op seems cool. I began with a 4 step pattern that I was playing back with P.NEXT so I tried switching to P.RND and I found that it was choosing from all 64 steps (everything outside my 4 step pattern was 0).

So, the issue was that P.END was set to 63, which brings me around to a point of confusion I’ve always had with Teletype’s pattern tracker: the relationship between P.END and P.L. To me, it seems like it would be more intuitive if the two values effected one another… like if you set P.L, then it would automatically change P.END to be + P.START P.L. Not sure what the rationale is for how it currently functions, but in the case of P.RND not working with the same range of pattern values as P.NEXT, I think its confusing.

I’m also wondering if there are any keyboard controls for setting the loop start/end/length in the pattern tracker screen that I have overlooked. I didn’t see anything noted in the manual, but I kind of remember this being possible?

One last thing, this seems like it could be a bug, but I inadvertently discovered that in the pattern tracker view, when I hit CTRL, it changes the currently hovered cell to 6! Weird!

4 Likes

yeah, P.END vs P.L is confusing to me too. i think the intent was for length to be used when you do P.INS and P.RM, and for P.START and P.END to be used with P.NEXT and P.PREV, but then it wraps when it reaches either P.END or P.L.

we could change it so that setting one changes the other, but this would be a breaking change in behaviour so probably needs to be discussed in a separate thread before we consider changing it.

right now the behaviour is: when you execute P.NEXT it will advance by 1. if it reaches either P.L - 1 or P.NEXT it goes to P.START (link). this would need to be changed as well. also this means that P.RND does work with the same range as P.NEXT, as long as you set P.L to be greater than P.END.

straight from the source code - if somebody checked which ones are missing and modified the pattern doc file that’d be awesome:

    <down>: move down
    alt-<down>: move a page down
    <up>: move up
    alt-<up>: move a page up
    <left>: move left
    alt-<left>: move to the very left
    <right>: move right
    alt-<right>: move to the very right
    [: decrement by 1
    ]: increment by 1
    <backspace>: delete a digit
    shift-<backspace>: delete an entry, shift numbers up
    <enter>: commit edit, extend pattern length
    shift-<enter>: duplicate entry and shift downwards (increase length only
    if on the entry immediately after the current length)
    alt-x: cut value (n.b. ctrl-x not supported)
    alt-c: copy value (n.b. ctrl-c not supported)
    alt-v: paste value (n.b. ctrl-v not supported)
    shift-alt-v: insert value
    shift-l: set length to current position
    alt-l: go to current length entry
    shift-s: set start to current position
    alt-s: go to start entry
    shift-e: set end to current position
    alt-e: go to end entry
    -: negate value
    <space>: toggle non-zero to zero, and zero to 1
    0-9: numeric entry

there are 2 more shortcuts:

pressing ctrl will input the current knob value (scaled to 0…31) into the current cell, pressing shift-ctrl will do the same but scaled to 0…1023 iirc (i thought i changed ctrl to something else so that you don’t accidentally change pattern values while muting scripts but i’m not seeing it, i’ll change it to alt-ctrl).

2 Likes

I’ll check the docs, since I’m in the neighborhood, so to speak

2 Likes

great, thank you! make sure to fetch the latest changes first, i had some new commits since your last PR (git fetch -all and then git merge).

1 Like

… and it’s now a 100 commit branch

100commits

(no particular significance to the number other than indicating that it’s going to be a huge PR… which is not necessarily a good thing. but good to be getting close!)

2 Likes

as of my branch the docs match what you say. I can add the two other shortcuts if they’re not there when I fetch.

1 Like

i can add those, that’s a small change.

@freqout which doc did you use to check the pattern shortcuts? https://monome.org/docs/modular/teletype/TT_keys_card_1.3.pdf - this one? want to make sure there aren’t any other places where we have outdated info.

this is where i ended up looking… forgot there was a key-specific doc…

https://monome.org/docs/modular/teletype/manual/#patterns

Yeah, I was just gonna call that out as where you might have looked. There is more detailed information elsewhere in the same docs, which should be correct. This bit isn’t wrong, it just may misleadinglessly suggest that that’s all in terms of features and/or documentation.

1 Like

that section doesn’t have the shortcuts though… i only see it here: https://monome.org/docs/modular/teletype/manual/#tracker-mode-1 which seems to include the latest with the exception of the 2 shortcuts to enter the knob value.

edit: ah i see where it is: https://monome.org/docs/modular/teletype/manual/#tracker-mode
we should add a distinct looking note there with a link to the full section. this ought to be done for all sections under Quick Start probably… which would address this:

the one i linked is terribly outdated and should be removed (you can still see 1.3 version in the filename too). @tehn when you get a chance could you update the main teletype page to remove PDF key reference that links to https://monome.org/docs/modular/teletype/TT_keys_card_1.3.pdf?

asked in the doc thread if we can autogenerate a new key reference.

2 Likes

(Cheering y’all on :slight_smile: )

2 Likes

@scanner_darkly Hey sorry to be nosy, but I was wondering what is meant by TIME and LAST now being 1ms accurate? Isn’t the Scene State TIME variable still incremented by the clockTimer callback?

what you describe was the previous implementation. my change was to use the global ticks variable that gets updated on each tick instead (tick is 1ms). the internal time variable is still used to allow setting TIME and to keep the last TIME value when you stop the clock with TIME.ACT 0.

here is the complete fix:

https://github.com/scanner-darkly/teletype/commit/c29a0466d3a602ef930dff103400b9946fab20a2