TK.

Yes, a CTRLR based panel is a feasible option - it will be a lot of work for you, but with the Lemur based solution it has been proven that the NRPN based communication is working, and it's also a good reference how to organize the layout. Best Regards, Thorsten.

Can't give you a better reference project than Novski :) Best Regards, Thorsten.

Hi Nate, MIDIO128 only supports 8x8 matrices, but up to 16 matrices can be defined. So, you could combine four 8x8 matrices to two 8x16 matrices, although you will only need 4x11 connections per keyboard. In addition the firmware allows you to map map different key values to the scanned inputs to align this with your keyboard layout. Channel can be selected as well. So: you would need: - 1 x MBHP_CORE_STM32F4 (alternatively MBHP_CORE_LPC17) - 2 x MBHP_DIO_MATRIX (best choice in your case: 4 DOUT and 4 DIN SRs) - 1 x MBHP_AINSER64 - the components for the SCS (1 rotary encoder, 6 buttons, a 2x20 CLCD) Best Regards, Thorsten.

Yes, MIDIbox DR has been discussed offline. As far as I know, Al is planning to provide the PCB in a bulk order. But please show patience - we are discussing this since January 2012! ;-) Best Regards, Thorsten.

Yes, this is the solution. The SET_NO_DUMP command is part of the V1.032 firmware that I released yesterday. Best Regards, Thorsten.

Hi Mark, the encoder spec (http://www.cliffuk.co.uk/products/encoders/EncoderSpec.pdf) looks fine, it will work :) Note that MIDIbox NG allows to connect up to 16 buttons to J10A/B, see also this configuration example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fdiocfg_1.ngc This means that you only need a single MBHP_DINX4 module for 16 encoders, the two buttons can be connected to J10A.D0 and D1, and with "DIO port=J10A emu_din_sr=5" they will be available as BUTTON:33 and BUTTON:34 Best Regards, Thorsten.

It seems that the PATH variable isn't set correctly. The wiki page gives an example: export PATH=$PATH:/usr/local/mios32_toolchain/bin If you've copied the toolchain to another location (not /usr_local/mios32_toolchain, but somewhere else), just adapt this setting accordingly. Best Regards, Thorsten.

I added "ain_mode=Toggle", because it was easier to implement this than troubleshooting your experiment ;) The new feature is available in v1.032 Best Regards, Thorsten.

A new version is available: MIDIbox NG V1.032 ~~~~~~~~~~~~~~~~~ o support for mathematical operations in .NGR script. They have to be surrounded with square-brackets ([...]) Syntax: [<left-operand><operator><right-operand>] Example: - set LED:2000 [LED:2000 + 1] will increment the value stored in LED:2000 - set LED:2000 [LED:2000 - 1] will decrement the value stored in LED:2000 Note that nested operations are supported as well, such as: - send CC USB1 1 [LED:2000 + [LED:2001 + [LED:2002 + LED:2003]]] More examples in cfg/tests/runscr5.ngc Support operators: + - * / % & | ^ o number of scanned SRIOs now configurable in .NGC file with 'SRIO num_sr=<1..32>' By default 32 DIN and DOUT shift registers are scanned, which result into an update rate of ca. 420 uS on a STM32F4 based core. With (for example) 'sr_num=8' only up to 8 DIN and 8 DOUT SRs will be scanned anymore, but the update rate is reduced to ca. 110..120 uS (a little bit more than a quarter due to SR handling overhead) o corrected DebounceCtr parameter (value was not passed to MIOS32) Now also part of the SRIO configuration, use: SRIO debounce_cycles=<1..255> o added new meta event "KbBreakIsMake:<keyboard-number>" which will already trigger a note event when the break contact is activated (nice for playing organ style). Trigger it from a toggle button function as shown in cfg/test/kb_5.ngc Can be optionally set from the terminal as well with following command: "set kb <keyboard-number> break_is_make <on|off>" (e.g. "set kb 1 break_is_make on") o added ain_mode=Toggle for AIN and AINSER events. Similar to ain_mode=Switch it can be used if buttons are connected to analog inputs. The event will toggle between the min and max value. o .NGR: added "set_no_dump" command. It allows to change the "no_dump" flag which specifies if an EVENT_xxx should be sent during a DumpSnapshot. This feature can be used to handle different snapshot setups. o STM32F4: support for bootloader "enforce_usb_device" flag Best Regards, Thorsten.

We continue as usual; some messages seem to be lost forever :-( Best Regards, Thorsten.

Hi, too difficult at my side... However, if I would provide access to the "no_dump" flag in the .NGR file, you would be able to enable/disable the flag for the affected events before restoring the snapshot via "exec_meta SetSnapshot <number>", "exec_meta LoadSnapshot" and "exec_meta DumpSnapshot". Best Regards, Thorsten.

Wow! This great piece of work definitely deserves a MIDIbox of the Week entry! :) -> Best Regards, Thorsten.

Eye candy! :smile: (click on picture to enlarge)

:thumbsup:

Don't worry, nothing dangerous will happen. Just imagine that you've soldered a big el-cap into the box which will slowly ramp-down the voltage when you turn off the sammichSID, so that PIC and SIDs are sent into deep-sleep softly. :sleep: Best Regards, Thorsten.

No, there is no real advantage if you would use a GLCD with 128x64 resolution. MIOS32 will just show the content with 6x8 pixel characters, which means that up to 21x4 characters could be displayed - but the firmware doesn't use of the additonal two lines. They will appear empty, and this looks ugly! That's a general rule for any MIDIbox: if a firmware doesn't explicitly support graphical images or more than the standard 2 character lines, the GLCDs are just handled as a dumb output device which emulates a CLCD, and all unused lines are blank. SCS: most parameters are accessible, which means in other words: I believe that all parameters can be edited, but if I missed one, just let me know and I will add it. Mostly I use the Lemur based solution, therefore only for this one I can guarantee completeness. Actually I only use the SCS for quick changes without turning on the iPad, e.g. if I want to check if a CV channel if it's working. Compared to Lemur the handling is very cumbersome... Best Regards, Thorsten.

I found following hint in the user manual of your interface: Here the complete manual for the case that you don't have it anymore: ftp://ftp.steinberg.de/Archives/Hardware/Midex_3/Midex3OperationManual.pdf This explains, why your MIDIbox behaves differently once you open MIOS Studio (the MIDI application) The reason why it works with your other MIDIboxes: maybe you've connected them to a different MIDI OUT of your MIDEX-3 interface? Or your 3rd MIDIbox has MIDI merger enabled, the other not... The MIDI merger would cause a loopback between the MIDIbox and the MIDEX-3 interface. Best Regards, Thorsten.

Let me follow-up on this later (when I implemented the new mode...) Best Regards, Thorsten.

Yes, just the MB-808 firmware with a special configuration which enables 13 CV outputs (for velocity) at 6bit resolution - the 74HC595 based DACs are part of the PCB as well: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_808%2Fsetup_seq_dr_default.asm Best Regards, Thorsten.

You are right, looking into the source code I can confirm that I even commented this behaviour ;-) Seems that we've finally found a use case where it makes sense to think about a generic way to trigger the MIDI event during forwarding. However, as always it will take some time until such a new feature will be available. Until then you could just execute a .NGR section with the AINSER event in addition, and from there you can send the current button value (which toggles between min and max) with the "TRIGGER BUTTON:<button-id>" command. Best Regards, Thorsten.

For MIOS8 applications this is definitely not normal (most of them are working since years and nobody reported such an issue yet). (for the records: the MIOS32 issue only exists for MBHP_CORE_STM32F4 after the new USB MIDI Host driver has been introduced, and will be solved with the next app releases) Which MIOS8 application are you using exactly? How is it connected to the MIDI device (resp. your PC?) and is there anything else we should know to help you? Best Regards, Thorsten.

Maybe I haven't recognized a certain detail, but I don't see the need to modify MIOS32 code or any driver. Just use the MIDIbox NG app and you can even use this hardware with an existing firmware without modification. However, please note that the LEDs and buttons are connected in the wrong order. The leftmost LED (B_LED_1) has to be connected to 74HC595 QH7, the next to QH6, etc... The leftmost button (B_PB1) has to be connected to 74HC165 A, the next to B, etc... In other words: when you compare with the MBHP_DINX4/DOUTX4 schematics, the LEDs are connected from D7, D6, D5, ... and buttons are connected from D0, D1, D2, ... yes, this was a good idea. But I'm missing the 10 Ohm resistor between digital and analog ground: http://www.ucapps.de/mbhp/mbhp_ainser8.pdf Bad idea, use two ADCs for best results. Shouldn't happen with the 10 Ohm resistor which acts as some kind of filter. As you can see here I even provide a jitter monitor to check this: http://www.ucapps.de/mbhp_ainser8.html And the conversion results are very stable, especially when we consider that for your MIDI devices only 7bit are required, and values are jittering at +/- 3 at 12bit resolution ;-) As long as you keep both SPI interfaces (and don't try to handle SRs and AINSERs via a single SPI) it will work without firmware changes. For the SRIO chain 4 signals are required: SO, SI, SC and RC1 (RC2 isn't required, it's just a duplicated RC1) For the AINSER8 chain 5 signals are required: SO, SI, SC, RC1 and RC2 + 5V and Ground makes 11 pins However, it's your own decision if you select an incompatible Jxx pinout for your project, or if you take a compatible one and open the possibility for other people to re-use your PCB with a common MBHP_CORE_STM32F4 module. Just another hint: with MIDIbox NG it would be possible to scan the buttons and LEDs from J10A and J10B instead of using shift registers. This would result into one additional connector, but it would save two SRs Best Regards, Thorsten.

Hi, are you using a MBHP_CORE_STM32F4 module? And what which MIOS32 app are you using? There is a known issue which has been fixed some days ago, but I haven't re-released all applications yet. Best Regards, Thorsten.

A DOG display will require some special initialisation code in the firmware which is not supported by default... However, I would propose to use an OLED instead, it looks much better and doesn't required SW changes! Here some pictures from our (upcoming) MIDIbox DR (based on MIDIbox 808 firmware) Best Regards, Thorsten.

Hi Chris, I haven't checked this by myself, but it could work by forwarding the event to a BUTTON in toggle mode Best Regards, Thorsten.