1.4 firmware has been officially released and includes 2 new algos, dream machine and filter bank: https://www.expert-sleepers.co.uk/distingEXfirmwareupdates.html

of particular interest for people using teletype integration:

  • Added the Looper ‘Octave down’ function.
  • Added Looper-specific i2c messages.
  • Added settings to enable automatic switching of the current parameter to the one being changed by MIDI or i2c.
  • Fixed a problem where parameters changed by i2c would not immediately take effect.
6 Likes

I am very excited to see this! I’ll put it on a couple of my “notify me” watchlists!

I’ve not been able to spend any quality time with my modular recently (dealing with the awfulness of the start of teaching in a pandemic in my university), but I really want to get on board with all the updates to Teletype and Disting EX ASAP. Quick question: with the current setup can I control any of the algorithms over i2c from teletype (e.g. controlling the volume of each voice in the dream machine) or does there need to be specialised ops written for each algorithm?

EDIT: I just realised that if this is possible then the Disting running the Matrix mixer, plus teletype and just friends could make a pretty extraordinary quadraphonic generatively panning drone machine in very few HP! (Apologies if this is all old news :slight_smile:

2 Likes

you can control anything that is listed as a parameter for any single algorithm (double algorithms currently do not support i2c control) using the following ops:

EX.PARAM param value (alias EX.P)

this will set the specified parameter to the exact value provided. you can also get the current value for a parameter with this op.

EX.PV param value

is similar to the above, but it expects value to be in the 0…16384 range and it will scale it automatically to the range available for the specified parameter. this is handy to use if you’re mapping the knob or the CV input (or faderbank values), so you could do something like EX.PV param IN.

EX.CTRL controller value

this ops sets the specified i2c “controller” value - this is useful if instead of controlling parameters directly you want to use i2c to parameter mappings, especially if you already have i2c mappings set up for faderbank.

some parameters act as switches with actions triggered when a parameter changes from 0 to 1 (like augustus loop tap tempo, for instance). for this parameters you’ll want to do something like EX.P .. 1; EX.P .. 0


there are also algorithm specific parameters - they are either for things not available as parameters (like augustus loop pitch) or for things that would likely be used often, like looper ops. looper ops also can give you the current state for the mode / reverse / octave down, which are not available as parameters.

i definitely think there are some pretty amazing things possible with teletype integration!

2 Likes

Apologies if this isn’t the place for it, I’m new here, but I’ve been experiencing constant i2c dropouts since adding the disting EX to my teletype setup. Previously I had been using the txo and txi expanders with no issues but since adding the disting I’ve encountered many situations where all expanders stop responding. The dropouts usually occur when I start trying to process incoming cv through the txi expander which works fine if the disting isn’t connected.

I initially thought the problem would be solved by using a powered busboard but attaching the TT busboard to the back of the teletype makes no difference. I also have a diy teletype which I think is the later board revision anyway. I’ve also checked the pull up resistors and I only have 1 set active as I understand there are a pair on the disting too. My total cable run for all 3 modules is about 45cm which should be ok from what I understand.

Is there anything else I could try?

try disabling pullups on the disting. also the cable length might play a role, try placing the modules closer to each other.

I have the pull-ups disabled on the disting and the total length of cable across all 3 modules is a touch under 16 inches. I’m not sure I could make any shorter while still fitting it in my rack.

I feel like I’ve also used the 2 expanders with way more cable in the past.

Could it be possible that I’m just throwing too many calculations at it?

the number of messages will play some role but it comes down to i2c bus being unstable. have you tried it with the pull ups on the disting enabled? other than that i’m afraid it comes down to just trying different configurations.

Am I right in assuming that the diy teletype board that pusherman are selling won’t require a TT busboard to speak to 3 devices?

impossible to answer without actually trying - it depends on which devices, how long the cables are etc etc.

I have finally found time to test the Disting EX ops and I am more than happy. I first sequenced the filter frequencies of the new filterbank algorithm. It is so cool that you can control really every parameter, so the possibilities of Disting EX explode. Thank you so much!

1 Like

that’s really great to hear! i think there is some really incredible potential. if you’re comfortable consider sharing your work!

Thank you for your advice and quick responses I’m I’ll get it sorted.

https://www.instagram.com/p/CG64CadCad8/?igshid=nb4fxsu3nzh3

It is just a little test.

Marbles gives clock and CV pitch for Teletype and Plaits, respectively. Teletype then changes the frequency of 3 of the 8 filters (multiband mode) of the Disting EX filterbank via I2C. What sounds like beating on wooden sticks are extreme resonances of the filters. Clouds only adds a little bit of reverb.

2 Likes

@scanner_darkly

I realize this is a little too late, but would it be possible to add one additional operator in the list of available operators? Having to send a note off message after every note on, at least on sound sources that can play continuous notes, can be a bit cumbersome, and is contrary to the nice way triggers and pulses are integrated in TT.

So maybe an op that also requires a note length parameter?

EX.M.LN (note, velocity, length)

Just an idea.

1 Like

How about a more pinging style, for instance an OP that sends note on and shortly thereafter a note off (could be played rings/JF style)? Or one that automatically sends note off when getting a new note on?

I totally see the pain with doing note offs by hand, but I’ve been programming some stuff (csound comes to mind) that works with note lengths, and doing this from code always felt very backwards. Deciding at note-on time how long the note is to be held always felt like a decision I’d rather not make…

Not sure if this makes sense, just my .02 dkr

1 Like

I see your point. That’s why my suggestion was for an additional op and not a replacement of the original EX.M.N. I am sure there are valid uses for EX.M.N as well. I went with EX.M.LN for (Length or Long Note).

Additionally, I’d like to raise a few points:

  • “shortly” will have to be defined one way or another, and that is note length. Unless you want to set the length of the note as a separate op, which is absolutely fine (could even be a better solution to be honest), but that requires two additional ops (1).

  • Sending a NoteOff automatically when a new NoteOn is sent means the recipient will only play monophonically. Maybe I need more than one NoteOn at a time, or maybe I need pauses between my NoteOn’s without having to explicitly send a NoteOff after X amount of time, after every single note.

  • I don’t see how the suggested scenario works much differently to TR.P for which you set the length with TR.TIME . On the contrary, for me at least, such an op creates zero dissonance to how gates are already implemented in TT, and as such makes some sense. But again I’m open to other solutions if they don’t limit usage.

  • I can imagine that if EX.M.LN indeed had length as a parameter, it would be super easy to set that as a variable and use that to determine the length of your notes separately. Patterns seems like a good candidate :slight_smile: That is still a more practical approach than eating up scrip space by having two lines, such as:

    EX.M.N X Y
    DEL A: EX.M.NO X

The above is the use case right now. I tried condensing this into a single line but I can’t come up with something that would give the same flexibility and would still fit. This also eats up DEL space, which, as we know is at a premium.

Just an idea, of course. I’m super interested to hear what others think.

(1) Another way would be to just introduce a EX.M.TIME op which would set the length of the notes for that particular channel, and then change the way EX.M.N works to adhere to the values of that op, in the exact same manner that TR.TIME and TR.P work. In that scenario EX.M.NO would still act the same way if the note was still active, essentially allowing you to cut notes before their time.

1 Like

I like your proposal @ParanormalPatroler. I came across the same issue myself recently. Taking care of noteOffs manually via TT seems very cumbersome to me, especially with polyphony.

I found, the solution using “DEL A: EX.M.NO X” does not work when the script is triggered faster than A.
For true polyphony one would have to store the pitches for a certain number of notes somehow, maybe in a pattern or queue, and then send out corresponding noteOffs later… but I have not yet explored that idea further.

Regarding the two discussed solutions:
I would personally prefer a new OP that adds duration to pitch and velocity, e.g.:
EX.M.NL pitch velocity duration

Two reasons for that:

  • I feel “duration” is a property of a single musical tone, much the same as “velocity” and “pitch”. So it would make sense to me to define these three values together when sending a note. That solution would allow different and independent duration values in polyphony situations as well.
  • Triggers and the way their length is handled currently, feels like a different thing to me. I’m not really sure it can be compared to note duration. A trigger output is per se monophonic, and the trigger length feels more like a “setting” to me, that is usually not changed for every trigger. Therefore the separate OP seems appropriate. Note duration on the other hand feels less than a setting and more like a parameter that is defined/changed dynamically for each note.

I’m looking forward to your thoughts!

1 Like

i’m afraid it’s not really feasible. in order to have a variable note length for MIDI note on ops, teletype would need 127 additional timers (since you’d need one for each possible note). this would affect performance, and i don’t think it’s a good idea to sacrifice some performance to support functionality that not everybody will use. and what about voice ops? they would also need something similar to keep it consistent, so even more timers required.

TR supports it but this is a much more general use case, so warrants dedicating timers to it. telexo also supports it, but that’s because telexo itself keeps track of note trigger length. just friends doesn’t support it - you either set it to trigger mode and control the envelope length on jf, or you set it to gate and then you have to take care of sending a note off.

That is understandable. It’s a pitty, but the reasoning is clear so thanks for explaining it.

I guess I’ll have to work with

DEL A : EX.M.NO X; EX.M.N X 127

which happens to be exactly 31 characters! The caveat, as @attowatt pointed out, is that this can be an issue if the script is triggered faster than A.

A workaround could be using MIDI CC 123 All Notes Off, which:

mutes all sounding notes. Release time will still be maintained, and notes held by sustain will not turn off until sustain pedal is depressed.

I guess this will also need to be timed correctly, but at least it doesn’t require storing the pitches for a certain number of notes, and can be used in combination with MIDI CC 64 to hold other notes. NB: MIDI CC 123 is channel specific, in case you didn’t know.

Another solution I’m thinking of @attowatt is to use a pattern as a source for X which could essentially be re-addressed later by DEL A, or another script (???), to stop the notes.

Worth a shot I guess.