Jump to content

MIDIbox NG Concept


TK.
 Share

Recommended Posts

Well i didn't meant the conection between other sources.

What i mean is to connect a LPC17_Core to an other LPC17_Core (or some other midibox equipment...) so i can save the 4 MIDI Ports for Connection to 4 MF_NG Modules and Connect to 32 Faders... :thumbsup:

Ok, you are right that for such purposes the MBNet would be very useful.

The CAN communication handler is already implemented & working (e.g. I can connect to a MBSID V2 via a LPC17 core) - so, it won't be that difficult to support this possibility to link multiple cores, therefore I added it to the feature list. :)

How many encoders will this have? (Re: Control surface PCB for 16 encoders/LEDrings Bulk Order)

With a single SRIO chain (up to 16 DINs and 16 DOUTs) 64 encoders and 64 LED rings can be serviced.

With a second SRIO chain (+16 DINs and +16 DOUTs) 128 encoders and 128 LED rings

Best Regards, Thorsten.

Link to comment
Share on other sites

I planned to make a DJ Conroller and like to know if

you planned to support high resolution/optical encoders (for the jog wheels) in some way?

If you donate one highres encoder to me, I could try to enhance the driver accordingly.

Best Regards, Thorsten.

Link to comment
Share on other sites

If you donate one highres encoder to me, I could try to enhance the driver accordingly.

Best Regards, Thorsten.

Es gibt einige verschiedene Herangehensweisen zum Thema HiRes Encoder im Forum.

Optisch, Magentisch oder doch mechanisch? Wie ist deine Meinung dazu?

Wieviele Ticks/Umdrehung wären sinnvoll und zu welchem Preis.

Oder hast du schon einen bestimmten Encoder im Fokus?

Spenden wär kein Thema :)

Gruß

Marxon

Link to comment
Share on other sites

Silly question: Is this Software only or does the NG Concept include new hardware aswell (except for the MF_NG)?

The concept involves new and improved configurations, new capabilities. It will use existing LPC17 core plus existing MBHP modules.

As in the past, folks will sometimes combine the required elements for a particular configuration or project into a single PCB. This would be considered new hardware I guess.

Link to comment
Share on other sites

Es gibt einige verschiedene Herangehensweisen zum Thema HiRes Encoder im Forum.

Optisch, Magentisch oder doch mechanisch? Wie ist deine Meinung dazu?

Wieviele Ticks/Umdrehung wären sinnvoll und zu welchem Preis.

Oder hast du schon einen bestimmten Encoder im Fokus?

I've no experiences on this topic, and therefore no opinion ;)

Silly question: Is this Software only or does the NG Concept include new hardware aswell (except for the MF_NG)?

If this is the actual question: an existing PIC based MIDIbox64/64E/LC can be upgraded by replacing the core module.

If it had a MF module before, it has to be replaced by MBHP_MF_NG

All other components can be re-used.

Best Regards, Thorsten.

Link to comment
Share on other sites

Hmm, I think I did not make clear what I actually wanted to know. But I can awnser ist now =P

It is "software only", as no new modules etc. are to be developed. Only thing is, one has to use the LPC Core, as PIC won't be supported anymore (resepectively not capable of Midibox NG standards).

(Ich will sagen, dass ist ein reines Software Projekt, da keine neuen Module eingeführt werden etc., somit ist es nur eine neue und verbesserte MIOS Anwendung).

Right?

Anyway, nice project. I think a more general Midibox project is a good way, as (imho) the existing projects have their strengths and weaknesses and are specialized too much (e.g., Midibox64E is not recomended with heavy pot use, so one has to tweak quite a bit around if he wants to use encoders and pots at the same project). A project where everything is possible (and has to be configured only) is just the next logical step.

Edited by kernelpanic
Link to comment
Share on other sites

this is great to hear news! thumbsup.png

while it smashes 50% of my current mb-project's concept, the ng will allow me to reconsider almost all of my postponed features and allow even more.

is this the thread to watch for needed help and support to this?

i would even come along, prepare you some meals and clean your toilet. but i guess you are in the far west.

do you consider to design the software that allows to change the configuration of a group of (encoders, buttons, leds, lcds), while any other configs are untouched?

Link to comment
Share on other sites

is this the thread to watch for needed help and support to this?

I will open a new thread once the beta version is released.

do you consider to design the software that allows to change the configuration of a group of (encoders, buttons, leds, lcds), while any other configs are untouched?

We will see ;-)

Best Regards, Thorsten.

Link to comment
Share on other sites

Hey,

I have two feature suggestions for the MB_NG:

1. Since the MB_NG will support the logic/mackie control protocol, it would be nice if one LPC17 core would emulate multiple logic controls.

Imagine that you want to build a 16 channel controller. With the old MB_LC each core would support only 8 channels per port (like the original), so you would have to add 2 cores, 4 midi cables...

Since the LPC17 supports 4 midi ports (right?), is it possible to use one LPC17 for this (with just a single USB cable)?

2. Yesterday I spoke to some friends from Bitwig about midi controller support in their software, and I told them I'd love to see a possibilty to have preset names (e.g. from a software sampler) on my LC Display of my (midibox) controller.

From what I understand it should already be possible to send that info via midi. Their implementation is based on Javascript, and it will be documented and free for everyone to adapt (their logic control support is already working btw).

So what I'd like to see is a way to send midi data (CC, NRPN, Sysex...?) to a midibox controller to display characters on the LCD (GLCD, CLCD...).

I hope this makes sense ;)

Cheers

Lars

Link to comment
Share on other sites

Hi Lars,

to 1) yes it will be possible to assign different USB ports for different protocols. The existing code base is already written in a way which allows duplication

to 2) it's an interesting feature, and I will support it if it also works under MacOS

Best Regards, Thorsten.

Link to comment
Share on other sites

On the old 8-bit core, I had implemented this to work like this (just found an old document detailing the mechanism, I don't remember exactly whether the application was a custom made one, or whether this was supported by all MIDIboxes - this is just to say that what you want is definitely possible):

LC Display Text can be displayed on the LCDs by sending MIDI System Exclusive (SysEx) data to the MIDIbox. It can receive encapsulated ASCII strings from the host and display them on the LCDs. Assuming two LCDs present, the first line of display LCD1 is reserved for displaying such messages. The MIDI SysEx string for displaying text must look like this:


F0 00 00 7E 40 00 08 01 00 00 text as ASCII data F7

The first byte indicates that the following bytes are SysEx data. The next eight bytes are a unique identifier which tells the MIDIbox that the following data bytes contain text to be displayed on the LCD. The first data byte (the tenth overall byte) determines the cursor position of the text to be displayed. The remaining data bytes contain the actual ASCII encoded text. The last byte (0xF7) indicates the end of the SysEx message.

Assuming the first display to have 2 x 40 characters, text to be displayed on LCD2 would then need to start at cursor position 0x50 (80 decimal).

For the Core32 you might want to look at the corresponding display functions here.

Edit: Okay, TK was faster, and looking at his reply it was probably some custom code that I used. About eight years ago, don't remember all the details...

Edited by ilmenator
Link to comment
Share on other sites

The logic control and motormix applications have already similar functions.

But it has to be considered, that MBNG will provide support for multiple LCDs, which means that a custom protocol with special enhancements will be required.

Best Regards, Thorsten.

Link to comment
Share on other sites

Oh, one more thing: you might be interested in how the Mackie C4 Pro handles text display on any of the four screens - I would think that Mackie Control and Control Extension use a very similar protocol. Some years ago I uploaded the MIDI implementation, you can find it here.

  • Like 1
Link to comment
Share on other sites

@TK

sounds great!

Btw, I have Bitwig studio running here on a macbook pro / OSX 10.6.8, but it will run on windows and even on ubuntu linux as well.

@ilmenator

thanks! my keyboard/controller is still running MB64e (which is assembler based, right?), so I can't modify this easily. But I will update this to LPC17 / MB_NG as soon as it is running well.

Can't wait to try the MB_NG beta :thumbsup:

Link to comment
Share on other sites

There is some progress on the development side: the basic framework is available, I've tested some general concepts how to organize and configure the setup, and I'm satisfied with the results. :)

Here a configuration example on which I'm currently working:

BLOFELD.NGC and BLOFELD.NGL

The .NGC file configures the application.

It can either contain the complete setup, or only a partial setup like in this example.

At the header some meta events are assigned to buttons, they switch between encoder group 1..5 which select OSC1/2/3 and FIL1/2 parameters:


# Following buttons switch between the Encoder groups
# For demonstration purposes, we also add a second meta event which switches the AINSER group (but AINSER not configured here...)
# The selected group will be displayed at lcd_pos=1:1:1 (first LCD, X=1, Y=1)
EVENT_BUTTON id= 1 type=Meta meta=SetEncGroup:1 meta=SetAinSerGroup:1 lcd_pos=1:1:1 label="**** OSC1 Group ****"
EVENT_BUTTON id= 2 type=Meta meta=SetEncGroup:2 meta=SetAinSerGroup:1 lcd_pos=1:1:1 label="**** OSC2 Group ****"
EVENT_BUTTON id= 3 type=Meta meta=SetEncGroup:3 meta=SetAinSerGroup:1 lcd_pos=1:1:1 label="**** OSC3 Group ****"
EVENT_BUTTON id= 4 type=Meta meta=SetEncGroup:4 meta=SetAinSerGroup:1 lcd_pos=1:1:1 label="**** FIL1 Group ****"
EVENT_BUTTON id= 5 type=Meta meta=SetEncGroup:5 meta=SetAinSerGroup:2 lcd_pos=1:1:1 label="**** FIL2 Group ****"
[/code] Below you will find the event definitions for encoder events:
[code]
# event definitions for encoders
# The event labels will be print at lcd_pos=1:1:2 (first LCD, X=1, Y=2)
# Sometimes we are using conditional labels which are defined in blofeld.ngl
EVENT_ENC id= 1 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0 1 ^val 0xf7" range= 16:112 offset= 0 ports=1000100000001000 lcd_pos=1:1:2 label="OSC1 Octave ^octave %03d"
EVENT_ENC id= 2 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0 2 ^val 0xf7" range= 52:76 offset=-64 ports=1000100000001000 lcd_pos=1:1:2 label="OSC1 Semitone %03d"
EVENT_ENC id= 3 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0 3 ^val 0xf7" range= 0:127 offset=-64 ports=1000100000001000 lcd_pos=1:1:2 label="OSC1 Detune %03d"
...
As you can see, it's possible to define SysEx streams directly. Even variables can be inserted, such as "^dev" (for device ID) and "^val" (for the value)... a stream can also send multiple SysEx events, or multiple "common" MIDI events such as Note, CC, etc... The value range can be specified from 0...16383, and we have an offset for displayed value (e.g. in the example above: Semitone ranges from 0:127, but the displayed value will be -64..63) At the end of the line the LCD output is defined. It supports printf-like formatting! E.g.
  • %d will display the value in decimal format without formatting
  • %3d displays the value with 3 characters right-aligned: " 1"... " 10" ... "100"
  • %03d pads the value with zeroes: "001" ... "010" ... "100"
  • there are many other formats available, such as %x for hexadecimal, %b to print a binary "o" or "*", "%B" to print a vertical bargraph, etc...
Another special feature of the LCD string definition is the "^" character: it allows to select labels which are defined in the .NGL file: Excerpt from BLOFELD.NGL:

COND_LABEL fil_type
COND =0 "Bypass "
COND =1 "LP 24dB "
COND =2 "LP 12dB "
COND =3 "BP 24dB "
COND =4 "BP 12dB "
COND =5 "HP 24dB "
COND =6 "HP 12dB "
COND =7 "Notch24dB"
COND =8 "Notch12dB"
COND =9 "Comb+ "
COND =10 "Comb- "
COND =11 "PPG LP "
COND_ELSE "Type %3d "
[/code] This is a conditional label, which will print different strings based on the value. Such labels consume a lot of memory - but don't worry: they are stored in binary format on the SD Card! :) (a .NGL file will be compiled into a .BIN file which can be accessed quickly during runtime without parsing overhead) Therefore, the number of such label definitions is only limited by the SD Card size. Back to the .NGC file: the hardware is configured independent from the event definitions, e.g.:
[code]
# encoder hardware configuration
ENC n= 1 sr= 5 pins=0:1 type=non_detented
ENC n= 2 sr= 5 pins=2:3 type=non_detented
ENC n= 3 sr= 5 pins=4:5 type=non_detented
ENC n= 4 sr= 5 pins=6:7 type=non_detented
ENC n= 5 sr= 6 pins=0:1 type=non_detented
ENC n= 6 sr= 6 pins=2:3 type=non_detented
ENC n= 7 sr= 6 pins=4:5 type=non_detented
ENC n= 8 sr= 6 pins=6:7 type=non_detented
ENC n= 9 sr= 7 pins=0:1 type=non_detented
ENC n= 10 sr= 7 pins=2:3 type=non_detented
ENC n= 11 sr= 7 pins=4:5 type=non_detented
ENC n= 12 sr= 7 pins=6:7 type=non_detented
ENC n= 13 sr= 8 pins=0:1 type=non_detented
ENC n= 14 sr= 8 pins=2:3 type=non_detented
ENC n= 15 sr= 8 pins=4:5 type=non_detented
ENC n= 16 sr= 8 pins=6:7 type=non_detented


# LEDring configuration
DOUT_MATRIX n= 1 rows=16 inverted=0 sr_dout_sel1= 1 sr_dout_sel2= 2 sr_dout_r1= 3 sr_dout_r2= 4 sr_dout_g1= 0 sr_dout_g2= 0 sr_dout_b1= 0 sr_dout_b2= 0

The named parameters give me enough freedom to add new ones in future without compatibility issues.

For the case that you are interested: here the default configuration files, which will be automatically generated if they don't exist on SD Card:

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Fdefault%2F

That's all so far - many details are still missing, but I think that the firmware should reach the "public beta" state next weekend! :)

Best Regards, Thorsten.

Link to comment
Share on other sites

Looks amazing!

Has any thought gone into the possibility of parameter feedback?

The example I'm thinking of is a synth control panel where all parameters are encoded as CC and note Aftertouch messages. Obviously when an encoder or button is pressed the value is changed, sent and displayed. Now if the value is received, the idea is the display and state of the control is updated to reflect this. In the case of the Access Virus, a simple dump request message would result in the the whole midibox being updated with the current patches values for every parameter, ready for modification. Also, it would keep the midibox "in sync" with data changed from the front panel controls of the synth.

Link to comment
Share on other sites

Has any thought gone into the possibility of parameter feedback?

The example I'm thinking of is a synth control panel where all parameters are encoded as CC and note Aftertouch messages. Obviously when an encoder or button is pressed the value is changed, sent and displayed. Now if the value is received, the idea is the display and state of the control is updated to reflect this. In the case of the Access Virus, a simple dump request message would result in the the whole midibox being updated with the current patches values for every parameter, ready for modification. Also, it would keep the midibox "in sync" with data changed from the front panel controls of the synth.

of course, this is one of the next steps before beta release. In my particular usecase, I want to update all encoders from a SysEx dump requested from the Blofeld.

So, it will be possible to update values based on incoming MIDI events or even from a SysEx dump (in this case, the corresponding byte position has to be defined with the EVENT_xxx item)

The received SysEx dump format will be defined in a special EVENT definition, and the request will be triggered from a button assigned to a SysEx stream.

Btw.: I also already considered that we want to embedd a device ID, pattern, bank, instrument number into the SysEx stream for such a request:


case MBNG_EVENT_SYSEX_VAR_DEV: *stream_out = mbng_patch_cfg.sysex_dev; break;
case MBNG_EVENT_SYSEX_VAR_PAT: *stream_out = mbng_patch_cfg.sysex_pat; break;
case MBNG_EVENT_SYSEX_VAR_BNK: *stream_out = mbng_patch_cfg.sysex_bnk; break;
case MBNG_EVENT_SYSEX_VAR_INS: *stream_out = mbng_patch_cfg.sysex_ins; break;
case MBNG_EVENT_SYSEX_VAR_CHN: *stream_out = mbng_patch_cfg.sysex_chn; break;
case MBNG_EVENT_SYSEX_VAR_CHK_START: new_value = 0; chk = 0; break;
case MBNG_EVENT_SYSEX_VAR_CHK: *stream_out = chk & 0x7f; break;
case MBNG_EVENT_SYSEX_VAR_CHK_INV: *stream_out = (chk ^ 0x7f) & 0x7f; break;
case MBNG_EVENT_SYSEX_VAR_VAL: *stream_out = value & 0x7f; break;
case MBNG_EVENT_SYSEX_VAR_VAL_H: *stream_out = (value >> 7) & 0x7f; break;
case MBNG_EVENT_SYSEX_VAR_VAL_N1: *stream_out = (value >> 0) & 0xf; break;
case MBNG_EVENT_SYSEX_VAR_VAL_N2: *stream_out = (value >> 4) & 0xf; break;
case MBNG_EVENT_SYSEX_VAR_VAL_N3: *stream_out = (value >> 8) & 0xf; break;
case MBNG_EVENT_SYSEX_VAR_VAL_N4: *stream_out = (value >> 12) & 0xf; break;
[/code]

Device ID/Pattern/Bank/Instrument/Channel will be selectable from a special SCS page.

Best Regards, Thorsten.

Link to comment
Share on other sites

SysEx dumps can now be received and mapped to controllers (such as encoders, which then optionally forward to ledrings).

How does it work:

First we define a button which sends the SysEx dump request:


# this button requests a SysEx dump
# note: instead of "^bnk ^pat" we specify "0x7f 0x00" to request the edit buffer!
EVENT_BUTTON id= 8 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x00 0x7f 0x00 0xf7" \
range= 0:1 offset= 0 ports=1000100000001000 button_mode=OnOnly \
lcd_pos=1:1:1 label="*** Dump Request ***"
[/code] Then we define a "generic receiver" which listens to MIDI, but isn't assigned to any controller (ok, it can output LCD messages)
[code]
# this generic receiver (without controller assignment) receives the SysEx dump
# and notifies all events which select syxdump_pos=1:<pos-in-dump>
EVENT_RECEIVER id= 1 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x10 ^ignore ^ignore ^dump" \
ports=1000100000001000 \
lcd_pos=1:1:1 label="* Received SyxDump *"
The ^dump statement starts the mapping. Controllers which should receive the SysEx data are defined this way:

########################################################################################################################
# OSC1
#######################################################################################################################
EVENT_ENC id= 1 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"

EVENT_ENC id= 2 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0 2 ^val 0xf7" syxdump_pos=1:2 \
range= 52:76 offset=-64 ports=1000100000001000 lcd_pos=1:1:2 label="OSC1 Semitone %03d"

EVENT_ENC id= 3 type=SysEx stream="0xf0 0x3e 0x13 ^dev 0x20 0x00 0 3 ^val 0xf7" syxdump_pos=1:3 \
range= 0:127 offset=-64 ports=1000100000001000 lcd_pos=1:1:2 label="OSC1 Detune %03d"
...
[/code]

the new "syxdump_pos=<receiver-id>:<position-in-dump>" is the key! :)

This means, that we can even define multiple receivers for different dump types (different patch formats, different synths) and distribute the values to controllers independent from each other. :)

The complete setup file (which is still under development): BLOFELD.NGC

Best Regards, Thorsten.

Link to comment
Share on other sites

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 ? =/

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...