Receive midi info from Octatrack to update values

The Lounge
1

Successfully controlling all aspects of Octatrack that I’d like to. I have 2 PBF4 and 2 EN16. Apologies in advance for my next questions, I am a terrible programmer and haven’t done it since the dawn of the internet with some basic html lol.

On the rare occasion I would touch Octatrack settings for what I have mapped, I’d love to have those values sent to the Grid so there aren’t big jumps.

On the PBF4, for the Potentiometer and Fader, is there a way to set it up so that the mapped values on the Octatrack aren’t modified until i reach them with my PBF4? Or something similar to that?

The EN16 I imagine would be easier to set up as it’s encoder to encoder.

In the midi monitor I am receiving on the correct channel and also the correct CC, but for some reason I only get 1 or 2 values, and then it just stops. If I go to a different track on the Octa it starts sending again, but again will only get 1 or 2 values. This is just with the default, I have not coded anything into the Midi rx tab.

Super appreciate any help!!

1 Like
2

What you’re referring to is ‘MIDI takeover’. As none of the Elektron boxes have MIDI takeover settings or the ability to use relative values, this would need to be done on the Grid controllers. Yes, there is a way to code this on the Grid controllers but it requires some programming to get setup.

The OT would need to be transmitting those CC values out on the same channel that it receives them on. Then, you would use ‘midi_receive()’ programming to update those values for each of the Grid elements.

For faders and pots, because they have value based on their position, you would approach things a bit differently than with an encoder. With an encoder, we can just directly update its value. For faders and pots we would need to write the incoming value to a separate variable so that they can check to see if their values match before they transmit any MIDI data. They would also need to update this checked value as they send out MIDI info so that it stays in sync with with itself.

You would also want to initially update the Grid values with the current OT values. The OT is the only Elektron box that has a feature where you can request all MIDI values by sending it CC61 (I need to lookup the details for this to know what value to send and on what channel. It likely needs to be sent to the auto-channel). This way, you don’t have to wiggle knobs to align values between Grid and the OT. You can just request a value dump from the OT.

This is something I could help with but my timing is pretty tight over the next few days.

You may wish to skim the Grid documentation to see if it points you in a direction. You can find them here:

I don’t have any PBF4s but I have enough of the controllers to give element-specific assistance. Just don’t wait around on me as I’m not able to poke at this for a few days (at the very least).

Cheers!

2 Likes
3

As @_d4ydream nicely laid it out, an OT config with bi-directional MIDI would need the following parts, all configured on the Grid side:

  • A way to know on Grid if you’ve changed stuff on the OT.
  • This informs Grid to ask the OT what changed by sending a CC61.
  • Then Grid would have to compare the received values from the OT to its own values and in the case of a mismatch, switch the pots and faders to a pick-up style of behavior. This way Grid would only send MIDI if the received and stored values are matching after a change on the OT side.

All of the above, is possible on Grid. In fact most of the above has been created on some shape or form and is available on the Profile Cloud.

The big task here would be to tie all of the above together into a specific OT controller configuration. This is something I too, would be willing to help with.

2 Likes
4

well you are both champions and i am very thankful for your willingness to help! i am able to comprehend code and dissect it and change values to my liking but writing from scratch is quite challenging for me. alone this would take me a month (at least) lol. i thank you for the link to the documentation, indeed i have been reading it, but i am slow to absorb such things.

I had no idea about the CC61. this does seem like the most elegant solution. but i wonder if it might be a lot of information, and it would cause delay? seems like it would have to be something it was doing at all times, or literally anytime i touched anything on the grid, because otherwise how would the grid know to ask if something had changed? or maybe i am overestimating how much data that is.

5

CC61 is more meant for an initial or user driven dump of CC values. It’s useful for when you first fire up your setup. It would let you synchronize your Grid controllers to the current values on the OT. Otherwise, you’d need to wiggle each controller element to snap the OT to the Grid controllers’ values.

I should have a bit of time tomorrow to do some code examples for you. If you let me know the element type (encoder, fader/pot), the CC value your sending and the channel you’re sending it on, I’ll see about doing something specific to your setup. I do have an OT and at least one of an EF44, EN17, BU16, and PO16. I have all bases covered.

6

Got it! yes that use would certainly be excellent. I have only just started using this with the Octa but yeah i was noticing even on the buttons that i have to touch everything once to get synced up. With the buttons it’s fine because once they are synced they stay synced.

Faders are channels 0-7, cc 25
Pots are channels 0-7, cc 33
Encoders are channels 0-7, cc 34, 35, 36, 45

Basically Volume + 5 controls, for each channel on the Octatrack

1 Like
7

Greetings! I hope you are well and humbly ask for your wise assistance. :smiley:

8

I’ll have the time tomorrow to test it out/look into it. Will report back.

9

a million thank yous!

10

I’ve tried testing even the setup but ran into several issues. But first I would have a question for you, what kind of USB MIDI Interface / Host do you use to communicate with the OT from Grid?

The issues I ran into are the following:

  • The OT uses an old MIDI spec, called Running Status to send its CCs out over DIN MIDI.
  • I’ve tried and failed using both Knot and an M-AUDIO MIDI interface to parse these messages since neither of them support Running Status.
  • Because of the above issue, I can’t even tell you if Grid would be able to properly parse the 7(8) times 24 MIDI CC values that the OT sends out on a CC61 dump request, because I wasn’t able to even forward those messages form the OT to Grid.

For now, I’m at a loss with this setup, because I’m unable to test it. In theory, we should be able to do this, but in practice I lack the tools to set up a testing environment. In the coming weeks I’ll be able to get tools for this process, but until then the project is on hold from our side.

Apologies, I did not expect it to turn into this complicated issue.

1 Like
11

Thanks for looking into this @narayb ! I knew the Ot had some quirks but it’s nice to learn about MIDI Running Status. It’s not a method that I was aware of. I have a few tools around that I could try and find a workable solution for this. My knowledge of MIDI is intermediate but growing.

If I find a workable method I’ll post my findings.

1 Like
12

thank you both!

I am using a knot to send and receive midi to/from the OT.

the usage here is primarily for a live situation. here is a slightly different approach, possibly easier? i will be changing patterns on the OT quite often. is there a way even for the OT to send the values for the 4 encoders i am using to control on each track, upon changing a pattern? like a program change message? this wouldn’t be as great as real-time updating but it would be fine for the most part.

and then if that didn’t work, even if there was somehow a message sent back to grid that said, reset the values of these encoders to their default values upon change of pattern. three are 0 and one is 127. that could also be helpful.

1 Like
13

the continuous update would way by far be the best though as I use p-locks on many of these parameters. base, width, res, delay send are my 4

14

Sadly both one-time updates (done via CC61) and live updates (turning the knobs on the OT) are done by using Running Status.

What happens is that the OT will send the value of first CC of every track when receiving CC61, but only the first one, out of 24. That’s not very useful. And when turning the encoders, you will only get some of the value changes, usually the first change. Also not very useful.
I haven’t tested how the p-locks are sent over, those are probably fine. But either way, your controller would be out of sync instantly without either of the above on a Part or Bank change.

As I said, at the very least implementing Running Status is among the things on the Knot issue tracker. But I wouldn’t expect it very soon. In fact, I will look into Running Status-capable MIDI interfaces/hosts for testing and will inform you when I find one.

@_d4ydream If you happen to find one, let us know. Thank you for looking into this and thank you for your patience @jaosmon13.

15

Thanks again for the more detailed breakdown. I’ve only got a Knot and an ERM Multiclock. The latter may work but is a rather expensive solution. I do have a Raspberry Pi-based MIDI host and a Roland UM-One MK2 that I could try. Though, I suspect that won’t provide the solution that’s needed either.

16

thanks for the details @narayb !

well if the p-locks worked to send values, that could certainly be sufficient for me. a little extra work, but i could put a trigless lock on step 1 of every pattern that set the parameters on the grid where i wanted them.

@_d4ydream i do have en ERM Multiclock, how would that help the situation?

and then my last idea is program change messages. is there a way for the grid to receive these from OT and do something with it? it wouldn’t be a total solution, but it would still be beneficial for me to set Base, Resonance, Delay Send to 0 and Width to 127 whenever i changed patterns.

17

I don’t know. @narayb was suggesting that a MIDI Hub/Router that explicitly supports ‘MIDI Running Status’ might be the solution. The ERM is a pretty complete device. It was a thought worth exploring.

I did setup the OT to my PC with a Roland UM-One MK2 just to see what the OT was sending when turning a knob. It does appear to send all 127 values for the knob sweep which means bi-directional MIDI should work. I’m going to see if I can setup a simple bi-directional setup for one CC, no takeover coding for the time being, just to see if it works.

I’m not sure about CC61 to initialize values on Grid but let’s look at one thing at a time.

18

So I setup an encoder to send CC 34 on ch.1 to update FX Param 1. It works just fine. I setup midirx to update the value of the encoder on element[0] with the value of CC34 when it’s received on ch.1 and it ‘works’ in that it updates the encoder and LED value accordingly.

But…

It crashes the module and it reboots. This going from a Knot to MIDI IN/OUT on the OT. So, bidirectional MIDI is working but receiving MIDI just crashes the module. I don’t think anything in my code is causing the problem either.

I’m also having to force close Editor on my Windows machine. It could be that I have MIDI-OX up to sniff the MIDI OUT from the OT. Maybe they’re not playing nice with the MIDI ports on my Windows box.

I also setup the button on the same encoder to send CC61, value 0 to the auto channel. I can see the full dump in MIDI-OX. It’s literally just sending the current value of all controls. I’m not sure why this wouldn’t work either to initialize Grid. If there’s a way to roll back to the previous firmware on my EN16, I’m going to do so. My other setup has been doing some flakey stuff on the newest firmware.

Lastly, I’m going to try this scenario with my Raspberry Pi MIDI host to see if Knot is being problematic. Unsure why it would be but I’ll rule that out as well.

Edit 1: Factory reset my EN16 and just connected it to a Knot with OT’s IN/OUT connected. Turning a single knob that’s send CC34 (or anything) just crashed the EN16. It reboots. I’m going to flash up the Raspberry Pi MIDI Host and see if it’s the same thing. While testing this, I’m running the OT MIDI OUT into a THRU box and sending it into MIDI-OX. OT isn’t sending anything other than CC 34 on ch.1.

Edit 2: I setup the Raspberry Pi MIDI Host/Router and it works without issue. I can control the OT FX PARAM 1 and use the knob on the OT and it updates the value of the LED and encoder so they stay in sync. I did notice that some of the auto-config code on the EN16 happened to line up with some stuff on the OT so I erased all code on all encoders except element 0 and the system midi_rx stuff. Connected through Knot again and tested. Receiving MIDI crashes the EN16. This does not happen through the Raspberry Pi.

I’ll see about shooting a short video later. I’ll also try this on an EF44s encoder to see if it’s an EN16 thing being flakey. I had some weirdness with an EN16 setup I was trying to use. It was sending odd values out.

Edit 3: Tested on an EF44 and receiving MIDI crashes the module when using Knot. All other elements have had all code deleted. It’s just the element 0 encoder/button and the system code.

Code:

-- Element 0 - 'Setup'

local ei, ev, bv = self:element_index(), self:encoder_value(), self:button_value()
led_color(ei, 2, 255, 0, 255, 1)
led_value(ei, 2, ev)

-- Element 0 - 'Encoder'

local ei, ev, ch, cc = self:element_index(), self:encoder_value(), 0, 34
midi_send(ch, 176, cc, ev)
led_value(ei, 2, ev)

-- Element 0 - 'Button'

local ei, bs, bv, ch, cc = self:element_index(), self:button_state(), self:button_value(), 9, 61
if bs > 0 then
    midi_send(ch, 176, cc, 0)
else
end

-- System - 'Midi rx'

local ch, cmd, p1, p2 = midi.ch, midi.cmd, midi.p1, midi.p2
if ch == 0 and cmd == 176 and p1 == 34 then
    element[0]:encoder_value(p2)
    led_value(0, 2, p2)
else
end

Octatrack MIDI IN/OUT to Knot IN/OUT. Tested both Merge and Non-merge modes. Turning encoder updates FX 1 PARAM 1. Turning Knob A (which controls first parameter slot on active page) sends out its value correctly (tested in MIDI-OX). If you turn Knob A one or two values at a time, you can see the encoder LED updating correctly. However, it will crash after a few short turns. This doesn’t happen through a Raspberry Pi MIDI Host/Router. This image:

19

awesome thanks for doing this troubleshooting! I’ll try your code out tomorrow at the studio and see if i get the same crashing issues. I’m on a mac, so no midi ox, we shall see if that makes any difference.

did the cc 61 work correctly through the Raspberry Pi also?

20

I didn’t test CC61 but I suspect it would work. I would only call it once when I plugged in my setup so I could sync values.

My code is just simple test code. Unsure if anything if written is problematic. It only seems to crash when Knot is the host.

I’m going to check with Ableton when I get home to see if sending MIDI from Ableton also crashes the module.

I wonder if there’s a way to generate crash reports in the module so that devs can see what’s going on.