MIDIbox NG Concept

[TK.]

So it's possible to press the button, twiddle a knob on your synth, and have it automap to _one_ encoder? (I think I'm in love if this is true)

So you'd need n buttons, where n is the number of encoders you want to program this way ?

Wouldn't it be easier to make the button go into "automap to next "twiddled" knob mode"?

Or am I completely mistaken ? =/

This is called "MIDI Learn" mode in the MIDIbox NG Spec

I haven't elaborated what it exactly means, since older MIDIbox users already know this feature from the PIC based MIDIboxes :)

But: in distance to MIDIbox64, MIDI learn will also work for NRPN and SysEx events! :)

This might sound a bit strange but would it be possible to also include the following scenario:

Instead of handling a set of real, physical encoders and buttons connected to the DIN port, LED rings connected to the DOUT port, and a real LCD connected to the Core board - would it be possible to replace these by virtual devices that are connected to a MIDI in/out port? So, on top of the "MIDI output config file" that we have now, also include the possibility of a "MIDI input config file" in which we define what MIDI message mimics the left- and right-turn of an encoder or the push/release of a button?

In such a scenario, the MB NG would act as an interpreter. It would allow to use MIDIbox .ngc files with third party controllers like the Mackie/Logic range of controllers (specifically the C4) or the Behringer ones, and with a relatively low cost - only the core board would be required to give new life to those.

Actually "EVENT_xxx" already handles "virtual" controllers, which are mapped to hardware separately.

Currently you can't see this in my configuration file (aside from the encoder and LED matrix definitions) since I haven't completed the implementation of this part yet, and instead hard-defined HW assignments to get a starting point for development of the event handling.

However, your usecase will be configured on a slightly different way which I will demonstrate later today (once the EVENT_SENDER and "output" parameter has been added) :)

In general I totally agree with you, that MBNG could also be used as a "bridge" between stupid HW controllers and other devices.

It could also be used as an "intelligent USB-MIDI interface" with MBHP_CORE_LPC17 only - oh man, there are so many usecases ;)

Best Regards, Thorsten.

[TK.]

So, this shows how it will work.

Let's start from the beginning - how events can be chained.

So, let's assume we've a button which sends/receives a NoteOn:

EVENT_BUTTON id=  1  type=NoteOn chn=1 key=36  range=  0:127 ports=1000100000001000  lcd_pos=1:1:1 label="Button%3i:   %e"

[/code]




and you want to link it to a LED function.

Means: the LED should turn on/off when you are pressing/depressing the button.

And it should turn on/off when the button receives a Note On event (which is sometimes necessary as well.. e.g. if it is in toggle mode)



Then just forward the event to another event - here LED:1

[code]

EVENT_BUTTON id=  1  fwd_id=LED:1  type=NoteOn chn=1 key=36  range=  0:127 ports=1000100000001000  lcd_pos=1:1:1 label="Button%3i:   %e"

If the event doesn't exist (because you want to avoid unnecessary writing effort), we assume that it will have the same parameters like the button. Same can be done with a rotary encoder to link it with a LEDring:

EVENT_ENC    id=  1  fwd_id=LED_MATRIX:1  type=CC chn=1 cc=16   range=  0:127 ports=1000100000001000  lcd_pos=1:1:1 label="Enc%3i:      %e"

[/code]






This works with any event - also with a generic receiver and sender.

So, you could write:

[code]

# Here we combine a generic receiver and sender to convert CC#16 to a SysEx stream

EVENT_RECEIVER id=  1  fwd_id=SENDER:1  type=CC chn=1 cc=16   range=  0:127 ports=1000100000001000  lcd_pos=1:1:1 label="Receiver%3i: %e"

EVENT_SENDER   id=  1  type=SysEx  stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0  77 ^val 0xf7" ports=1000100000001000  lcd_pos=1:1:2 label="Sender%3i:   %e"

oh... and of course:

# The same vice versa (SysEx -> CC)

EVENT_RECEIVER id=  2  fwd_id=SENDER:2  type=SysEx  stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0  77 ^val 0xf7" \

               range=  0:127 ports=1000100000001000  lcd_pos=1:1:1 label="Receiver%3i: %e"

EVENT_SENDER   id=  2  type=CC chn=1 cc=16 ports=1000100000001000  lcd_pos=1:1:2 label="Sender%3i:   %e"

[/code]




It's even possible to chain events:

[code]

# A chain of events... max. 4 events can be chained (to avoid feedback loops or too deep recursions)

# note: in future we could also provide range scaling here, e.g.

# range 0:127 -> range 20:30 or even range 0:127 -> range 127:0 (inversion)

EVENT_RECEIVER id=  3  fwd_id=SENDER:3  type=CC chn=1 cc=17   range=  0:127 ports=1000100000001000  lcd_pos=1:1:1 label="Receiver%3i: %e"

EVENT_SENDER   id=  3  fwd_id=SENDER:4  type=CC chn=1 cc=18   range=  0:127 ports=1000100000001000  lcd_pos=1:1:2 label="Sender%3i:   %e"

EVENT_SENDER   id=  4  fwd_id=SENDER:5  type=CC chn=1 cc=19   range=  0:127 ports=1000100000001000  lcd_pos=1:1:2 label="Sender%3i:   %e"

EVENT_SENDER   id=  5                   type=CC chn=1 cc=20   range=  0:127 ports=1000100000001000  lcd_pos=1:1:2 label="Sender%3i:   %e"

Now to your usecase:

# An external MIDI controller, sending to CC32 should control an ENC entry

EVENT_RECEIVER id=  6  fwd_id=ENC:6  type=CC chn=1 cc=32   range=  0:127 ports=1000100000001000


# the ENC entry forwards the new value to a SENDER

EVENT_ENC    id=  6  fwd_id=SENDER:6  type=SysEx  stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0   1 ^val 0xf7"  syxdump_pos=1:1 \

             range= 16:112 offset=  0  ports=1000100000001000  lcd_pos=1:1:2 label="OSC1 Octave ^octave %03d"


# the sender sends back the new ENC value to the external controller

# or: if the ENC is moved, the it will get the new value

EVENT_SENDER id=  6                   type=CC chn=1 cc=32  range=  0:127 ports=1000100000001000

[/code]


In order to combine this with the group handling (which I will explain further once it's completely implemented), it will also be possible for a SENDER to send to the first ENC of a group.

E.g. let's say, we've grouped 16 (hardware) encoders, so that their assignments can be switched between the ENC id=1...16, ENC id=17..32, ENC id=33.48, etc.. items

Then it will also be possible for a SENDER to send to the current "first ENC" (so: id=1, 17, 33, ...) of the current selected encoder group.

-> this should completely cover your proposal :)


Best Regards, Thorsten.

[ilmenator]

V-E-R-Y N-I-C-E !!! :drool:

[jojjelito]

This will be great! Thanks TK!

[TK.]

So - finally a first public beta version is available! :)

->

More documentation will be available this evening, but I guess that our experts will already be able to start with the first experiments. ;)

This thread is locked now, please continue discussions in the new forum article.

Best Regards, Thorsten.