TK.

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.

@lp1977 MIDI file export should consider this option now, could you please try at your side? -> http://www.ucapps.de/mios32/midibox_seq_v4_096_pre9.zip Best Regards, Thorsten.

Hi, finally found time to go through this thread... ;-) First of all: the SysEx string contains an "illegal" value: 0xE0 Values >= 80 should not be sent, because they will be interpreted as a new MIDI status. Second: you could simply toggle between the two values 0x10 and 0x01, and insert it into the SysEx string via ^val: EVENT_BUTTON id=1 range=0x10:0x01 button_mode=toggle type=SysEx stream="0xf0 0x00 0x01 0x16 0x10 0x18 ^val 0xf7" Best Regards, Thorsten.

@lp1977thanks for the information! Problems are understood and fixed in: http://www.ucapps.de/mios32/midibox_seq_v4_096_pre8.zip @sis.tmjust tried at my side, it works! (and sometimes I'm surprised what can be done without special consideration in the sources ;-) assign track to CV in LFO page, set the ExtraCC# to 16..23 16 will send to CV channel #1, 17 to channel #2, etc - which means: with the CC number you can address the CV channel you would like to use as LFO output Best Regards, Thorsten.

Thank you! :) I'm too busy at this moment, but will have much more time for MIDIbox in December :) Best Regardsm Thorsten.

Without a model of the IC an academic discussion isn't possible. Simple measurements would help to understand the internal circuit. Best Regards, Thorsten.

This isn't correct, see also the SN74HC595DR datasheet: http://www.ti.com/lit/ds/symlink/sn74hc595.pdf Output drive current is 6 mA, which means in other words: you've to add an internal resistance of ca. 800 Ohm to the calculation. This could be doublechecked by clamping an output to ground, and measuring the current draw while the pin is set to logic-1. Best Regards, Thorsten.

That's the reason why I haven't listed J10A/B in my requirements list - it's just important to have a standard control surface (SCS), otherwise applications won't be re-usable. The 6 buttons + encoder could also be connected to an on-board DIN SR, connected to J9 as the first SR in the chain. Would be happy to evaluate it. Best Regards, Thorsten.

Yes, I think it's only a display problem in MIOS Studio, I should change this to a decimal value. Best Regards, Thorsten.

Must-have requirements: STM32F407VG (1MB flash) SCS with 6 buttons, 1 encoder and 1 GLCD (so that we can also use the display as a scope) 1 MIDI IN, 1 MIDI OUT USB Device SD Card SRIO (J8/9) J19 for AOUT 50mm depth HP doesn't matter as long as it still fits into the Pod40X case together with the Expander modules Optional: up to 3 additional MIDI IN/OUT (could also be provided as an optional module) USB Host 4 on-board LEDs Audio-DAC Potential extension modules: SRIO based encoder/ledring modules AINSER64 module (with at least 8, but maybe 3x8 INs?) - inputs should be buffered, protected and maybe also amplified and level-shifted for +/- 5V Such a module could also cover MBNG for script based processing. Best Regards, Thorsten.

@Antichambre very nice! Does it provide J8/9, J10A/B and J15A? (For J15A the pins for GLCDs with serial interface might be sufficient) @latigid ondepth >50mm isn't suitable, it won't fit into my case; I guess that this limit is considered by most Eurorack modules. Best Regards, Thorsten.