If you want to send a minimum of data, you can use a one shot square lfo, that sends only 2 values. This probably have to be sent just before of after the note. On the same trig, CCs are normaly sent after the note.
And it doesn’t really answer about the different behaviour between OT and DN with same midi monitoring…
After re-reading i can not even make sense of what the problem is. The only true advice i could give is sticking to simple test scenarios to eradicate interfering signals.
Snoize Midimonitor is one of the best i know, pretty exact and has also much better views to show what data flows apart from that hexdump that to interpret is not possible without midi specs of the targeted machine as this is sysex. It should look more like…
The picture I shown is advanced view, maybe it can reveal a difference between OT and DN.
Windows user, I used Midiox, Miditest and Miditest (same name). Same results.
Where is the buggy bit ? 
Your responses have been really helpful so far so thanks. I’m going to revise the original post to condense the issue and make it make more sense as well as add some videos to show the problem first hand so stay tuned
as suggested, send me your bank files and project file without wavs in one folder as zip. I can open it and even make literally screenshots of all settings. Much much easier to analyse and would be the first time someone would get that sweet offer :)*
in case you know how to use mac-“terminal” you can use the following commands to convert data to hex prints and the hex prints comparing with…
or byte by byte comparison
or binary comparison
if that helps: 7bit Note-Off are defined as 0x80(==ch0) followed by note pitch this note-off corresponds to (i.e. 0x3C==60) followed by velocity (0x00 or 0x64, or higher). In most cases sending velocity 0 in note-off practically means no aftertouch shall follow. Velocity 64 as note-off therefore allows a releasing note to be manipulated with aftertouch messages. In short a all in all classic Note-Off is like 0x80+0x3C+0x00 for a C-note which was send before as 0x90+0x3C+0x80. As soon the note-off msgs do not correspond to earlier send note-on you actually have a note-closing problem, most interfaces will start to choke as then the note-off has to be found in a not existing note-on buffer which typically fails and might repeat that process until some note-on was found.
Ok folks, after some time away i have returned to this, determined to get to the bottom of it. I will revise the original post in order to make it a little easier to understand and for anybody in the future to possibly find if it gets resolved.
The (current) solution:
On the Octatrack MIDI sequencer track, set one of the 3 LFO’s to the following in the MIDI LFO SETUP page:
*You can set this to any CC slot from 1-10, and it seems to work with multiple CC numbers but since i discovered the solution by going nuts with the crossfader which sends MIDI CC48, i set CC1 to that. I suppose you can start there then try others if you are trying this solution yourself and your own lighting controller utilises this CC for something else.
SO! I have a one page pattern running at 120BPM (though it works flawlessly all the way up to 300) with a trig on every fourth step. The trigs have a single PLOCK on them each just for the note they’re sending out, alternating between C0 and C#0 which is flipping my lighting controller between “scene” 1 and 2.
Without the one shot LFO that triggers with every trig, as noted elsewhere, this would hiccup and malfunction constantly, never completing a single page as intended with the lighting controller frequently missing 1/2 to 2/3 of commands.
With the above settings however, which appear to be the sweet spot after a lot of troubleshooting, the lighting controller has not missed a single command, even at maximum BPM
Now, i’m not sure what this reveals about the Octatrack’s MIDI sequencer and how it behaves, as as a reminder the Digitone Keys/A4mkii/RYTMmkii midi sequencers behave perfectly without this fix, so it isn’t as easy as simply dismissing it as the fault of the lighting controller itself as these tests have proved that the octatrack does indeed behave differently. Somehow the LFO sending a bunch of midi commands on the same channel after the note… unsticks(?) the midi data stream and the other commands send out just fine. huh.
So there we have it for now, a solution, revealed by frustratingly flailing about on the crossfader
Any further discussion or insight is welcomed as, to my knowledge, this hasn’t really been discovered before on this forum at least not for this application, and it has stumped elektron support themselves
I’d like to thank @sezare56 and @Shredrr for their extremely helpful insights in solving this particularly. Thanks guys
Congrats @chrl_nrys ! Still a mystery…
Did you try with a square lfo, in order to send less midi data ?
I haven’t read through the thread yet (sorry, in a hurry atm), so just ignore me if the following isn’t of interest. 
I remember having an issue that sounds like the same thing a while back when preparing for a live show. I was also using the OT for DMX, btw. In my case I used one of those DIN MIDI -> usb adapters. The midi choked up, bytes were missing etc. I don’t think I was sending a lot of data, but I might remember that part incorrectly.
Anyways, three different usb midi adapters caused problems, the fourth worked without a hitch. I was not able to reproduce the issue with midi from computer or other gear. All usb midi adapters worked just fine except with midi from the OT. I remember thinking the issue was very strange, but I didn’t have the time to investigate and just stuck to using the adapter that worked.
there is one scenario that was not discussed yet that can spook your otherwise pretty looking midi data flow.
Which is signal spam, in the sense that you assigned a CC output to (in example) LFO and punch out massive speedy changes which would fill the midi stream with data in all available bit’s. One symptom would be that your device chokes on data maybe even goes out of tune or becomes stalled and re-appears as normal when you slide a value which forces CC48 (SLIDER) to re-evaluate the midi value state of the sequence and seems to free the device of the spam as long you move the slider. That is because midi has a baudrate and you can not fill in more data than what can be transported bit by bit in the time (ticks/beat) given between MIDI clock signals.
And it would also explain why on a DT you have other or no symptoms because i guess it has no LFOs to be assigned as CC output available. Or i am wrong (having no DT in my house).
That would in particular disturb a midi stream that has to pass thru and is altered with the help of an OT.
Sorry to derail the thread a little, but perhaps it might be worth having a sticky topic about known Octatrack midi issues. @moderators?
Possibly also worth @Patrik seeing this?
The two most common issues encountered are:
*Note, I have also experienced this anomaly with the Monomachine, where the data sent was not received correctly by the recipient device, so possibly it will also be an issue with MD too.
My theory is that the midi data pulse amplitude (or perhaps width) is not quite within the expected range of the recipient device, hence the ambiguous behaviour experienced.
Might be worth @Elektron looking into this as it might be fixable in firmware.
Thanks as ever to @sezare56 for bumping me.
Edit: Note applies to mk1 and mk2 OT.
Even for midi signal quality ?
All I can say is that I recently had the proof some OTs can have a weaker signal than other machines, even a Model Cycle.
It was with a MKI. I never encountered midi issues with my old MKI, first generation with “grainy” faceplate.
I never noticed the problem on my mk1s (both older style paint) but have had it with mk2.
So I guess there is a chance that component tolerances or something could be a factor.
Square doesn’t work! It seems that tri works best, as in the only with 0 flaws so far, as rand would sometimes get caught up
Yep! It makes absolutely no difference. I’ve just tried it again to make absolutely sure. I was already sending it through a buffered midi splitter before troubleshooting it direct anyway
And as I noted somewhere before, sending the digitones midi sequencer (which communicates with the lighting controller flawlessly) into the octa and out of the MIDI OUT (which acts as a soft thru when set to the same channel) it also develops the same problems. The problem is the octatrack
I am using the black MKII for reference
This seems like it COULD be the issue though I’m not sure I understand fully. So just because the octatrack CAN send all these CC changes on every available bit, even if it doesn’t, it still occupies them and chokes up the recipient devices ability to refresh and check the actual note changes on time? Unless I’ve missed the point entirely. The DN(K) can also send CC changes, LFOs and pitchbend etc so I’m not sure how it differs?
https://youtube.com/shorts/0bha7_fA2vQ?si=2n6ZpX3Bysv_X74k
LFO on ^
https://youtube.com/shorts/BRSTgpC6YPs?si=5v1KxBxVXVFAmDj1
LFO off ^
This is totally random so I apologize – but have you tested whether you are using a MIDI cable that has all 5 pins wired (not really MIDI spec) vs only three pins wired (MIDI spec)?
I only ask because this causes issues with Atari ST, where the MIDI OUT has an extra pin or two wired for use with a Y-splitter to be MIDI THRU. I always have to be careful to use a real three-pin-wired MIDI cable to the MIDI OUT of my ST.
Just food for thought – I have no reason to believe this would be true for the 
and totally defer to the wise posts above 
.
This would make me think it is a signal mismatch issue, at OT midi out port, soft thru is processed, hardware thru isn’t.
Soft thru or from thru port on DT?
Did you try any other hardware thru? Like a dedicated thru box or something else.
This is interesting and further points toward a signal mismatch issue to me.
