I posted a while back about a MIDI mixer I was making to accompany my Octatrack. The project is getting close to being finished, however, I’m trying to implement turbo MIDI and am not entirely sure how far I can push the octa (turbo docs provided by Elektron on request btw).
From some initial testing I’ve found that the Octatrack has the following speed options:
Mask = 0x01 7F - Meaning a maximum of x13.3 MIDI speed.
Cert = 0x00 0F - Meaning that Elektron certifies that the Octa can handle going up to x5.
First of all, does that mean that a x13.3 speed could potentially damage the Octa internally?
If not does it just result in less processing power being available for other Octa functions(FX, arrangement, …) or will the rest of the OT run like normal?
Here’s a pic of the current stage of my project, for anyone interested:
maybe there’s a limit built into there code for adapting to the turbo midi which can fluctuate depending on how/what’s connected
perhaps it’s to do with the rate at which the optocoupler or associated circuitry can reliably operate without data loss
maybe it capped to avoid internal conflicts with processing, but who knows, in any case, they flag it up as 10x in the hardware typically so maybe aim for that
by virtue of turbo-midi being a closed circuit you can only have the controller attached (or maybe a third in a bigger loop ? never heard that being discussed), so under what scenarios do you need timing accuracy 10x more than normal midi can provide - are your fades gonna be super fast or does the timing of a mute need that added precision etc - i’m not sure the benefit here, but power to you for giving it a go
by making it turbo midi you kinda block other possibilities to extend the rig and i’m fairly sure that would outweigh any advantages (assuming you have any)
looking good and no doubt lots of fun getting this together - i’d be inclined to get it robust using normal midi first, then finesse it if it seems lacking or if you are just inclined to achieve it for learning/other purposes or for reasons i haven’t accounted for of course … good stuff
Almost certainly not, in my opinion. The only circumstance like that to consider would be sending a firmware update to the OT.
I don’t think that other operation would necessarily be affected, it would just mean that the MIDI messages being sent would not be received correctly. Given that certain functions on the OT can be controlled by MIDI then some unwanted stuff might happen, but the risk is small.
Perhaps if you get it going you might add it to our epic list of all the non-Elektron devices that use Turbo MIDI:
I think this is most likely. The Mk1 MM and MD have a lower guaranteed Turbo speed (6.7x) than the MkII MM and MD. I imagine that it’s for this reason that the MD, MM, and OT have Turbo MIDI speed negotiation with their paired instrument.
As far as I know, the bi-directional connection is only required for the negotiation of Turbo speed. If you know what the receiver can handle, then there can be a one-way connection from transmitter to receiver. I believe that this is how the Squarp Pyramid and Social Entropy Engine sequencers implement Turbo MIDI on their MIDI outputs.
The goal of the project is to make a more creative production workflow, as I am fed up of using DAWs. I’m using the Octa in studio mode and the cue outputs are connected to delay FX. This allows me to use my mixer to do dub mixing. The issue with this is that I also want to have access to the metronome - I can’t output the metronome through the cue or standard outputs if I am recording(externally). The bypass is to use midi clock to generate my own metronome ticks.
8 knobs, 8 sliders and 8 buttons in total. The knobs control the cue send for each track. Sliders are track levels. Buttons are for toggling retrig(0 to max) for each track, this only works well for sliced sources(drums) so I’m in need of suggestions for other source types.
It’s 3 individual DIN connectors mounted on a PCB I designed.
Ok, that’s exactly what I wanted to hear! I’ll try ramping up to x13.3 and see if anything goes wrong. I know my side can handle going up to x20 so if all goes well I’ll see if there is a hardcoded x13.3 limit. I will get back to the forum with any results and possibly even a copy of my source code(providing I clean it up).
Due to the need for midi clock the connection has to be bi-directional anyway. I may redesign the midi module and alter the microprocessor so that I can inject midi note from a keyboard - I’m not a huge fan of the Octa keyboard.
Improved MIDI clock timing for the metronome.
More responsive to changes in the sliders and knobs.
If you position the sliders & knobs very close to the ADC level trigger they can oscillate between 2 values. Not a huge issue but worst case scenario is 16 oscillating values causing CC to be sent every cycle - At 1x midi this can affect the responsiveness(a bit of a hack of a solution)
The microprocessor code was finished before the peripheral boards were delivered. I’m just looking for improvements I can make and was intrigued when I came across turbo midi. The other reason is that I dislike analogue design and am putting off designing the metronome tick module .
Thanks for all the replies and interest. I’ll get back with the turbo midi testing results and I’ll make another post when I’ve finished the project & made a demo video.
This is rad, I’ve done this in the past with a very very similar setup with a nanokontrol and a pi. Certified awesome. Doing your own complete stack will give even more control. I hope it all goes well. Share your progress/results with us!
All previous answers stating that the internal processing of the OT will not be influenced by turbo MIDI seems to be based on the assumption that you are not flooding the OT with messages especially not at turbo speed.
Turbo MIDI is fine to get more precision and to transfer larger files (like an OS updates or samples), but it is not meant to hammer the receiving side with a constant stream of messages during normal operations.
When you do this (not sending a message now and then but constantly at every possible cycle) I’m quite sure the MIDI receive buffer gets pretty fast overloaded, because the OT cannot keep up with processing the messages while doing its “normal” job.
Oscillations like that should be suppressed at the source (rate limiting), because otherwise there is also no bandwidth left for useful information (it’s quite similar to suppressing a bouncing key).
Analogue filtering is not an option as the peripheral boards are already made and I’m not going to pay for them to be redone . The pots are only readable via a single Mux, so I also cannot add an analogue filter to the output of the peripheral board.
My only option would be digital filtering. If I add a software filter it’ll take up a fair amount of processing and still result in some oscillation. Given that this is a hobby project, and not a module for NASA, I’m going to just leave it . If I do have issues with flooding I’ll look into using another microcontroller for the filtering.
Also note that it’s relatively unlikely to land on an ADC level border, so the worst case scenario of 16 channels of oscillation will probably never happen.
EDIT: I’ll benefit from a precision voltage reference for the ADC
.