#497

DEL.R and DEL.X are in official 3.0 firmware (Edit: I was sure they were but I don’t see them in the 3.0 manual. The latest beta is very stable though.)

DEL.R 5 100: TR.P 1 will fire trigger 1 5 times with each pulse 100ms apart. With the first trigger occurring without a delay.

DEL.X works in a similar way but the first trigger is delayed by the delay time.

7 Likes
#498

Beautiful! Thanks @rikrak @alanza. Can’t wait to try this one.

2 Likes
#499

Oh and don’t forget to set TR.TIME to a suitably short gate length.

4 Likes
#500

Yeah, this is very useful @rikrak !

@b_w - preceed that script with a line reading the param knob and you’ll be able to set the rate on the fly. The param knob range could also be set in the init script with your min and max ms values.

1 Like
#501

I’m constantly forgetting TR.TIME default is 100ms and often run into that issue. I kind of wish the default was 15.

1 Like
#502

the easy way to check whether something is in the official release is finding the latest official release version number either on the official firmware release page or the firmware guide thread and then checking the changelog.

as of today the latest official teletype release is 3.0, so anything listed as added after that is in beta right now (for detailed info and links to relevant threads including where to find the latest beta see the firmware guide above).

3 Likes
#503

Would like to ask, how does one use ‘Break’ in the scripts and in what scenarios?

#504

Here’s an example where BREAK is a bit more elegant than the alternative:

M:
L 1 4: $ 1

1:
A I
PROB 75: $ 2

2:
CV A N PN.NEXT A
TR.P A

Vs.:

M:
L 1 4: $ 1

1:
PROB 25: BREAK
CV I N PN.NEXT I
TR.P I

(Actually, without being in front of a Teletype I’m not sure it’s necessary to transfer I to A in the first example or if it would still pass through in the second script call. Even so, I find the second version a little cleaner.)

1 Like
#505

Just in case it’s helpful: BREAK halts the execution of the rest of the script (if you write BREAK; ... even the rest of the line will not be executed). So often you “hide” it behind PROB or IF PREs to do what @Starthief illustrates—control whether part of a script happens or not.

2 Likes
#506

I think I get it, but will need to try to put it into a script to see how it works for me. Thanks @alanza and @Starthief

2 Likes
#507

I have a question regarding trigger input behavior.

I’m sending a momentary gate via a footswitch into trigger input 1 of Teletype to reset the first track of Kria. Script 1 has the following code:

KR.POS 1 0 0

The first track of Kria is resetting when I send a gate, but it’re resetting on both the rising and falling edge of the gate. This happens with gates from the footswitch, Just Friends square wave cycles, etc. The hardware reset input on Ansible behaves the same way.

I’d like to be able to reset the Kria track with only the rising edge of a gate, not both the rising and falling edge. Is there some way to specify this behavior? There was a thread where @tehn mentioned this behavior could be altered but I haven’t been able to find how to do so.

Also confused because it seems like riding-edge-only detection should be the default behavior… I’m running Teletype 3.0 and Ansible + polyearthsea.

#508

What are you using as a footswtich and when did you get your Teletype?

#509

I got it from the recent batch of black PCBs, same that need the TR.3 fix (haven’t done that yet).

I’m using an ADDAC Floor Control, albiet inverted through Math’s mixer for appropriate 0-8v response (using a normally closed footswitch when the Floor Control requires normally open). But, using gates / squared CV from Just Friends produces the same result.

#510

Do you have a scope to look at the output of both? Teletype should respond to the rising edge, not double trigger.

I would also double check all your scripts just in case. Have you tried it with other commands or to trigger one of the gate outs on the teletype?

1 Like
#511

No scope at the moment unfortunately. Does seem like the source of the gate does vary the behavior. Tested a simple TR.P 1 output with the following results: Foot Control (both direct and through a mixer) and Just Friends caused the double trigger; Maths End of rise /cycle, a Teletype trigger output like, and short triggers from Kria/elsewhere don’t seem to cause it. Strange…

#512

I get this behaviour as well if incoming gate/trig is above 5V (e.g. 10V). I if it’s around 5V i only get 1 trigger on rising edge. I’ve used it to great a though.

#513

Amplitude of these trigger sources doesn’t have an effect for me, attenuating any of the sources I’ve tried ends up with the same triggering behavior, so it must be something with the voltage source itself. This is only really an issue for me regarding the footswitch, resetting rhythms manually and such. Will keep playing around with it.

#514

Been searching and cant figure it out - is it possible to reset metasequences with teletype?
thanks!

#515

Just ran into a possible bug within JF synth mode - I’m not sure if this has ever been addressed or if I’m just overlooking something. Scripts are super simple, just changing the pitches of JF channels and triggering them manually via different scripts. It’s much easier to see in the video below, but basically the problem I’m having is that sometimes certain notes of the chord ring out indefinitely as opposed to being triggered/plucked and then decaying as they should (apologies for video quality!):

2 Likes
#516

I am finding this too. I think I fixed it though. I’ll check tonight, but what I think I found was that I hadn’t specified V for volt before the velocity for one of the command. Eg:
JF.NOTE 6 N 12 8
Instead of
JF.NOTE 6 N 12 V 8
I’m not entirely sure that this was it or it’s fixed though…