#46

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
#47

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

#48

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

#49

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
#50

@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
#51

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
#52

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
#53

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
#54

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.

#55

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.

#56

@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.

#57

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).

1 Like
#58

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

#59

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.

#60

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.

2 Likes
#61

Hello,

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 ?

Thanks

#62

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

#63

@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 ?

#64

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.

#65

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!