TK.

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.

It will work with any MIDIbox, which means: also with MIDIbox NG. It's the right approach for an external pedal board - but let me prove the robustness first before I can confirm that it will really help. Best Regards, Thorsten.

I was able to recover this, repo is at 2088 again. Best Regards, Thorsten.

No, this isn't so easy to implement and leads to an unnecessary complexity which I don't want to support (especially if I don't use this HW by myself). Actually the LED rings are already too extravagant: whenever you move an encoder, the parameter name and value will be displayed on the 2x20 LCD Best Regards, Thorsten.

Hi, since the old posting got lost, I will write a new one and give you some updates. I've overworked the 25-pin breakout port for MBSEQ (and MBCV V2) to allow interconnections between an AOUT(_NG) module and MIDIbox over long cables (at least 2m will be possible). In addition, the previously direct J5/J28 outputs for gates and DIN clock have been replaced by a DOUT connection, which means that level-shifting is now done via 74HC595 SRs, and more than 10 outputs are available (e.g. I'm planning to provide multiple Clock and Start/Stop outputs, but also the 64 drum trigger outputs can now be made available in a breakout box). Picture of the prototype: Schematic of the transmitter part: http://www.ucapps.de/mbhp/mbhp_line_driver_transmitter.pdf Schematic of the receiver part: http://www.ucapps.de/mbhp/mbhp_line_driver_receiver.pdf Update: today I created the layouts and ordered at OSH park. Boards should be available for testing in ca. 3..4 weeks Best Regards, Thorsten.

Update: I got a reply from Twin-X, (unfortunately) he wasn't aware about the incident and will ask the hosting provider. I fear that it won't be possible to restore the missing postings from this week. If there are important troubleshooting requests, please post again! Best Regards, Thorsten.

Hi, as some of you already noticed, the midibox.org server was down yesterday morning; in the afternoon it was online again but with an older forum backup which doesn't contain the postings of this week. I don't know why this happened, and who initiated this. I wrote a mail to Twin-X, but haven't got a reply yet. Hopefully a newer backup is available which will allow us to restore the missing postings. Until this has been clarified, please don't write too much in the forum because it won't be possible to merge old and newer postings. Best Regards, Thorsten.

Great! :) Let's try it step by step - I hope that with a minor modification it's already possible to fake a B cable: http://www.ucapps.de/tmp/stm32f4_usb_test_files.zip Try app_skeleton_enforced_usb_device.hex If the query button is working with this version, try this MIDIbox SEQ release where device mode should be enforced as well: http://www.ucapps.de/mios32/midibox_seq_v4_087_pre4.zip Best Regards, Thorsten.