MIDI parameter feedback objects

#1

Hey.

I made two objects for integrating Axoloti and the Behringer BCF2000 controller.

The BCF has flying faders and illuminated knobs and buttons that you can control with MIDI parameter feedback. Basically that just means sending the same CC that's assigned to a control back to it. If your fader sends CC #20, send CC #20 back to it and it jumps to the value you sent. You can control the LEDs in the buttons and around the encoders in the same way. I think a lot of controllers do this now but I only have the BCF.

There are two objects:

1) MIDI radio buttons

This object has four attributes. You select a MIDI channel and an output port for providing feedback (this is USB Host port 1 if you connect via USB). You then select a minimum and maximum MIDI CC number. The idea is that you assign a group of buttons to consecutive CCs, so four buttons will be e.g. 30, 31, 32, 33. The object keeps track of which one was last pressed, and outputs the number relative to zero - so if you're using CCs 30-33 and the last one pressed was 32, you get a 2 at the output.

The select input, when low, disables writing to the internal register for this particular instance. However, the most recently stored value is always present at the output. A rising edge on the select input outputs a 0 for the unselected CCs and 127 for the selected one, allowing you to restore the state saved in this instance.

By decoding the output of one set of buttons set to one range of controllers and using it to select one of a number of other instances set to the another range of controllers, you can get something like bank/page switching:

radiobuttons.png570x537 13.9 KB

The buttons that send CC 30-33 select four "pages" which store the selections made with the buttons that send CC 34-37.

2) Octal CC register

This stores incoming CC values for eight consecutive CCs starting from the one set by the attribute 'min'.

Like the other object, values are only written when the select input is high, and a rising edge restores the state, allowing you to make multiple banks of physical controls. This works with faders, button LEDs, and the LED rings around the encoders on the BCF. Just programme the controller to send eight consecutive CCs.

Again, the latched values are always present on the output, the select input only controls which instance to write to when CCs in the right range come in.

I'm going to try to make a few actual things with these to see if more/less features are needed, and then add them to the library with Git and that. Comments are welcome in this thread.

midi_radio_buttons.axo (2.8 KB)
octal_cc_register.axo (3.1 KB)

Anyone use a touchscreen yet? Multi-touch? What Os?
#2

Ive moved this post,as the community library has a very specific format/aim... (see sticky in category)

#3

I made a video about these. (Mostly because I wanted to try making a video.)

#4

Works great! I did set this up but using Lemur and BCF template.
Keep up patching :wink: will be nice to see it in Community Contrib.

#5

Eh, users! That's ace.

What this really needs is storing state to SD card and I'm thinking about ways to do that.

#6

Hmm, I don't get it. If the BCF is setting #20, why doesn't it set it's own LED's to 20? Or is this used to confirm that the destination really did get the message AND switch to 20?

Also on state. What is the intention here? Some kind of preset switching?

(Interested to know if I need this in my build or not :slight_smile:

#7

The idea is just the paging. That you can store a set of values, move to a different set of values, and then come back and see those values you set before. So the object has to resend the values when it's reactivated.

The idea is not preset switching, but to be able to control more parameters than you have physical controls. Think of a synth with different menu pages and a couple of encoders beneath a display.

#8

Got it. The BCF itself can't store the state so the Axo has to.

#9

I wish you had made this for a Mackie C4 controller. I have one that has been collecting dust and a Axo board may even fit inside. sigh.

#10

hey @rvense , seems like we are working in the same direction...I also did some objects aimed at midi-feedback...
and as far as can see from looking at your code,some of them are functionally quite similar..
(I think I have to document what I'm doing a bit more often because just a week ago, @TheSlowGrowth also released some stuff that I had already done some time before.. )

anyway,they are under rbrt/midi/in and rbrt/midi/out ....
I'll add help files as soon as I get the time and post here again...

#11

I haven't actually looked at this at all since I posted it, you're welcome to nick any ideas or code but if you come up with something that does the same, these should be considered deprecated since I'm unlikely to work on it again at least in the near term.

One thing I really wanted to do was objects that persisted state across restarts, but I found that hard to implement when I last tried.

#12

I don't know the C4, but it's just MIDI so it might work. There's nothing BCF specific here.

#13

...guess I already did so some time ago :wink: but that doesn't really matter

...try with writing the states to a table, saving the table to SD-card and auto-load that table on restart
check out rbrt/midi/in/table store
and rbrt/midi/out/table send cc
...I guess they could work in a scenario like this

#14

Oh yeah, I think I remember what the issue is - I didn't want a table per object for some reason (I think there was a reason!). So the MIDI objects were connected to one table object which would allocate slots in the table without the MIDI objects knowing.

#15

I remember a very old MAX implementation done by NOTAM years ago but it is no longer around. The C4 has all those LCD strips above the 24 encoders so that adds a lot to the ergonomics. It does just spit out MIDI but writing to the LCD strips is the tricky bit.