Telex: Teletype expanders

[bpcmusic]

Are you 100% sure you’re building with the DEBUG code disabled?

100%. With no USB connected, it would have never started up as it would be waiting forever for the serial connection.

can you try manually setting a GPIO high right at the beginning of the setup function and measuring that.

I will this evening when I’m back from the office and a dinner. On second thought, might be more like early tomorrow morning as I’ve not had the best of luck with wine and probes in the past.

not sure the use of new will cause the hundreds of milliseconds delay though

It doesn’t. When I measured it, it didn’t look like the init function took over 1ms to execute.

At this point, I’m really not sure where the delay is coming from. Need to root around some more to see if I can identify any more potential culprits.

Will check again tonight/tomorrow morning.

[sam]

Try a blank sketch with nothing in it apart from turning a GPIO on? That will give you the absolute baseline. (Well, not without replacing the Teensyduino framework.)

After you’ve sobered up though

[bpcmusic]

Ok. Test complete.

Right there with you, @sam; was planning to create an empty sketch with only the LED set. Here is the code:

And, what is going on is so evident visually that I didn’t need to wait till the wine-free morning in order to scope it.

• The TXo on the left is running the full module code is getting TO.TR.P 1 delayed at 191ms.
• On the right, the code above is executing with a pulse on TR 1 and nothing else; no additional libraries, no additional code…

Video follows:

https://youtu.be/rlHRMwtVkfs

Um…

Time to get more paper towels and dig in.

[sam]

I downloaded the video and Zaprudered it frame by frame. The Teletype is fully booted before the 2 LEDs come on

According to this post, you can define your own startup_early_hook to run code even earlier in the boot process.

PaulStoffregen/cores/blob/master/teensy3/mk20dx128.c#L685

---

Right, just tried my own TXo, with DEL 210: TO.TR.P 1 in the I script, I get no pulse at power on. With DEL 211: TO.TR.P 1 in the I, I do get a pulse.

That’s with a Doepfer LCB w/PSU3.

[bpcmusic]

Announcing TELEX Firmware v.016

TELEXo Changes:

• Recompiled reducing Teensy startup to 175ms (from 400ms)
• Optimized memory for LED and Quantization Tables (moved to FLASH)
• Fixed updates to envelope AD times while the envelopes are active and in that segment

TELEXi Changes

• Recompiled reducing Teensy startup to 175ms (from 400ms)

Get them here:

bpcmusic/telex

Remember: make sure your Teensy is not connected to Euro-power when updating the firmware! Instructions for firmware updates are in your manual and on the main GitHub page.

---

@sam & @tehn -

I was able to reduce the startup time for the TELEX so that no additional delay is needed on the Teletype - although we still may need to add a little one on the TT to keep it from racing Ansible and others to the starting line.

Turns out, at some point a 400ms delay was added to the Teensy prior to calling the USB initialization to reduce complaints when people were trying to use components that weren’t ready because the Teensy started up “too fast”.

I modified “pins_teensy.c” on line 586 from 400 to 175. This should capture my case and @sam’s case - which was a little slower. I could go lower - but I didn’t want to push any of the components to unstable places (especially the DAC).

// for background about this startup delay, please see these conversations
// https://forum.pjrc.com/threads/36606-startup-time-(400ms)?p=113980&viewfull=1#post113980
// https://forum.pjrc.com/threads/31290-Teensey-3-2-Teensey-Loader-1-24-Issues?p=87273&viewfull=1#post87273
// reduced to 175 from 400 for the TXo firmware
delay(175);
usb_init();

I’ll be putting some instructions for this on the GitHub site for the TELEX tomorrow for those that want to compile it themselves. Unfortunately, you have to go in and modify the code in your Arduino directory. It applies to everything you compile for the Teensy. (Shudder.)

Here is the nice forum where I got some help (saving me a lot of time):

https://forum.pjrc.com/threads/44692-Optimizing-Teensy-3-2-Startup?p=145480

Finally, thanks for inspiring further investigation. I’m glad we could keep startup as zippy as possible.

[dudadius]

Hey folks, what is the setup for using the onboard ADSR as a VCA?

[michael_matos]

Not next to mine but if I recall you setup the oscillator ( cv level 10, Osc to a freq greater than 0) then set up a trigger , then set up an envelope.

[dudadius]

Thanks…but I guess I’m missing the routing part. Say you have CV 1 operating as an oscillator. And CV 2 as an envelope. What is the mechanism for routing the oscillator audio and having that envelop CV control the level?

[dudadius]

Nevermind…stumbled onto the solution. So you enable oscillator on CV 1, then enable envelope on the same CV 1. Then TO.ENV.TRIG 1 1 pings that envelope…it’s as if a VCA is built into that one CV out. (As it says in the manual…duh…but until I experienced the operation, it didn’t make sense.).

[dudadius]

Now that I’m wrapping my head around this…I want to build this up as a travel machine someday.

[michael_matos]

Exactly. It’s all stacked in one channel. It makes sense once you get it, but I admit I stumbled on it.

[bpcmusic]

it’s as if a VCA is built into that one CV out

Yup. The extended functions that are linked to each CV channel interact. CV controls the “peak”. Oscillations move between the peak and its polar opposite. Envelopes control changes to the peak over time - which cause it to behave like a VCA when the oscillator is active.

The ENV also can be a bit confusing in that it mutes the CV channel until a TRIG command is sent - at which point it goes through the envelope to the peak voltage.

Once you get the hang of everything, the interaction model opens up some interesting behaviors. Try playing with negative voltages, slews (for both CV and OSC), offsets, changes to the oscillators center (OSC.CTR), slow LFO rates, morphing waveforms, rectification, log curves, changing attack + decay times mid-envelope, and the EOR/EOC triggers. You can get some wacky-cool stuff out of it for modulation and/or audio-rate enjoyment.

[dudadius]

Thanks, gents. [head explodes]

[sam]

Nice one!

I was able to reduce the startup time for the TELEX so that no additional delay is needed on the Teletype - although we still may need to add a little one on the TT to keep it from racing Ansible and others to the starting line.

I will add a 50ms startup delay.

Have you consider asking for the 400ms delay to be changed to a define that could be overridden more easily? (And would that even be possible with the Arduino IDE?)

[bpcmusic]

Have you consider asking for the 400ms delay to be changed to a define that could be overridden more easily? (And would that even be possible with the Arduino IDE?)

The IDE is pretty crap when it comes to dependencies. I have a feeling that there is not a lot of flexibility in this regard, but I haven’t asked if it is indeed possible (or done any experiments).

I will add a 50ms startup delay.

Good call.

I was surprised that our two systems differed by 20ms.

[dudadius]

Talking about your Script above with the ENV.EOR and ENV.EOC…If I understand this Scene correctly…

Each single M Script blasts Script 8 4 times?

Then, as 8 gets triggered each time, B is read as 1, then line two it becomes 2, then on the second Script 8 read it is read as 3 and 4, 3rd Script 8, it is now 5 and 6, etc…

So those looped reads of Script 8 happen REALLY fast, eh?

[GoneCaving]

Is A needed? Can you use I instead?

[bpcmusic]

Each single M Script blasts Script 8 4 times?

Yes. This causes it to read all 8 of the TXi inputs that are a part of the script. They alternate affecting attack then release for each of the four envelope generators.

So those looped reads of Script 8 happen REALLY fast, eh?

With the work that everyone has done on the i2c stability and performance, the answer is yes. You can pound the snot out of it.

A read is more complex than a write (slower too) - which is why it is the first to show instability when there are too many devices connected without a bus board. So the rate that you execute them is worth some consideration.

Best practice is to store the value in a variable if you are going to use it multiple times. Also, you don’t need to run the M super fast for things to feel responsive from a control perspective. I’ve noticed that when controlling CV from the PRM inputs that a tiny bit of SLEW can go a long way to butter up the output.

Is A needed? Can you use I instead?

Yup. Good catch; use of A was redundant given the global nature of I.

I

L 1 4: TO.CV I V 5
L 1 4: TO.ENV.ACT I 1
L 1 4: TO.ENV.LOOP I 0
L 1 4: TO.ENV.EOR I I
L 1 4: TO.ENV.EOC I I
L 1 4: TO.ENV.TRIG I

M

B 1
L 1 4: SCRIPT 8

8

TO.ENV.ATT I TI.PRM B; B + B 1
TO.ENV.DEC I TI.PRM B; B + B 1

[dudadius]

Thanks for the info, guys! (I will ponder the ‘A’ comment whilst I nurse this Manhattan🥃)

[Geremy]

Hi,

I’m hoping that with my new TXi I can ‘play’ some sequences into the teletype from my metropolis for recording. I will use the regular IN on the teletype to store the CV to a pattern, but I’m trying to figure out the best way to record gate time. I think one way is to mult the metropolis gate out to one of trigger inputs on the teletype and and one of the TXi inputs. Then when I receive the gate and execute the script, can I do something like:

T 0
L 0 X : IF TI.IN 1 : X add X 1
PN 2 (step count) T

I don’t think nested PREs are available. There isn’t a return call so it doesn’t make sense to call a script within a loop. Any ideas?