#1

Starting this thread to initiate a discussion that emerged from this thread:

But wanting to focus on Teletype / Telex implementation.

There is a way to include selected scales in the Telex units that @bpcmusic outlined here:

but I am wondering if there could be a more streamlined way to offer a path to explore the amazing wealth of various scales for the TT use. I am specifically thinking of experiment friendly approach that would allow to switch scales easily/quickly to explore tonal variations more adventurously.

Imagining some way of, for example, populating the patterns with various scale sets. Where one would write a script feeding of a particular pattern, and then be able to swap different scales while monitoring the sonic outcomes, etc.

In any case, am curious what other ideas you might have, or approaches to integrating Scala resources deeper within the Teletype and Telex environment.

Here is the Scala page for reference:
http://www.huygens-fokker.org/scala/

5 Likes
A user's guide to the wonderful world of teletype āŒØ
#2

I could imagine a utility similar to @bpcmusicā€™s that would generate pattern text for teletype save files rather than a lookup table for telex source code. I havenā€™t actually looked at the script yet, but I canā€™t imagine it would be all that difficult to achieve.

1 Like
#3

I would love to see a way to store an array of values, in cents, in a scale lookup table.

Itā€™s really cool to be able to compile scales into the Telexes (if you have them, and I do), but being able to build scales on the fly would encourage experimentation.

Something like (ā€œMTSā€ = ā€œMicroTonal Scaleā€ command family):
MTS.NOTE [scale number] [note number] [value in cents] (inserts/replaces a value into a scale table)
MTS.SPAN [scale number] [cents] (allows for non-octave scales)
MTS.READ [scale number] (dumps scale values to the console)
MTS.Q [scale number] [raw value] (quantizes value)
MTS.N [scale number] [note number] (lookup table method of specifying output values)
MTS.SD [scale number] [raw value] (gets scale degree from raw value, wrapping)

So a 12TET scale would be defined in the console like so:

MTS.NOTE 1 1 0
MTS.NOTE 1 2 100
[ā€¦]
MTS.NOTE 1 12 1100
MTS.NOTE 1 13 -1 <ā€” defines the end of the scale

One advantage of a lookup table like this is that thereā€™s no requirement for a ā€œscaleā€ to be an ascending series of values.

1 Like
#4

Yeah, that would make it slightly less problematic than the current need for rewriting the Telex firmware.

But still, I am wishing for a easier/faster way to 'audition" multiple scales.

Maybe some way to include scale data transfer within the USB scene saving scenario? Or a similar scheme specifically for loading scale banks?

1 Like
#5

I seem to have lost the reply that I wrote to this post. Apologies. User error again, I imagineā€¦

TELEX Perspective

Iā€™ll point out that my design objective for the TELEX was to get as much capability as I could out of the four DAC channels. At this point, the microtuning support uses lookup tables to keep things snappy. The math to extrapolate them is somewhat expensive in embedded world and I optimized it out when I was pushing the firmwareā€™s capabilities. This isnā€™t to say that the firmware canā€™t be modded to employ a more real-time approach to scales and still perform with some clever caching. :wink:

One of the approaches that I was thinking about was designating a pattern for a scale and then transferring that to the TELEX. Fill up a pattern with values, declare the patternā€™s END, and send the pattern to the TELEX - something like TO.PSCALE 17 or TO.PNSCALE 2 17 that would target a user scale location 17 within the TELEX.

The reason for the transfer is that the DAC in the TELEX supports 16 bits of resolution over -10V to +10V. The Teletype supports 14 bits (hence the 0-16384 range of values). By sending note numbers to the TELEX (using the various .N commands), CV can be output using all 16 bits and get you higher precision for the microtuning - which itself is wholly dependent on the tracking and tuning of the oscillators receiving the CV. Should also note that the OSC functions within the TELEX will be super-precise on the tuning as there is no CV translation layer.

This way, we can use the existing list framework for managing the scale definition. The TELEX can use its existing quantization and note targeting operators. The only thing we are adding is the ability to user-define a few scale slots and transfer the pattern data over from the Teletype.

This doesnā€™t take into account what to do on the Teletype side with this (for outputting microtuned CV). Consider my TELEX implementation for SCALE and QT as an option here. At least it would be consistent. :slight_smile:

3 Likes
#6

My experience of writing about three versions of firmware for my own microtuning quantizers (AVR platform) is that the math isnā€™t that complex. My cycle times were dominated by the ADC times for the CV inputs; the rest of the operation was trivial except for my first version which also had a OLED display to update.

I stored everything in cents and computed the value to send to the DAC on the fly with not much more than some modulo division and range mapping, which you have to do anyway.

But whatever the approach, being able to load scales from the Teletype UI would be amazing and lend itself to exploration. :slight_smile:

3 Likes
#7

Yeah - Iā€™m sure there are things we can do to optimize the thing. :slight_smile:

3 Likes
#8

Iā€™m so stoked with what we already have, it seems greedy to want more!

3 Likes
#9

Me too!
But you know: seems that every idea starts with some form of dialogue (external or internal)ā€¦ :slight_smile:

2 Likes