Attempting to make a relative encoder, failing


#1

Hi All, I thought I'd have a go at creating an object that deals with relative rotary encoders, it doesn't work

I've got rotary encoders on my arturia minilab, for 2 of the relative types the values are greater or lesser than 64, either bipolar from 64, or 1/127, with acceleration it's a bit more involved than that but for the purposes of testing I can use <>64 for those 2 types. I am only getting 0 or 126 on disp i_3, it doesn't count. Am I doing something wrong?


#2

That would only work if your controller updates at around k-rate (3000/sec) , it's probably much slower than that.

You need to basically be doing something like 64 - X


#3

@thetechnobear I decided last night that this really wasn't the best way to handle relative values from rotary encoders.

I had a look at the midi/in/cc i object and created my own versions that deal with the 3 different relative encoder types on my arturia, the 3 types are all accelerated so they deal with 2 ranges of values in each direction for increment/decrement. the left hand value for inc/dec is the un-accelerated value you would expect for each type, so 63/65, 1/127, 15/17.

  1. 63-1/65-127

  2. 1-63/127-65

  3. 15-0/17-32

Now that I can decode relative data types we should be able to control pretty much anything with a rotary encoder, obviously I need to write the objects to cope but I envisage a rotary encoder object where you set a min and a max value, and a resolution for the data type you want to control, attach it to the object you want to control and start twisting :smile:

I'm not sure if a cc i style object is the right way to do this but I decided to make them anyway, they're very simple objects and the code can be adapted to suit.

I will post the objects later on once I've finished testing them.


#4

this is what I did with the Push :slight_smile:
the push uses something called... 2's complement encoding. I suspect this is what (2) is.

yes, there are various different relative encodings, in fact Ableton offers support for 8 different variations :wink:

Im rather surprised Arturia are using different encodings, Id have thought for one controller, one encoding is enough (the Push only uses 1)... with relative encoding it doesn't matter if a value is bipolar or unipolar, as you are sending changes.


#5

I tried to find what had been done with encoders in the push code but couldn't find anything immediately apparent, I appear to suck at searching the code and forums.

I believe they use different types of encoding simply because not all software solutions for rotary encoders are created equal, like you've said, ableton has got 8, presonus studio one has got a few (but they're not documented so you have to guess/reverse engineer their solution!!), traktor has got a few as well.

Now I've got the arturia covered, I'm going to look at what I need to do for my behringer and numark midi DJ controllers, tons of buttons, pots, faders and encoders, along with a bunch of midi addressable LEDs, this will give me enough controls for pretty much any synth/module/effect.


#6

@thetechnobear I'm getting a nagging feeling that creating objects to do this isn't the right way, it seems to me that it would be better to do it universally via the CC assignment in the gui?

I don't know java at all, but I think this function GenerateMidiCCCodeSub Is one of the functions I'd need to look at editing?

I also need to add a way for the user to choose the type of incoming CC data, Absolute, or XX relative types.


#7

I think a custom object is the right way. Doing it in GUI code complicates future efforts to implement live-midi-mapping.


#8

It shouldn't be anymore complicated than a switch/case and appropriate controls/logic but even that's beyond me at the moment as I'm not familiar enough with axoloti to attempt this :wink:

I would still like to attempt this for myself at some point in the future, I hear what you're saying @johannes so anything I attempt would be purely for my own satisfaction and not to challenge you :slight_smile:


#9

There are a few ways to do this kind of midi mapping....

the obvious ones are the UI mapping, and the midi/in/cc objects. the later you could create a custom variant off for relative encodes.. the former would as you noted, need an Axoloti UI release.

BUT there is another way worth considering, and that is using mod sources.. (and again you could create a variant). the nice thing about these is, they are kind of 'detached' a little from the patch.

I was thinking the other day, of perhaps creating a small mod source patch bay i could throw into each of my patches, they was on predefined CCs , so then in the patch all I do is then assign relevant controls to the mod source.

@johannes, we might want to add to the object editor a 'provides modulation source' checkbox, so we can have custom ones.... I also see a slight limitation here, in that a user might one to create have an object create multiple mod sources.


#10

The patchbay is an interesting idea @thetechnobear I was thinking along those lines myself, but hadn't really come up with much of a way to implement it other than making a specific object. What are modulation sources? I had a look at the mod source cc object but I'm not sure if I understand exactly what it does?

The ui feels like an intuitive place to be able to assign CC encoders, I'd also like to be able to assign note on and/or off for switches, toggles and radio buttons.

I do appreciate that it will add complexity but then again, adding anything to the mapping system will increase complexity but it will also end up enhancing what I believe is a very very powerful midi system, there is a lot of potential here.

I want to be able to plug in any of my midi gear and know that it will be easy to use, the beauty of the axoloti is that we can write the code for anything that is missing.

btw. I had a look at 2s complement but I couldn't see how to use it for a 7bit value, unless I add 128 to values > 64?

Lastly, I was wondering how the midi system is connected and whether it's possible to just intercept the incoming CC messages before it goes anywhere, manipulate the data and then inject it back into the internal system, that way it would be possible to assign CCs via the ui without actually having to change the ui code?


#11

Without reading this whole thread (sorry) here's a simple recipe for absolute->relative encoding:

input value -> sample/hold the value -> subtract the held value from the next input value -> divide this result by the absolute value of itself. you will get a signed 1 as a result (-1 or 1). cheers!