Teletype Disting EX integration

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.

@scanner_darkly Makes sense.

Would it help to limit the number of timers to, let’s say, 8 timers?
As I understand it, that would give us 8-tone polyphony, which would be more than enough for me personally.

Each of the eight timers take notes in the order they arrive.
Once the 9th note arrives and no other timer is yet finished (“free”), the 1st note gets a noteOff and its timer resets.

it would still be 8 timers dedicated to a specific device though - and then the question would be, why not do something similar for just friends? er-301? this would also mean that any future device would also need to get its own triggers.

i think a better solution would be the generic NOTE op i proposed here: NOTE teletype op (which could also provide various voice allocation options).


I didn’t know about this thread and your proposal.
I just read through it and think it’s a great, even better, solution.

Is the NOTE op something that has any chance of being implemented? Seems like the idea hasn’t been revisited since 2018. It’s a good idea regardless of whether this would apply to EX and the aforementioned MIDI issue.

i might consider adding it - tbh since there didn’t seem to be much interest i put the idea on hold. i do think it would be a good addition in that it follows the teletype philosophy of language expressing musical ideas well. no promises though.



I am having troubles for sending notes with TT out from the ExpertSleepers Disting EX midi breakout.
I am using, for example,

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

But there is nothing out the midi.
I know the connections are goods; i2c work and midi also (it’s work with Kria in midi mode)

Is there something I forgot in the code ?
If someone use it, it will cool to have some details about the configuration and the script.
Maybe I forgot something, somewhere ?


does it work when you send other commands from teletype to disting? is it just midi that is not working?

@scanner_darkly Yes all work excepted just the midi commands from TT.
I am able to sequence and control the algorithms with i2C.
Do I have to select a specific algorithm for the midi ? Or does it pass thru the Algorithm ?

you should be able to use disting MIDI ops regardless of which algorithm is currently selected, as long as it’s a single algorithm.

if the disting is receiving i2c okay and you can use the disting midi mode from ansible then i’m not sure why it’s not working. have you tried just sending notes without using variables and delays? also, check if you’re on the correct midi channel, you can set it with EX.M.CH channel.

1 Like

Does the Disting have any option to filter incoming MIDI messages? Sometimes devices are able to cut the stream of incoming MIDI. Also channel is a good place to look. Gah knows how many times I’ve had that problem!

1 Like

Thanks for the help @scanner_darkly and @ParanormalPatroler ,
Maybe my error was trying to write the entire line,
I try with two line with delay note off command first and now it’s work.
But I find it not as stable as Ansible midi…
Sometimes there is strange behavior.
And sometimes it’s mess with the delay note off.
Thanks :pray:

this indicates that the i2c bus is not 100% stable, try turning the pullups on disting on and off and see if that makes a difference.

Ok yes or do you think maybe it’s not enough stable because in the same scene I also send sequence to Disting Ex Multisamples, Just friends, Er-301, CV, Gate teletype, and read some SweetSixteen faders.
Same notes and triggers out at same times ( I use it for make out of a sequence on all these modules)
Maybe it’s too much ?

i would definitely qualify that as very heavy usage! not to say it’s impossible to get reliable performance with this but yeah it would likely require more work getting a reliable configuration. one thing you could do is just create a scene for stress testing, something where you could hear easily if commands are being dropped, then run it with one device for 30-60 minutes at a high metro rate and then add more devices one by one.

1 Like

And I forgot to precise that I send all of this on 5 voices of these modules…
I think I don’t really need all of this but I wanted a script with all devices setup for live improvisation and not to have to delete lines before start performing.
For having a scene ready to use with all devices.
But yeah ! It’s definitely too much…

Your suggestion is perfect, I will try to stress my system for to know the limit of it…

Thank you again.

Edit : @scanner_darkly I understand now, for finding the problem I delete line after lines and for realize that the problem come from midi script. The note X variable was to high…

But the problem still occur in some state of use, like fast trig
It flavor like some probability on notes…

Quick question… how do I use EX.M.CLK? I would like to sync my Digitakt with the Teletype and then control the patterns via EX.M.PRG.