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 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.
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 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.
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).
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.
@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.
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!
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.
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.
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…