Knob sending multiple CC #'s of the same value

7 posts / 0 new
Last post
Jordankrug
Jordankrug's picture
Knob sending multiple CC #'s of the same value

Hello!  I am looking into a BCR2000 and the BCmanager software as a way to customize my MIDI rig, and I was wondering if certain things would be possible.  I would like, for example, to have a knob for my drum machines that would send out a series of CC messages with a value of 1 upon turning the knob to the right, and a value of 0 while turning to the left in order to mute parts of a drum machine.  In the example I am using I would like the knob to send approximately 12 different CC #'s sequentially in either direction.  From what I am reading this could potentially be possible using .tx commands and by setting the resolution of the encoder to essentially only be scrolling through a very small number of values.  I really have no idea if this is really possible, but I suppose programming buttons to mute different groups of drums would also work.  Having a hard time wrapping my brain around the use of custom outputs with this software, but it seems  very powerful and very promising if I can figure it out!  Any help would be greatly appreciated!

Jordankrug
Jordankrug's picture

Commenting to add that I have also been considering a BCF2000 as well, perhaps this would work better with the faders having actual physical endpoints?

 

Mark van den Berg
Mark van den Berg's picture

If I understand what you want correctly, it's very easy to achieve.
I've just tested the following encoder definition (since you mentioned ".tx", I don't have to explain that this is BCL smiley):

$encoder 1
  .showvalue on
  .mode 1dot/off
  .resolution 96 96 96 96
  .default 0
  .minmax 0 1
  .tx $B0 $00 val $B0 $01 val $B0 $02 val $B0 $03 val $B0 $04 val $B0 $05 val $B0 $06 val $B0 $07 val $B0 $08 val $B0 $09 val $B0 $0A val $B0 $0B val

When I turn this encoder slightly clockwise, three things happen: the bottom left LED in the encoder's ring goes on, the display briefly says "1", and the BCR outputs a sequence of 12 CC messages with value 1 (B0 00 01, B0 01 01 ... B0 0B 01).
Then when I turn the encoder back counter-clockwise, the bottom left LED goes off, the display briefly says "0", and the BCR outputs the corresponding 12 CC messages with value 0.
In the above definition, ".resolution 96 96 96 96" (equivalent to simply ".resolution 96") is in fact the default resolution for all encoders: 96 values per 360 degrees. In my experience, its responsiveness is ideal here: choosing a lower value only makes it more difficult to switch between the two modes.
However, one aspect of this definition is not ideal: when I keep turning clockwise, the BCR keeps outputting the exact same sequence of 12 CC messages (i.e. with value 1) at every next 1/96th of the full circle - this is simply a quirk of the BCR. This is probably not a problem for your drum machine; however, if you want, you could lower the resolution to something like 16 or 8: then you would have to turn a lot further to make the BCR fire another batch of 12 messages; but of couse this would also increase the rotation back to 0...!

So I think it's much better to use a button for this.
For instance:

$button 33
  .showvalue on
  .default 0
  .mode toggle
  .minmax 0 1
  .tx $B0 $00 val $B0 $01 val $B0 $02 val $B0 $03 val $B0 $04 val $B0 $05 val $B0 $06 val $B0 $07 val $B0 $08 val $B0 $09 val $B0 $0A val $B0 $0B val

When I press this button for the first time, its LED goes on, the display briefly says "on", and the BCR outputs the 12 CC messages with value 1.
When I press this button for the second time, its LED goes out, the display briefly says "off", and the BCR outputs the 12 CC messages with value 0.
So this is much cleaner. But of course it depends on how you want to organize the preset whether this is actually the best way: you might need the buttons for other things.

I have also been considering a BCF2000 as well, perhaps this would work better with the faders having actual physical endpoints?

I've tried this:

$fader 1
  .showvalue on
  .motor on
  .override move
  .keyoverride off
  .default 0
  .minmax 0 1
  .tx $B0 $00 val $B0 $01 val $B0 $02 val $B0 $03 val $B0 $04 val $B0 $05 val $B0 $06 val $B0 $07 val $B0 $08 val $B0 $09 val $B0 $0A val $B0 $0B val

But I didn't feel very comfortable with this: the lower half of the fader's range means "0" and the upper half "1", so the effective switch area is around the mid-point. A fader has no LEDs, so the only "permanent" clue to its current state is the position of the fader itself, which is not ideal, particularly in a dark place.

Also note that a BCF is also substantially heavier than a BCR (due to the motors of the faders).
And at least originally the BCF tended to be about 50% more expensive than the BCR - I'm not familiar with their current prices though...

Anyway, my advice would be to go for a BCR rather than a BCF, and to use a button for this type of definition.
Unless of course the BCF's 8 faders are more useful to you than the BCR's 24 extra encoders.

Hope this helps,
   Mark.

Jordankrug
Jordankrug's picture

Thank you so much, Mark!  You have no idea how much I appreciate such a concise and thought out response!  I have a BCR on the way so I can test this out hopefully very soon.  I am currently using two drum machines which use the same type of controls for mutes, is it possible to add MIDI channel arguments as well if I were to decide to try and combine both knobs into one?  Thank you so much again for everything!

Jordankrug
Jordankrug's picture

I forgot to ask in my reply if it is possible to have the knob send the messages incrementally, meaning as the knob is turned farther to the right, more of the "1" messages are sent, and the opposite in the other direction?   Sorry about all the questions!

Mark van den Berg
Mark van den Berg's picture

if it is possible to have the knob send the messages incrementally, meaning as the knob is turned farther to the right, more of the "1" messages are sent, and the opposite in the other direction?

Maybe I'm misunderstanding your intention, but isn't this the standard behavior by encoders that I described as a potential drawback in my first post? That is: the behavior whereby the encoder sends the batch of messages containing the maximum value (as defined by the Value 2 parameter) again whenever the user rotates to a position where a higher (but unreachable) value would be (as defined by the Resolution parameters)..

Mark van den Berg
Mark van den Berg's picture

is it possible to add MIDI channel arguments as well if I were to decide to try and combine both knobs into one?

In any channel message, the channel c (1-16) is represented by the low nibble of the status byte, so for instance $Bn for Control Change messages, where n = c - 1.

So if your drum machines are on different channels (say: 1 and 2), the ".tx" statement must contain separate messages for both these channels. In other words, you'll have to copy-paste all message definitions and change the low nibbles of the status bytes to the appropriate channel.
For instance, in the example I gave in my previous post, you'll need not just "$B0 $00 val", but also "$B1 $00 val" etc.
(Unless I'm missing something, you can't avoid this "dumb" duplication. Unfortunately BCL doesn't allow you to do something like "for n = 0 to 1 do send ($Bn $00 val)", as you could in any imperative programming language.)

One important caveat: the ".tx" definition(s) of each button/encoder/fader are limited to 127 bytes, where each ".tx" statement itself and each "val" takes up two bytes. (For further details, see section 14.6.6 of BC MIDI Implementation.pdf.)
So a ".tx" statement with 2 * 12 Control Change messages, each with a "val" identifier, takes up 2 + 2 * 12 * (1 + 1 + 2) = 98 bytes; so this is possible, but is getting close to the limit.