HD Midi

[S0lo]

value = (CC_19_VALUE << 7) + CC_51_VALUE;

It's another way to get 14-bit precision in midi and the LSB/MSB pair is always LSB = 1-32
MSB = LSB + 32

And as you can see 19 + 31 = 51.

I guess you meant 19+32=51.

I actually thought this is the only way it's done.

[bmrzycki]

value = (CC_19_VALUE << 7) + CC_51_VALUE;

It's another way to get 14-bit precision in midi and the LSB/MSB pair is always LSB = 1-32
MSB = LSB + 32

And as you can see 19 + 31 = 51.

I guess you meant 19+32=51.

I actually thought this is the only way it's done.

Yes, sorry I meant 32. And as for the way it's done -- you're correct for 14-bit precision CC. RPN/NRPN is a slightly different bytestream. It allows MIDI to use just 4 CC values to control 2^14 * 2 parameters. You're essentially muxing by selecting a variable first and then using the other 2 CCs to set the 14-bit value.

[justin3am]

Ah, I wasn't aware that some manufacturers we doing 14bit values this way.

[AdmiralQuality]

Wow, that's going to complicate things. (The great thing about standards is there's so many to choose from!)

And yes, the reason to want a plug-in to output MIDI is so you can make MIDI processors as well as audio to MIDI converters.

And my point about inc/dec is not all continuous controllers have an obvious minimum increment. In a 32 bit floating point value there are, what, 2 ^ 24 possible values between 0.0 and 1.0? 16777216 steps! Over 16 million! That's a lot of presses of the inc button!

[bmrzycki]

Ah, I wasn't aware that some manufacturers we doing 14bit values this way.

Yeah, it's definitely a hack as it halves the number of usable CC messages at once. And if you're curious the MSB CC # is treated as the actual CC number. So in S0lo's bytestream above it'd be treated as 14-bit precision on CC 19.

[mkdr]

value = (CC_19_VALUE << 7) + CC_51_VALUE;

It's another way to get 14-bit precision in midi and the LSB/MSB pair is always LSB = 1-32
MSB = LSB + 32

And as you can see 19 + 31 = 51.

I guess you meant 19+32=51.

I actually thought this is the only way it's done.

Yes, sorry I meant 32. And as for the way it's done -- you're correct for 14-bit precision CC. RPN/NRPN is a slightly different bytestream. It allows MIDI to use just 4 CC values to control 2^14 * 2 parameters. You're essentially muxing by selecting a variable first and then using the other 2 CCs to set the 14-bit value.

And if you need to talk to an expert on the subject, that's me. I've done vst-editors for hardware synths that work by sending CC, Sysex and NRPN messages to enable full automation of all the synths parameters.

Btw. i recall you can send the NRPN address just once and then all the parameter values as 2 CC MSB/LSB pairs. None of the hardware i've work with does so though, so neither did i. It's safer to just send the 4 values at once. No mix-ups between parameters and way easier to implement.

Thanks, but Won't work, Thats almost exactly like the lag/delay. It can't stop in the middle of two values, unless you MANUALLY edit the recorded and faded data, which is obviously not for a live performance.

No it's not like the lag/delay, as there is no lag nor delay. Sure it can't stop in the middle of two values, but this was a solution for you to get smooth controller data with a 7bit controller. If you need more "levels", look at control surfaces like Mackie, or synth controllers like Automap.
And why do you even need to stop at the middle of two values? Is there a real reason or do you just like to argue? The reason there usually is just 128 steps on values is because more is so seldom needed. 128 is luxury compared to vintage analog eq's that snap to frequencies and decibels etc. You'd prob slice your wrists with them right?

[bmrzycki]

And my point about inc/dec is not all continuous controllers have an obvious minimum increment. In a 32 bit floating point value there are, what, 2 ^ 24 possible values between 0.0 and 1.0? 16777216 steps! Over 16 million! That's a lot of presses of the inc button!

Yep, inc/dec is weird as there are many different continuous controller stream types. I remember playing with my BCR2000 several years ago. I ended up selling it when I got a Novation SL Zero (my mistake, the encoders on the BCR feel nicer with no detents).

The CC bytestream I liked using the most with them worked like this (can't remember the mode name). Let's say you have a parameter, Cutoff and is set to value N where 0 <= N < 2^24. I have an endless rotary encoder setup to CC 20 and it is mapped to parameter Cutoff.

1. slow clockwise sweeps generated CC 20 values from 65 to 70
2. normal clockwise sweeps generated CC 20 values from 71 to 100
3. fast clockwise sweeps generated CC 20 values from 101 to 127

The same thing happened for counter clockwise just that the values were less than 64, so slow-> 63 to 50, normal->49-30, fast->29-0

It was up to the software to take the incoming CC message and do the following:

1. determine if it is a positive or negative sweep as well as the magnitude of the sweep.
2. based on the the size of the value it was mapped to (Cutoff of 2^24 bits in this case) calculate a suitable positive or negative delta to the current cutoff
3. adjust the cutoff by N - delta or N + delta and optionally send some sort of midi feedback indicating the change to listening devices or the host.

I gave up on this in practice because most controllers have horrible acceleration curves. You either move it way too slow or you end up compensating by spinning faster and completely overshoot the intended value.

I would gladly pay $200-$300 for a single, high-quality encoder with a mechanism to quickly switch between parameters. Most of the stuff I've tried falls laughably short as it tries to to everything.

[justin3am]

And my point about inc/dec is not all continuous controllers have an obvious minimum increment. In a 32 bit floating point value there are, what, 2 ^ 24 possible values between 0.0 and 1.0? 16777216 steps! Over 16 million! That's a lot of presses of the inc button!

I'm not talking about buttons. Some controllers allow you to set encoders to send inc/dec messages (they transmit a message for each step of resolution they have, usually 24-32 steps per revolution) rather than absolute values. That's why controllers that can send inc/dec messages have acceleration curves.

This is how some controllers communicate with DAW control surface protocols. They don't transmit absolute values, they just tell a given parameter to increment or decrement, then they rely on the DAW to send feedback to the controller in the form of sysex text strings.

[S0lo]

but this was a solution for you to get smooth controller data with a 7bit controller. If you need more "levels", look at control surfaces like Mackie, or synth controllers like Automap.

Yup, thats exactly what I need. More levels instantly under my hand, live.

All due respect

[AdmiralQuality]

And my point about inc/dec is not all continuous controllers have an obvious minimum increment. In a 32 bit floating point value there are, what, 2 ^ 24 possible values between 0.0 and 1.0? 16777216 steps! Over 16 million! That's a lot of presses of the inc button!

I'm not talking about buttons. Some controllers allow you to set encoders to send inc/dec messages (they transmit a message for each step of resolution they have, usually 24-32 steps per revolution) rather than absolute values. That's why controllers that can send inc/dec messages have acceleration curves.

This is how some controllers communicate with DAW control surface protocols. They don't transmit absolute values, they just tell a given parameter to increment or decrement, then they rely on the DAW to send feedback to the controller in the form of sysex text strings.

Yeah. Yuck.

[Nantonos]

I would gladly pay $200-$300 for a single, high-quality encoder with a mechanism to quickly switch between parameters. Most of the stuff I've tried falls laughably short as it tries to to everything.

How would you want it to work? Acceleration based on turning speed? Or a fine/coarse knob pair? Or concentric knobs? Weighted knobs?

Concentric LED feedback (coarse) or a numerical display of the value, or ...

Would you also want control over the acceleration curves?

How many parameters do you want to switch between? For a small number, assignable buttons would work. For a larger number, I guess its down to menus; scrolling through a large number of options is slow, though.

Any would you want NRPN, RPN, MSB/LSB or all three?

[justin3am]

Hey Nantonos,

Do you know anything about Alesis having custom 360 degree potentiometers made to get the best of pots and encoders? I've been trying to find more info about this but I can't even figure out if they actually exist.

[Nantonos]

Hey Nantonos,

Do you know anything about Alesis having custom 360 degree potentiometers made to get the best of pots and encoders? I've been trying to find more info about this but I can't even figure out if they actually exist.

Interesting. Endless (360 degree) encoders which send some number of pulses per revolution. Problem is the number of pulses is typically low, 24 or 32. These are fine for higher speed applications like measuring the turn speed of a motor. But rather coarse for audio control applications. I have seen 128 and 256 per turn encoders from Honeywell and Bourns, though they are expensive. But even then, you need to turn and turn to get a wide range of output values. Also, you need two channels with a phase offset so you can also determine the direction of rotation.

A pulley gearing system might help, to increase the rotation speed of the encoder relative to the control knob.

Potentiometers give continuous values, and can have greater sensitivity by using multiturn ones (I have seen 10 turn, 15-turn ones). But those have hard end stops.

But if they really combined them ... say 16 pulses per turn and 16 linear pot segments between the pulses. So you get analog resolution between the pulses, count pulses to get the coarse resolution, and can multiturn. Once a pulse happens you count it and the analog slider probably hits an earth point momentarily then goes onto the next resistive segment.

Plus, you might only need one channel of pulses because the analog value would show which way you are turning.

No, I hadn't heard of them, but thanks for alerting me to the concept.

[justin3am]

But if they really combined them ... say 16 pulses per turn and 16 linear pot segments between the pulses. So you get analog resolution between the pulses, count pulses to get the coarse resolution, and can multiturn. Once a pulse happens you count it and the analog slider probably hits an earth point momentarily then goes onto the next resistive segment.

Plus, you might only need one channel of pulses because the analog value would show which way you are turning.

No, I hadn't heard of them, but thanks for alerting me to the concept.

What I've heard from a former Alesis employee is that each endless pot has two resistive elements that work in opposing directions. So as you turn the pot in either direction you are increasing the resistance for one element and reducing resistance for the other. I think the pulses are derived via some quantizing method in firmware. Supposedly, the Alesis Micron and Akai MPK keyboards use this kind of endless pot. I haven't had a chance to completely disassemble my MPK, but I can see that each rotary control element has 4 leads!

Kinda interesting. Still, I can't find any information about these parts, so I don't know if they are only being custom made for Alesis/Akai/Numark or what.

[bmrzycki]

I would gladly pay $200-$300 for a single, high-quality encoder with a mechanism to quickly switch between parameters. Most of the stuff I've tried falls laughably short as it tries to to everything.

How would you want it to work? Acceleration based on turning speed? Or a fine/coarse knob pair? Or concentric knobs? Weighted knobs?

Concentric LED feedback (coarse) or a numerical display of the value, or ...

Would you also want control over the acceleration curves?

How many parameters do you want to switch between? For a small number, assignable buttons would work. For a larger number, I guess its down to menus; scrolling through a large number of options is slow, though.

Any would you want NRPN, RPN, MSB/LSB or all three?

All good questions. What I'd really like is a high-quality encoder with a large knob. Something the size of a jog wheel or a hockey puck. I could then connect its output to the GPIO pins on a device like the Raspberry Pi. Then I'd use Linux (with RTOS extensions) to generate the appropriate midi messages. I'd also like to use an android app or windows/mac app to send commands to the RPi over bluetooth or WiFi to change how the messages are sent. It also allows me to decide if the messages are CC, MSB/LSB CC, Pitchbend, Aftertouch, RPN,NRPN, (and if I can ever figure it out) Mousewheel up and down.

I know that's pretty much unmarketable but that'd be my ideal setup. It'd allow for a clean, touchable interface on the android and a good tactile knob that can dynamically change tasks. A Nexus 7 + RPi is about $250 and all that's left is a good knob.