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.

Hi *, this thread informs you about the latest release, and gives you the possibility to write down your feedback (bug reports, questions about existing features, suggestions for new features, etc...) MIDIbox NG is in beta state! Not all planned features are implemented, but the existing functions should (hopefully) work stable. The latest build for MBHP_CORE_STM32 and MBHP_CORE_LPC17 can be downloaded at: -> http://www.ucapps.de/mios32_download.html List of planned/implemented features (press refresh button in your webbrowser to display the latest state): -> http://www.ucapps.de/midibox_ng.html Documentation (in progress): Hardware LCD Hardware First Steps .NGC Configuration File .NGL Configuration File .NGR Configuration File Standard Control Surface The complete Documentation ;-) Best Regards, Thorsten.

Hi, do you have a schematic for this keyboard? Best Regards, Thorsten.

Hallo Alexander, danke fuer die Rueckmeldung! Schoen, dass Du die Ursache noch gefunden hast! :) Gruss, Thorsten.

Thanks for the hint, I will update soon! :) But I'm surprised that these imperfections were handled as compile error, at my side these are only warnings. Best Regards, Thorsten. /Edit: fixed in repository now

Hallo Roman, mittlerweile findet die Erweiterung selbst in einer meiner Applikation Verwendung (MIDIO128: das .MID menu) - so schlecht war die Anregung also gar nicht, man muss halt nur manchmal ueber seinen eigenen Schatten springen. ;-) LPCXPRESSO programmieren: laeuft bei Dir eigentlich Windows oder Linux in der VirtualBox? Ich verwende normalerweise Linux, damals hat das gut geklappt. Windows war bei mir glaube ich auch problematisch. Gruss, Thorsten.

The GLCD has to be selected in the Bootloader Update application. Just upload it again (don't worry, the update won't take place) and type "help" in MIOS Terminal. Probably it will show that a CLCD is selected. Change it with the "lcd_type" command. Best Regards, Thorsten.

Hast Du vielleicht im Bootloader ein GLCD konfiguriert? Lade nochmal das Bootloader Update auf (der Update wird nicht stattfinden, doch die Applikation gibt Dir auch Zugriff auf die LCD Parameter) Tippe dann "help" im MIOS Terminal: welches Display wird angezeigt? (sollte auf CLCD stehen) Gruss, Thorsten.

Very nice! :) Best Regards, Thorsten.

MIOS Studio 2.4.1 is available now This time only two minor changes: - the filebrowser editor doesn't close anymore if the file has been saved - means: you can do successive edits and send them to the core without re-opening the file again and again... - previous MIDI IN/OUT port selection won't get lost if MIOS Studio was opened while the selected ports were not available. Best Regards, Thorsten.

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.

No, because the right versions are selected with highest priority in the PATH variable. It could be, that this is related to a 32bit/64bit issue; Leopard is running in 32bit mode, right? I need some time to find out how to compile for 32bit with the existing Xcode toolchain, because it seems that this isn't properly documented. :-/ Best Regards, Thorsten.

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! :) 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.

Hi, ok from my side. Best Regards, Thorsten.

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.

Alternative download location: http://www.midibox.org/mios32_toolchain Best Regards, Thorsten.

I'm currently not so much into assembly programming... but thanks for the reminder - at least before new year I will clean up the open topics ;) Best Regards, Thorsten.

Oh! :-( Which MacOS version are you using? Maybe I've to compile the binaries differently. I'm using 10.8 Best Regards, Thorsten.

There are some obsolete settings in your script... Actually it should work this way: # shell script goes here # path to MIOS base directory export MIOS_PATH=~/Desktop/MIOS # path to MIOS bin directory export MIOS_BIN_PATH=${MIOS_PATH}/bin # path to SDCC and GPUTILS bin directories export PATH=~/Desktop/blob/sdcc/bin:~/Desktop/blob/gputils/bin:$PATH # change to SRCROOT (which is passed by Xcode?) cd $SRCROOT # execute the makefile make [/code] Best Regards, Thorsten.

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.

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.

Nice demo! :) Check your filter settings, maybe the cutoff frequency of the right filter is 0, or you've assigned all oscillators to the filter (Chn=123), but filter mode is disabled (Mod=---)? Best Regards, Thorsten.

It doesn't matter where the directories are located. /usr/local/bin is the traditional location, today we prefer /opt It's important, that your PATH variable points to the appr. bin directories of the packages. Best Regards, Thorsten.

Nein, ein Releasedatum gibt es natuerlich nicht, aber ich denke, dass die Firmware naechstes WE den "Public Beta" Status erreicht hat. Gruss, Thorsten.

Hi, this is the wrong SDCC and GPUTILS version. I think that it really makes sense that I'm hosting the right versions at midibox.org Here we are: http://www.midibox.org/mios8_toolchain Please let me know if this works, then I will update the Wiki accordingly. Best Regards, Thorsten.