#778

Is there a way to set JF.VOX pitches without triggering them?

For context - I have an M script setup in which JF channels are each being “randomly” triggered. Script 1 is a set of JF.VOX pitches and script 2 is a different set of pitches. I’d like to be able to switch between those two sets of pitches without triggering a whole chord at once upon triggering the scripts.

#779

I don’t believe so. I have two workarounds for this currently:

Set up a script that ‘simulates’ the randomness but is actually introducing a new pitch via a bunch of delayed JF pitch inputs (voice specified) like this:

DEL M MULT 1: JF.VOX 1.....
DEL M MULT 2: JF.VOX 2.....
DEL M MULT 3: JF.VOX 3.....
etc.

Can’t recall if this ends up being too many letters without using vars for either delay time or the other parts (depends on how many chars your pitch + velocity scripts are… using vars for those I’ve found to be good hygiene anyway, though). If you put the vars in the script itself you can use a $ # command to trigger another script containing any voices that don’t make the first six-line cut.

The other way is to use sustain mode and six channels of VCAs…

Also there’s a good chance you’re not actually using all six outputs of JF anyway (unless you’re in cycle mode), in which case both things are more doable (the first only requiring a single script with fewer lines, and the second requiring fewer VCA channels).

I’m only ~4 months deep into a module some folks round here have had 4 + years on, so maybe someone’ll chime in with another solution :slight_smile:

1 Like
#780

@srogers91 This is an example of using patterns to store chord intervals. Here there are five notes per chord in five consecutive indexes on pattern 0. The first chord is indexes 0-4, the second is indexes 7-11, and the third is indexes 14-18.

In the metro script the variable X is used to set which pattern index is assigned as the pitch of each JF.VOX command:

A TOSS; B TOSS; C TOSS
IF A: JF.VOX 1 P X V 4
ELSE: JF.VOX 2 P + X 1 V 4
IF B: JF.VOX 3 P + X 2 V 4
ELSE: JF.VOX 4 P + X 3 V 4
IF C: JF.VOX 5 P + X 4 V 4

X is assigning JF.VOX 1 with the starting pitch of a chord, with each subsequent JF.VOX being assigned each subsequent pitch entered into the pattern. In Scripts 1, 2, and 3 variable X is set to either 0, 7, or 14 to correspond to the start point of each chord entered in the pattern. You can see variable X change with the chords from 0 to 7 to 14 on the live screen later in the video; apologies for my camera not focusing very well.

I used variables A, B, and C with the IF/ELSE ops for the easiest way to get something random that wasn’t a huge flurry of notes, since I wasn’t sure how you were using random in your case.

Not super obvious in my example since my metro rate was pretty fast (doh), but this method will allow you set the pitch for JF.VOX for the next time it’s called without calling it directly. Hope this helps!

3 Likes
#781

@yams I definitely don’t want to tie up 4-6 VCAs, this is worth looking into for sure!

@kbit my first thought was somehow using the pattern tracker but I couldn’t figure out the logistics. I’ll have to try this out with a slower speed but my only concern is not having the separation between each notes, i.e. that script triggers groups of 2-3 notes at each pulse. Regardless this is really cool and I’m gonna explore it further.

This is what I was doing at firs, with JF in synth mode, transient/sound:

M:
DEL RND 6000: JF.TR 1 1
DEL RND 6000: JF.TR 2 1
DEL RND 6000: JF.TR 3 1
DEL RND 6000: JF.TR 4 1

And each numbered script is a different set of JF.VOX pitches. The only thing I want to avoid is triggering the entire chord upon triggering each script. And I’m typing this I answered my own question with a stupidly obvious solution…

Put a DEL RND X: pre before each JF.VOX voice!

1 Like
#782

What is the easiest way to store and retrieve multiple integers from an integer? Should I just use the 1’s place, 10’s place, etc, or is there a trick?

(Yes, I am trying to double my pattern storage…)

#783

We were just talking about this over in the TT alternate firmware thread. Using decimal places, like you say, along with the / and % ops is one way to do it.

1 Like
#784

Nice, that works well for retrieval! Storage seems trickier but doable. Will have to first retrieve the unmodified portion of the number and then add it to the new number.

#785

hi everybody, i got a newbie question. i just got my TT, and running the latest firmware 3.1, been trying the teletype studies1-5, i’m starting to understand it a little better so far. now i’m trying to do just type studies 1.
i followed all the scripts on the just type studies 1. i think it did what it supposed to do, but what i didn’t get is the turtle ops, when i look at the tracker mode, the pointer/cursor is just static at one place, didn’t reflect the pitch movement, although i do get random pitch out on cv 1 out (based on the script) to my osc.
i did compare when trying normal pattern, from teletype studies 5, i did get pointer/cursor movement. i think it has something to do with the turtle ops, but still have no clue what to do about it…
do i miss something obvious?
here’s i attached the script from the JT studies 1

#1
EVERY 3: JF.TR 1 1
EVERY 5: JF.TR 3 1
EVERY 4: JF.TR 4 1
EVERY 2: JF.TR 5 1
EVERY 7: JF.TR 6 1
EVERY 2: JF.TR 0 0

#M
@STEP; @DIR RRAND -180 180
CV 1 N @; SCRIPT 1
EVERY 30: CV 2 V RAND 10

#I
M 120
@F 0 0 4 4; @SPEED 300
CV.SLEW 2 3000

#P
4 16 19 11
7 7 0 12
0 12 11 16
11 7 4 23
19 23 7 19

thanks

1 Like
#786

By the way, the same happens to me when I use the P.RND or PN.RND commands. No cursor moving on the tracker. I guess it’s normal but it would be nice to have feedback from the more experienced users.

thanks

1 Like
#788

On the pattern/tracker view, if you press SHIFT + 2 (the @ key) this will toggle visibility of the turtle cursor (a < next to the pattern cell). This is mentioned in the manual in the key reference for pattern mode, and all the way at the bottom of the first on-module help page, but should probably be mentioned in the Turtle section as well as the studies.

P.RND grabs a random pattern value from between P.START and P.END and returns it, it does not change the position of the “read head” for the pattern. Moving the read head to a random position seems like a useful separate op, possibly this could be called P.I.RND? Equivalent to P.I RRAND P.START P.END I suppose. The read head is currently only modified by P.NEXT, P.PREV, and P.I ops.

5 Likes
#789

Thanks @csboling. Got it!

1 Like
#790

ah okay thanks so much for your response! :pray:t4:

1 Like
#791

Hi all,

I’ve been eyeing up the Teletype for a minute and a few used modules have shown up on Reverb. All seem to be the green pcb version. Are there any major arguments against this version of the module? I’ve been digging through old discussions about the hardware here and it seems that the major difference between the green and black pcb versions are the number of i2c connections available without the use of a “backpack” and the amount of power that can be drawn through the module (powering a grids).

At present I would only be connecting the Teletype to Just Friends, potentially adding an Ansible down the line.

Thanks!

#792

you’ll be fine with the green pcb version, the i2c connections is more for convenience than anything. And if you run out, there’s always solutions for it.

The usb powering on the black pcb is still not ideal anyway, as it can generate noise. No matter the teletype it’s usually better to use an offworld/splitter when using the grid.

2 Likes
#793

One difference that might be worth mentioning is that the newer version can apparently handle keyboards with backlighting (lots of mechanical keyboards have backlighting and it’s a bit harder to find one without), whereas the older version tends to crash with backlighting on.

That obviously doesn’t change anything if you’re not planning on using anything else than the default keyboard :slight_smile:.

1 Like
#794

Hello all! A quick question as I can’t seem to solve this on my end:

Is there a way how to set a vertical fader that has zero value at the bottom, and the maximum value at the top? I can’t seem to find a way to work this out using the command

G.FDR id x y w h type level script

Thank you for your help!

#795

that’s how it should work for faders by default, zero value is at the bottom, max value is at the top (assuming you’re using G.FDR.N to get values, with G.FDR.V you can flip it by setting the fader range appropriately).

in general, for both fine and coarse faders G.FDR.V / G.FDRV uses the range defined with G.GFDR.RN op (it’s shared by all faders within the specified group). this is convenient when you want to use fader values for a specific range, this way you don’t have to scale it each time. by default this range is 0…16383.

G.FDR.N / G.FDRN also return a fader value but the range is defined as:

  • for coarse faders it’s 0…width/height-1 (so if you have a 5 button wide fader the range will be 0…4)
  • for fine faders it’s 0…L where L is the maximum level set when you define a fader with G.FDR.
2 Likes
#796

Sorry to be sophomoric but… Ouch?!?

4 Likes
#797

I had an alarming thing happen when updating my TT to 3.1 last night. After finishing the install, I power-cycled my system with my computer still connected to the TT via USB. This was apparently a bad thing to do, as the lights on all of my modules freaked out! I panicked and flipped my system off but all of the modules stayed on in their freaking out state. I pulled the USB cable and everything shut off. It appears that everything is working fine, but I was very scared that I fried my whole system, and am still worried that things might be damaged in ways that aren’t immediately apparent.

Is this a “of course you shouldn’t have done that” common sense thing? I feel like a couple sentences added to the firmware install instructions could be beneficial here, especially if there’s risk of damaging modules.

#798

Question–is teletype slew curved?
I’ve got a half-decent granular MLR running (thanks to @scanner_darkly’s script of course!) using TT+Grid+STS by 4ms. I use the grid to set a base CV output and then send out some slewed CV over a few seconds to scrub through a “slice” of the song, and then sequence that sixteen times for the whole song… speed of slew determines how fast playback speed will be. It’s pretty effective!
Only little bug is that whenever I jump to an earlier position in the song, it stutters on one position for a second before continuing to move through the sample again. I was curious if this was a problem with sending too fine a CV message (0-.3v over 6 seconds is what I’m in the area of right now) for the STS input to read, or if there’s a little curve at the beginning of a slewed CV signal from Teletype that the STS is getting caught up on. So far I’ve found the STS to be pretty consistent for the most part…

little demo/showin off the bug:

1 Like
Grid ops / integration