Hey everybody,

Sorry, for a lot of text. But the bold text at the bottom is my main question. The rest will help you to get a better understanding of my situation.

you helped me so much, with my last question here (the Faders are working dope now):
https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/25

I am doing a Steinberg Houston to Mackie Control emulation at the moment, to use my controller with other DAWs than Cubase/Nuendo. Will upload it to the internet community, when I am finished for the handful of people that maybe are also using this controller.

I made good progress:

I got the Faders and the normal knobs to work. And the display puts out information. But it is with bugs, because the LCD Screen of the Houston has 40 characters for one line and the Mackie Universal Pro has 56 Characters. So i did a list algorithm, which deletes spaces of the mackie message until the message fits on the 40 character line. Maybe there is a method wich will work better but this subject eats too much time for me at the moment and it works rough okay. One defenitely get's some helpful information on the screen from the DAW.

The Faders and Rotary Knobs and normal knobs are the most important of this controller I guess. The Faders are working fine as I mentioned above, but there is a problem with the rotary knobs, wich I can't handle alone and hope you can help me.

The problem is, that the Mackie Controller send simple clicks to the DAW. If you are turning a rotary knob, it sends out a number of midi messages:
If you turn it right, it sends midi messages wich contains the value 1 and if you turn it down it sends messages wich are containing the value 65.
"When the VPots are rotated rapidly, a message equal to the number of clicks is sent."

BUT the Houston controller instead is sending values like it's faders with 15 (MSB) and 128(LSB) values. AND it is updating the rotary limit by itself. So if I turn a rotary, it will update it's LEDs and stops sending midi messages when it reaches the maximum or minimum value. So, I did this patch as a momentary state:

Rotary Encoder Example.pd

The DAW sends 11 values for the Houston LEDs. 11 is max and 1 is min. This is good, I send this values to my houston controller and can update the rotary values and LEDs.
With this updated values from the DAW, I can force my rotary knobs, that they don't stop to send values, because they are set to the values, which the DAW sends, every time I turn a knob. With this method I got it to work to imitate a Mackie Rotary knob. Everytime the Houston Rotary value changes, it sends Mackie "midi click values" according to the amount of midi value changes of the houston.
BUT the problem is, that this is working only in one direction. Now my main question:

How can I make pure Data know, if I am turning my knob in the left direction or in the right direction? There is also the problem, which I mentioned above, that I set the momentary value everytime, I move the rotary, so that I get a unlimited amount of possible rotary move "clicks". Also the midi values which the houston sends arent perfect smooth. It works fine, but it isn't like that, that if you move a rotary in one direction, every value one by another is perfectly lower or higher.

I think I maybe need a algorythm, which looks if the values in a time period are getting higher or lower and then send out bangs on two seperate outlets. For example the left outlet for lower values and the right outlet for higher values. And it should also detect, if I move the rotary fast or slow. So a constant smoothing or clocked bang is also not an option. This is defenitely to complicated for me. I have no idea and what I tried didn't worked.

Would be super cool, if you could help me out again.

@Bangflip

Edit. you are trying to emulate a relative encoder with an absolute encoder, which will not work well, you will run out of knob, depending on the parameter you are editing and the knob movements you make, the knob could very well end up at min or max even though the parameter has not. You would probably be best off updating the knob value after every change, set to midvalue, detect change, determine if it is up or down, set back to mid value. Also make sure your controller can not be set to relative values for the encoders, many can and then all this will be unneeded.

@oid said:

@Bangflip

Edit. you are trying to emulate a relative encoder with an absolute encoder, which will not work well, you will run out of knob, depending on the parameter you are editing and the knob movements you make, the knob could very well end up at min or max even though the parameter has not. You would probably be best off updating the knob value after every change, set to midvalue, detect change, determine if it is up or down, set back to mid value. Also make sure your controller can not be set to relative values for the encoders, many can and then all this will be unneeded.

Thank you for your answer. Id did know moses already, it is very helpful. Unfortunately the Houston only is sending absolute values: "The 8 x Rotary-Encoders send MIDI ‘Controller’ MSB/LSB absolute position". There is no option to change that as far as I know. It is an 20 years old controller and the support was dropped years ago.

Yes exacly. I am updating the knob value after every change. But I struggle to get the the up, down detection.

@Bangflip Oh, no need for the [t f f] then, just set the argument of moses to that mid value, if your mid value is 64 than [moses 64]

Ahh, I think I know, what you would try to archieve. The problem is, that to values are also updated from the DAW. So the controller doesn't stay at the mid value. But you brought me to an idea. I have only 15 LED positions on the encoder. So I could find out the values and add or subtract them from the middle position before everything goes into moses. I will try that out now.

@Bangflip Can the DAW you are using be set to use absolute value encoders? That would make things easier, then you just need to have the DAW also tell pd if the relevant value has changed and things become much easier.

Yes, it is possible, if I set up a generic controller and do the mapping in the DAW. But I would like to also get display information like a Mackie Universal Pro. And so I am doing a Mackie Emulation. And this Mackie Universal Pro Controller Protocoll is supported by almost every DAW. I then just need to set it up one time.

@oid Your Idea roughly is working! Not thought, that the basic solution is sooo simple!

But anyways. I have a problem. It only works, if I slowly move my encoders. With fast movement moses sends bangs on both sides. It maybe has something to do with the rotary position update, everytime I move one, but I am not sure.

@Bangflip Put a [select (mid value)] on the outputs of moses and use the right outlet of the [select]s

I tried it. It still doesn't work, but I find out, that the problem bangs in the wrong direction occur, when the mid value changes, which the DAW is sending. But only with fast rotary movements.

@Bangflip Then you need to put a [print] on the output of [moses] to see exactly what is happening. This should also clue you in on how to get it to automatically deal with knob velocity and make greater changes for a faster knob turn. But that will be a trick since you are updating the knob value every change. It really would be simpler to use the generic option instead of the mackie standard. You should be able to update the display still, you will just have to use pd to do that instead of relying on the DAW.

Hey oid, yes. I will look, where the error could happen. But unfortunately the generic controller method is not an option for me. Because I am also interested in names like the VST Plugin list. In mackie mode I can for example scroll through my Plugin list and select and load my desired plugin into the effect chain. Also the parameters and value changes are sent from my DAW as SysEx midi data for the display. I think this isn't possible in the generic mode.

@Bangflip The [print] should explain things for you, make sure to also put one on the input to moses, this is an issue of the update you send and knob velocity. You should be able to make generic mode work just fine, you will just have pd as the intermediary for different data, data that does not change so much so you have less to update/modify.

WOW, I GOT IT per coincidence.

I found something out which you can't read in the manual or set up the normal way. The SysEx message below set's how the Rotarys behave. The number 15 is the range I guessed. What the other values are for, I am not sure. But then I tried out to write just three zeros in. The number before the 247 is a check digit or something like that in order to get the SysEx message to work I had to do [mod 128] of the numbers before. This I found out while working on the Display output.

And now, BAAAM. The Rotarys are relative now. Some kind of. They send only two numbers per level (1-15) and the rotarys only update with input from outside the controller. With your select and moses method it works now!