EN16 encoders with variable ranges

I’m on a quest to configure my EN16 in way that lets me change the range on the fly. I’m using it with TouchDesigner.

In essence, i want to be able to configure the value of turning the encoder: I imagine i would have great use for a lookup that scales the change based on the velocity of the encoder turn. Like, 1 tick is +/- 1, a swift turn is +/- 10.

As I use TD, I’ve got a wide array of options available for processing values from the EN16, but I would like as much of it to be done in-hardware. If I could, as a start, get stable inputs from EN16 that tells me how many “ticks” it has made in any direction, I can make the ranges however I want in TD.

My approach thus far:
I’ve been plucking away at the BinOffset encoder mode. As I read the values from it, I can see that I get values above or below 64, depending on the direction of the turn. Great!
But, I haven’t found a way to check when I get a MIDI value, I can only check if the latest value has differed from a previous value. So, if I turn the knob clockwise, I make values of 65, 65, 65, 65… and TD only reads that as “the latest value is still 65, nothing has happened”.
I tried sending the self:encoder_timeelelapsed value out as a seperate MIDI message, so that I could check for differences in that, in parallel to the actual values of the encoder. But it seems a bit hacky…
I also tried using the Turn Left block, sending out a NoteOn followed by a NoteOff, but that doesnt really seem to send anything.

How should I approach this?

Heyas! How are you making out with this? Have you made any progress?

Just reading over things to get a sense of what you’re trying to do and seeing if there’s a way forward that makes sense for your use case.

Yeah, this is the progress so far:

init:
Encoder Mode BinOffset

encoder:
sends 1 midi message with ch, 176, cc, val as per default for the controller
immediately following that midi message comes a midi message with ch, 176, cc, 64 to tell my software to “reset”

This means that it outputs something like:
65 - tick clockwise
64 - reset
65 - tick clockwise
64 - reset
63 - tick counterclockwise
64 - reset

Then it came to reading that shit correctly. I’ve just got a reliable signal coming through in TD; it required me using a MIDI In DAT and writing some python, as I couldn’t muster a simple and functioning CHOP network.
I’ll post the .tox when it’s good and ready.

1 Like

Nice :slight_smile: Happy you’ve got some forward momentum here. I don’t use TD but was curious about setting things up to do the ‘heavy lifting’ on the Grid side of things.

Is TD only wired to work with MIDI? I’m assuming that using a ‘MIDI In’ DAT is a module or object that interprets MIDI and you’re doing that heavy lifting there and in your Python script.

I’m wondering if you could still do the heavy lifting Grid-side. Are you needing each left turn to send a different value so that TD knows the value is changing? As I read it, that was the hang up when you originally posted. And, that hangup was because of using Relative BinOffset. You’ve already discovered the encoder_value() returns 63 on left turn and 65 on right. If you’re wanting your directional turns to also send a mutable value each turn, that should be easy enough to do. I have some thoughts but I have to step out for a couple of hours. Just curious about what you would want each turn to do i.e left turn increments a value and sends and right turn increments another, separate value and sends it.

TouchDesigner works with many data types, but there’s a few different approaches on how to access the data from a MIDI input.
Basically I could use their value-processing nodes (CHOPs) or I could use their scripts-and-dataset-nodes (DATs). The problem with using CHOPs, I think, lies within me not fully understanding how to make the values read whenever a new messaged arrived. I could only really access the latest value in a MIDI CHOP, and not read when it came. Thats’ why I opted to make a reset value come right after, sort of like a serial stop bit.

But with the MIDI DAT, a small script can run each time a new message arrives, meaning I can run an if/else statement that raises or lowers a variable depending on what the incoming MIDI value is. Now that I think about it, I don’t need the 64 reset anymore…

I also considered doing all of this processing within Grid. But I have no experience setting up a MIDI Rx system on Grid, so I thought that would be even more tedious than figuring out to how to read and process the values in TD.

My wishes, in essence:
I want a variable value X to control whatever in TD.
Left turn should decrease X by Y amount, for each tick.
Right turn should increase X by Y amount, for each tick.
I want to clamp X between a variable floor and ceiling.
I want to be able to edit Y, floor and ceiling on the go, from an interface in TD.
But I might also want to just use a left/right tick to just pulse two buttons in TD. Or I might not want to clamp, but rather loop X around two thresholds…

What I’m building right now is a companion interface for each of the modules I own, inside TouchDesigner. I’m sort of doing all that work now, in order to not re-do MIDI networks whenever I start a new project. So I’m going for maximum flexibility, as it’s hard for me to predict exactly what kind of values I need.

This was the part that I was thinking could be done on Grid. So your DAT is only processing values being sent from Grid. I was just trying to work something out before I left today.

I haven’t used the MIDI Rx on Grid yet but it’s pretty straightforward from what I’ve been reading. On the Editor, you can change the drop down on the ‘Configuration’ pane to 'Element 16 (System) to expose the ‘midi rx’ tab:

From there, it’s about mapping incoming values to certain elements. I did poke briefly with it but I was getting some MIDI feedback; turning an encoder updated the value on my hardware but the hardware, in turn, was sending those values back and causing issues.

While I didn’t pursue it further, I thought about checking the encoder_elapsed_time() value so I could ignore incoming messages if an element had just been interacted with.

Doable. Either through MIDI or keyboard output (or even mouse and gamepad output).

Doable. You have access to all of LUA’s library in the editor. You’re not constrained to action blocks or system functions as defined by Intech.

Doable. Depending on if you’re referencing the value generated by an element or not. All elements have some function for setting min and max values. If X is a declared value not generated by an element, you can use LUA functions to constrain output.

I would say doable with using ‘midi rx’. I need to do some setup on my end to get a better understanding. I would like to be able to speak with more authority in this area.

Doable using MIDI or even sending keystrokes if that is a better approach.

Doable I would imagine. With access to all of LUAs library, there’s definitely a way to achieve this.

Time consuming while it might be, you could create and save templates in the Editor. This could be an entire page OR even a single element. The Cloud save feature means you can access this from any system that you login to.