TK.

Let me check first if something can be done at the SW side (tomorrow...) Best Regards, Thorsten.

My first KiCAD project - I don't miss xcircuit and Eagle & I'm happy that other people can now edit the files with state-of-the-art open source SW as well :-) Best Regards, Thorsten. P.S.: ordered at OSHpark - let's see if the circuit works like intended next year :)

The EVENTs which are controlled via NGR script shouldn't be assigned to a bank, otherwise concurrent changes on the "active" flag will happen. Therefore just write: # select tone 1-2 and trigger NGR script MAP1 1 2 EVENT_BUTTON id=35 hw_id=35 range=map1 button_mode=Toggle type=meta meta=RunSection:1 # select bank and trigger NGR script EVENT_BUTTON id=36 hw_id=36 type=Meta meta=CycleBank meta=RunSection:1 button_mode=OnOnly # dummies to define bank1/2 # can be removed if banks are defined for other events (not controlled from NGR script) EVENT_BUTTON id=3001 bank=1 EVENT_BUTTON id=3002 bank=2 ### First page EVENT_ENC id=1 hw_id=1 lcd_pos=1:1:1 label="1_1%B " EVENT_ENC id=2 hw_id=1 lcd_pos=1:1:1 label="1_2%B " EVENT_ENC id=3 hw_id=2 lcd_pos=1:6:1 label="2_1%B " EVENT_ENC id=4 hw_id=2 lcd_pos=1:6:1 label="2_2%B " ### Second page EVENT_ENC id=5 hw_id=1 lcd_pos=1:1:1 label="9_1%B " EVENT_ENC id=6 hw_id=1 lcd_pos=1:1:1 label="9_2%B " EVENT_ENC id=7 hw_id=2 lcd_pos=1:6:1 label="A_1%B " EVENT_ENC id=8 hw_id=2 lcd_pos=1:6:1 label="A_2%B " And in the NGR script I noticed some wrong "endif" statements. "elsif" will only work for the previous "if" condition if you don't terminate it with "endif": ### First page of parameters if ^bank == 1 LOG "First Bank" ### tone 1 if (id)BUTTON:35 == 1 set_active (id)ENC:1 1 set_active (id)ENC:2 0 set_active (id)ENC:3 1 set_active (id)ENC:4 0 set_active (id)ENC:5 0 set_active (id)ENC:6 0 set_active (id)ENC:7 0 set_active (id)ENC:8 0 ### tone 2 elsif (id)BUTTON:35 == 2 set_active (id)ENC:1 0 set_active (id)ENC:2 1 set_active (id)ENC:3 0 set_active (id)ENC:4 1 set_active (id)ENC:5 0 set_active (id)ENC:6 0 set_active (id)ENC:7 0 set_active (id)ENC:8 0 endif ### Second page of parameters elsif ^bank == 2 LOG "Second Bank" ### tone 1 if (id)BUTTON:35 == 1 set_active (id)ENC:1 0 set_active (id)ENC:2 0 set_active (id)ENC:3 0 set_active (id)ENC:4 0 set_active (id)ENC:5 1 set_active (id)ENC:6 0 set_active (id)ENC:7 1 set_active (id)ENC:8 0 ### tone 2 elsif (id)BUTTON:35 == 2 set_active (id)ENC:1 0 set_active (id)ENC:2 0 set_active (id)ENC:3 0 set_active (id)ENC:4 0 set_active (id)ENC:5 0 set_active (id)ENC:6 1 set_active (id)ENC:7 0 set_active (id)ENC:8 1 endif endif exit With these changes it works at my side :) Best Regards, Thorsten.

Hi, if_equal will match the EVENT value, not the bank, therefore this function won't help for the intended purpose. For complex banking schemes I introduced the NGR command "set_active", where the script can activate/deactivate EVENTs based on your own rules. E.g. following example shows how to activate/deactivate based on the variable ^bank: - https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/multibnk.ngc - https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/tests/multibnk.ngr In your case, you would add BUTTON:33 with an additional "if" condition to activate/deactivate (id)ENC:1 and (id)ENC:2 It will result into a very long NGR script - but it should work (and should be fast enough) Best Regards, Thorsten.

I can't recommend this solution; it only transfers via a serial protocol, which then has to be converted by a computer into MIDI messages - this is error prone. Today we would prefer the BLE MIDI protocol, which is natively supported by many operating systems, and considers special MIDI features such as continuous SysEx streams. And this is possible with a simple ESP32 controller, which is available for the same (or less) price - and on top of this WiFi should be possible as well. Best Regards, Thorsten.

Hi Analog_mo, I don't have enough expertise in this area to assess your circuit proposal, but can give you an alternative advice: There is a new C64 PSU available which seems to be safer: I use it with my MBSID meanwhile because of the same worries that you have... Best Regards, Thorsten.

Cool, I like CME :) Best Regards, Thorsten.

And never forget: from a loopback track it's possible to control sequencer parameters of another track, here the corresponding parameter numbers: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/doc/mbseqv4_cc_implementation.txt And while I was writing this, I remembered that I wanted to make this function also available from a parameter layer. Here it is: http://www.ucapps.de/mios32/midibox_seq_v4_096_pre10.zip E.g. in the Event configuration page, I assigned Par. Layer E to Ctrl: Echo Rep. and Layer F to Ctrl: EchoFB.V - and it works: with each step a new value can be set, or previous setting will be kept if "---" is selected (turn encoder full-right) Best Regards, Thorsten.

Reproducibility proven - great! :) Best Regards, Thorsten.

Good question! Currently it's mainly a learning vehicle for me to explore a new microcontroller and corresponding software. And now I'm also learning KiCad to enter the schematic (and maybe also the Adapter PCB) - currently only for my own interest. If you would like to play with the project as well, you are welcome of course! :) I will bring it at least to a state that others can use an adapter board on their existing MBHP_MF_NG, can connect via traditional MIDI but also Bluetooth and maybe also (later) rtp MIDI, but I can't promisse anything else. And at this point in time it especially needs "real life testing" before it's build by others. Was worth a try: I used 200kHz and it works like 20kHz - don't see a big difference on the motor handling itself - but probably in an analog system: 20 kHz: 200kHz: The "noise" that we see here comes from the higher ADC resolution (faders are scanned at 12bit instead of 10bit) and messy ground on my vero board - this should become better with a PCB. But it doesn't impact the smooth movements. Of course, most interesting would be if it works so smooth like your 89MotionN: At least I see a potential cost benefit ;-) Best Regards, Thorsten.

Hi Tim, there is a metronome function which sends MIDI Notes, by default C#1 on Beat and Measure to Channel #10 of the default port (a GM compatible sound module would output the typical metronome sound). This can be configured at the Options page under 17/33 I think that this is sufficient. By enabling the Audio DAC, MBSEQ would be unnecessarily (over)loaded by outputting the wavestream. There is also not enough RAM available for such a feature (the remaining RAM should be saved for future features) Best Regards, Thorsten.

Depends on the desired resolution for the duty cycle. The timers are clocked at 80 MHz Means: with 20 kHz we could have 4000 different "speed levels" (but actually I'm currently only using 64 speed levels, which is sufficient) At least I know that MacOS and iOS don't allow this. If I take the device with one computer, it appears as "offline" on the other (and vice versa). Seems to be intended, that only a point-to-point connection is allowed. Yes, there should be some kind of meter available, here a link to the driver documentation: https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/bluetooth/ Best Regards, Thorsten.

Hi Chris, the EEPROM is actually emulated in flash. I would assume: if it gets corrupted, very likely also the application couldn't be booted anymore. It's also very unlikely that the flash gets erased due to this "relaxed" temperature - this can't be the problem. Best Regards, Thorsten.

I fixed the link, could you please try again?

Just use the MBNG app with this template: https://github.com/midibox/mios32/blob/master/apps/controllers/midibox_ng_v1/cfg/templates/logictrl.ngc It supports the Mackie and Logic Control protocol. Best Regards, Thorsten.

The "MIDIbox chat" link works at my side. Best Regards, Thorsten.

Hi, interesting: they are using a slightly different way to calculate the checksum. Actually "128-remainder" is problematic, because if the remainder is 0, it would result into an invalid value (128 is outside the 7bit range). So, I added ^chk_roland, and it masks the result with 0x7f to ensure that it will be valid. -> http://www.ucapps.de/mios32/midibox_ng_v1_037_pre6.zip Best Regards, Thorsten,

Interesting! Unfortunately it seems that there is no support for drum sounds, otherwise it would be a good OPL3 replacement :-/ Best Regards, Thorsten.

Should be possible -> https://github.com/lathoub/Arduino-AppleMIDI-Library Good progress at my side: I'm now able to control motorfaders, and the accuracy is much better than ever before, because dedicated PWM outputs are used (which are normally intended to fade LEDs), clocked at non-audible 20kHz range. Some work is still required to get it compatible with MBHP_MF_NG, but maybe I can show the difference in 1..2 days via video. My test setup: a NodeMCU hooked on the MBHP_MF_NG board with a quick&dirty adapter board, communicating via Bluetooth (the MIDI sockets are currently not used - unfortunately ESP32 pins are not 5V tolerant) Best Regards, Thorsten.

It would be too much effort to provide a 1:1 compliant solution. Would it be sufficient if I provide new markers to address the display, and to set the Y position? (something like ^lcd and ^cursor_y)? Best Regards, Thorsten.

Could you please provide a link to the details? Here an example how text messages can be received and forwarded to a LCD: EVENT_RECEIVER id= 1 \ type=SysEx stream="0xf0 0x11 0x22 0x33 0x44 ^cursor ^txt" A more complex example (defining individual cursor positions) in the Logic Control Template: # LCD Messages # Note: we use ^txt56 instead of ^txt, so that the cursor will jump # to the next line after the 56th character has been reached # Use map=1 to map the cursor positions over a 2x80 LCD EVENT_RECEIVER id= 5 \ type=SysEx stream="0xf0 0x00 0x00 0x66 ^dev 0x12 ^cursor ^txt56" \ range=map1 # X cursor positions are defined in MAP1 # spread message over two 2x40 LCDs MAP1 2 3 4 5 6 7 8 \ 12 13 14 15 16 17 18 \ 22 23 24 25 26 27 28 \ 32 33 34 35 36 37 38 \ 42 43 44 45 46 47 48 \ 52 53 54 55 56 57 58 \ 62 63 64 65 66 67 68 \ 72 73 74 75 76 77 78 If this doesn't work for you, I might add an firmware enhancement - but in this case I need concrete information about the content of the SysEx string. Best Regards, Thorsten.

done - have fun! :) Best Regards, Thorsten.

No, I won't have the time for a fully adaption to MIOS32, especially considering incompatibilities, missing resources and last but not least, potential additional user support which I can't give thereafter. And concerning bootloader: the native solution of the ESP32 ecosystem is working well, no real need for an adaption. Therefore I provide the projects "as is" and independent from MIOS32 - but you will find some things known from MIOS32 later, and the projects will be somehow integrated into the MIDIbox platform - but please don't expect so much "flawless compatibility" that we know from MBHP_CORE_STM32/MBHP_CORE_LPC17/MBHP_CORE_STM32F4... Times have changed, today powerful DIY platforms are already available, so that it makes sense to adapt to the workflow of the corresponding users - I'm flexible and see the possibility to reduce efforts at my side ;-) Best Regards, Thorsten.

Winter time is DIY time - and this year I decided to explore the capabilities of the ESP32 platform. There might be synergies with MIOS32, but I'm very sure that I won't fully integrate this Microcontroller into the MIOS32 ecosystem --- this hasn't been considered 10 years ago when I started with the 32bit platform, and it would take too much time to make everything compatible (with many compromises - e.g. no native USB support, and we know that this is important for best performance!) However, I think that ESP32 is a pretty good companion device to a STM32F4, hence potential candidate for future MIDIbox enhancements. E.g. the NodeMCU ESP32 available at Reichelt for 10 EUR supports Dual-Core (!) @240 MHz with WiFi and Bluetooth, 512k RAM, 4MB external Flash, incl. USB programmer on PCB - compare this with a PIC18F*! ;-) I started with Bluetooth, and the result can be found here: https://github.com/midibox/esp32-idf-blemidi This so called "BLE MIDI" service should work with any OS which supports this protocol. So far only tested on MacOS and iOS... but it should also work with Linux and Win10. This will be the basis for further experiments at my side - I'm able to communicate with the device via MIOS Studio. :-) (however, application download has to be done with the ESP32 ecosystem - means: the appr. esptool.py based bootloader) In future also a WiFi connections as demonstrated in Pedalino might be possible, but I'm not there yet - focus is on the application itself, knowing that the MIDI interface options won't be so fast like known from the STM32F4 based platform. E.g. how accurate can we control a Motorfader with the PWM LED outputs of a ESP32? If it works, it could be connected like a MBHP_MF_NG module via traditional UART based MIDI to a MIDIbox NG. And will it be possible to control a SRIO chain? Might be interesting for a future BLM16x16+X with (only) optional WiFi and Bluetooth connects. Best Regards, Thorsten.