My code in the EN16 is directly setting val for elements, but is not pointing to elements in other modules, just elements from 0 to 15.

Just tested connecting the pair via the BU16 socket and in that case they velocity is recorded correctly, so seems to be only when connecting both via the EN16.

If there is any way for me to do a dump of the config of both units, let me know, happy to pass it so you can test with the same software running.

If so, there you said you had to wait a bit more and the BU16 connected after that on that side as well. IF this issue is solved, please get back to us here as well, thank you.

What I was thinking is that the order of the modules could maybe cause this, but it’s unlikely. If you have the time, testing the setup where the BU16 is the one directly plugged in could be useful.

Not sure how your custom code could cause this, though I have no idea what your configuration is.

More than reading comprehension it might be writer skills, I should have structured the post better

They are side by side, USB connected to the EN16. BU16 to the right of the EN16.

I’ve been thinking if any of my code in the EN16 might be affecting those exact buttons somehow. Is weird because if they were affected by index all the buttons on the same row should experience the same behavior.

I’ll keep thinking…

Any advance debugging technique that I could use to try to trace the chain of execution/events triggered by the button? it would be awesome if there was any way of tracing the execution somehow.

I will attempt to replicate this in the office tomorrow.

I’ve noticed some erratic behavior when I my EN16 and BU16 attached together.

When used individually the velocity tracking of the BU16 is spotless, but as soon as I attach the EN16 some buttons stop reading high velocity values (those specific buttons only record velocity above 0 when touched very lightly).

This buggy behavior disappears as soon as the BU is used separately.

I was close to open a ticket for the BU16 thinking that the affected keys were defective…but as the module performs perfectly bu itself I assume that the problem is not hardware related and more software related.

How could I debug or solve this issue? What does motivate this behavior?

The other interesting thing is that only some buttons are affected, I can see that button 4 and 8 are the ones affected, the rest behave as expected when attached to the EN16.

Velocities with the module by itself.

Velocities with the BU16 and EN16 together. The first “0” are triggered by high velocity pushes.

This behavior has been recorder with the units plugged to a PC via USB 3.0.
Same behavior is detected when using external gear like the 1010 Blackbox via the dedicated device USB.

Thanks in advance.
Cheers.

I purchased and just received a BU16 and an EF4 module, I’m just starting to learn it, I was connecting these to my DAW (Reaper) and it’s generally working.

But I found that one side of the BU16 seems to not be working. When I have the EF4 attached via USB-C and try to mate the BU16 to it, all but one side of the BU16 connects. I’ve tested this visually using the software too.

I haven’t done much testing so can’t describe much more yet, but I’ll test more tonight and post a follow-up. But I’m curious what’s the support policy/procedure on this? I just received and opened the boxes for these yesterday, never used.

Thank you

What want to do is use a button to select a feature and then use the dial to scroll up/down through whatever I’ve selected.

I have programmed the dial with NRPN so when i turn the dial i can see output in the midi monitor but the dial is not working properly.

Rotating the dial the values go from 1 to 0 only in one direction - what I’m expecting to see is rotate one way and the output is 1 and rotate the other way and the output is 0 which would equate to up or down when i scroll on the hardware EVM module.

What am I doing wrong ? appreciate any help.

Anyway, thank you very much for sharing these cool cases. I will definitely use them, although I would feel a bit safer with a case that protects the entire device.

Edit: I downgraded again and the issue still persists. Not currently sure what is even going on, but I can see in MIDI monitor that some buttons send out on all 32 channels instead of the one they’re assigned to.

Maybe just a question before I start trying to deal with this: Are configs made before the breaking changes generally expected to even work still? I do not see myself dealing with recreating my entire config again just to get it working like it was before. I also can not just use the old Grid-Editor anymore because the UI is not readable anymore on my current OS.

Is there something like a migration guide or anything?

With decksavers I just use a strap to hold them in place and pack the device.

I might think on a 2 piece design that encloses the units but that might require a bit more work.

BTW I transported my grid controllers last week to a jam using the double unit in a backpack (together with other gear) and the worked very well.

Also, a version with a bottom plate might be useful for people who often transport their devices, sometimes in dusty environments. It would help protect the bottom of the device and keep the inside of the case a bit more sealed.

Ill add a version with more prominent tabs.

Glad they work for you (despite the tabs).

However, the devices do come out a bit too easily, especially with the single case. The case itself seems to have the correct tolerances, but the retention tabs might be slightly too short to properly secure them.

what I am looking to do is have it turn endlessly to be able to scratch back and forth. If I have the interaction mode of the mapping set to relative (as it is in the downloaded mapping) it does that but only within a very narrow range. If I have the interaction mode set to direct, it does move endlessly but turning the knob in either direction only ever moves it forward through the track.

any pointers as to what I might be doing wrong? This is on macOS with traktor pro 4

I’ll add some more controls to act when rotating while pressing to some knobs like LFO wave shape and multiplier.

WIP grid EN16 control page for elektron DN.

I wanted to provide an extra layer of protection given that the case of the unit is plastic, but want to explore a leaner design. I’ll keep you posted.

I corrected the model yesterday, will update the one in the shared folder. I’ll let you know when I do it.

8191.5 didn’t get assigned to the encoder as it is not an integer.

Is there any way of enabling type error throws in the grid editor? So this kind of issue doesn’t happen silently?

Cheers.

https://drive.google.com/drive/folders/1zdwrJY6wQIqSHes3y2_QkWgtThkeowKz?usp=sharing

I shared the single one and the double one.

If I have a function receiving a self in System, and that function is executed in an encoder and access a self variable from another encoder…would that be a variable scope issue?

Curiously the function can access with no-issue other entities in the encoder like the encoder value, but not the self variable stores in setup.

Still trying to wrap my mind around how things are scoped.

Do you guys have a system architecture diagram or several? Showing how the elements inter-connect, depend and when they get executed by default?

I think that a dependency/scope graph and a flowchart with all events would help.

Model is an iteration over another model I saw online but has wrong dimensions the one I found online is too tight and if you fit the controller in is veeery hard to take it out.

I’m trying to manage a 2 layer system with default preset values for some of the knobs and I’m finding a strange behavior in one of my functions.

Each knob have some self variables called val1 val2 that serve as storage cache for the two layers.

I have two functions in system setup that I reuse extensively. They are as follows:

function UpdateValuesPress(self)
  local base = self:element_index()
  for i = base + 4, base + 12, 4 do
    print("e" .. i .. " - " .. "v2: " .. tostring(element[i].val2))
    element[i].val1 = element[i]:encoder_value()
    if element[i].val2 ~= nil then
      element[i]:encoder_value(element[i].val2)
      print(element[i]:encoder_value())
    end
  end
end
function UpdateValuesRelease(self)
  local base = self:element_index()
  for i = base + 4, base + 12, 4 do
    element[i].val2 = element[i]:encoder_value()
    if element[i].val1 ~= nil then
      element[i]:encoder_value(element[i].val1)
    end
  end
end

The weird behavior is at this chunk in UpdateValuesPress:

if element[i].val2 ~= nil then
      element[i]:encoder_value(element[i].val2)
      print(element[i]:encoder_value())

Even though I’m setting val2 with a preset value to be used at setup of the encoder, it seems that “element[i]:encoder_value(element[i].val2)” is not executed or effective on the first time that I press the button to change layers, only when val2 is stored on the second layer when the encoder is moved and after release.

For some reason even though it is set in the setup val2 seems to be zero the first time the function runs.

Capture of val2 and encoder value after 4 pushes on the encoder controlling the layer switch. (yes val2 for e4 should be nil at start)

The curious think is that as soon as I rotate the encoder in the controller layer that is stored in val2, val2 gets the value of the corresponding encoder, and when switching back and forth the encoder is correctly updated with the value stored in val2.

It seems that only the initial state of val2 set in the encoder setup is ignored.

Does anyone know what could I be missing?

I hope that I’m descriptive enough.

Profile shared here: grid-editor://?config-link=EBPm9mLpyle6QVLi3ljj

Thanks in advance.

Update…disregard the PR, it brings some undesired side effects in other unrelated components. I’ll try to find a solution.