TK.

I'm planning to implement some kind of compiler, which translates the .ngr commands into opcodes stored in RAM and executed dramatically faster than today. So, if performance is the only issue, it will be solved sooner or later (but not in the next two months) Best Regards, Thorsten.

The simple bank mechanism won't help you to achieve this. Instead, you've to activate/deactivate the events from a run script: http://www.ucapps.de/midibox_ng_manual_ngr.html with the "set_active" command This approach can result into a long list of commands, but it's the most flexible solution... Best Regards, Thorsten.

It wouldn't surprise me if you are getting warnings when you are using a different gcc version. Even more dangerous are the hidden differences which are only visible by running the code and could result into a lot of trouble! Therefore I strongly recommend you to use the official MIOS32 toolchain which is located under: http://midibox.org/mios32_toolchain/ All other versions are unreliable. Best Regards, Thorsten.

The USB descriptors of MIOS32 match with the descriptors of the official usbmidi interface spec, no special tricks have been used, and Windows/Linux/MacOS are happy with them. So, if another Host doesn't connect, it's an imperfection in the Host driver and you've to report this to the appr. manufacturer, not me! In any case it always makes sense to check, if the manufacturer already fixed the bug in a newer driver version based on customer feedback... Best Regards, Thorsten.

whenever you want to print floats with %d, you've to cast the appr. variable to integer with (int)variable, e.g. (int)value Best Regards, Thorsten.

This is 5V, Ground, D+ and D- (protocol lines) If 5V isn't properly connected to the appr. USB pin, then a similar effect could happen as well; core will be supplied via D+ in this case, but it's only a "weak" power path. So: check especially the USB pin connected via J17 jumper to 5V! Best Regards, Thorsten.

The slow power ramp-up is very unusual, actually the 3.3V should be available immediately (less than 1 second) - of course, this is the answer for strange firmware effects, but a firmware change won't help to fix this problem! The rectifier can't cause such an effect, it's more likely a problem with your external PSU. Could you please try a different USB hub? Or alternatively power the core directly from a 7..10V PSU via J1 (remove the J17 jumper for this option) Best Regards, Thorsten.

I need your configuration files to reproduce this. However, as you may have noticed, I'm currently too busy with other things and therefore can only help on issues which are easy to clarify. This looks like a complicated issue where even firmware changes might be required; I fear that I can't look into this the next two weeks... :-/ The configuration files will be helpful anyhow... Best Regards, Thorsten.

yes, this is more than enough this was an issue many many years ago, it's solved and confirmed by many many people. check the date of postings first before starting such experiments, because you don't know the dependencies under certain circumstances it could screw up the installation (e.g. SD Card config files, USB driver interaction with Windows, etc) Use the current firmware, other versions won't help to find the issue and could cause new issues. A 74HC595 has to be used, the 74HCT595 won't work reliable, confirmed by some users that 74HC595 is the better choice. That's the reason why you find this chip in the schematic: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf (just to repeat:) the change is already in the firmware since some years. It could make sense to check your hardware if certain devices are removed. E.g. did you already remove the MBHP_IIC_MIDI modules from J4A? If they are faulty and cause a short circuit after power-on, similar behaviour could be observed... And what happens if only a single LCD is connected? Best Regards, Thorsten.

Great work! :) Did you consider to use footswitches for controlling recording and loop points? See this video for a usage demo: Best Regards, Thorsten.

This is correct, it wasn't clear that you don't like this effect. Maybe it helps you to use conditional events instead of the bank mechanism, it would allow you to enable/disable EVENT_MF depending on the state of another item, such as a button. More information can be found in the user manual: http://www.ucapps.de/midibox_ng_manual_ngc.html search for "conditional events" Best Regards, Thorsten.

The firmware is quite stable, it can't cause such effects, resp. it works for many other users. Could it be a power supply issue? Maybe your USB based PSU is too weak for the MBSEQ? I recommend the usage of an externally powered USB hub. Best Regards, Thorsten.

Use the Echo Fx, it works the same way. Best Regards, Thorsten.

It works at my side, e.g. select Track 2 & 3, go to transpose change -> octave and semitone transpose changes take place for both tracks. I need more information to reproduce the issue. no problem here - could it be that there is a problem with the buttons of your MBSEQ? Does this also occur with other trigger switches, or only with Roll? Well, where should such a configuration item be placed... finding free places in available pages is the biggest issue ;-) However, did you know that roll can also be controlled from a parameter layer? This gives you much more freedom (-> more variance) Actually the trigger layer based roll only exists due to legacy reasons, the parameter layer based Roll/Roll2 is much more useful Best Regards, Thorsten.

Yes, it's class compliant. But some MIDI hosts have problems if two interfaces with the same name are connected. You could give one board a different name via the bootloader update app. See http://www.ucapps.de/mios32_bootstrap_newbies.html search for "name" Best Regards, Thorsten.

Wie gross ist das Delay zwischen den Sequenzern, und bleibt es gleich, oder variiert es mit jedem Play? (am einfachsten laesst sich das Delay ausmessen, indem man die von den Sequenzern generierten Klaenge aufnimmt, und Waveforms miteinander vergleicht) Gruss, Thorsten.

Hi Partrice, interesting hack! :smile: The sequencer core calculates the resulting delay as: t->bpm_tick_delay = (delay * t->step_length) / 96 This explains why you had to divide by 4 The correct formula which also works with different clock dividers should be: delay = ((SEQ_BPM_TickGet() - t->rec_timestamp) * 96) / t->step_length; if( delay >= 96 ) delay -= 96; // because quantisation has put the event into the next step (untested) Best Regards, Thorsten.

You could use banks for this purpose: put one EVENT_MF into the first, another EVENT_MF for the same fader into the second bank, and switch between the banks with a button. Best Regards, Thorsten.

Hi Bartosz, I'm relieved that you found a way with the current firmware, because I've no explanation which change could have caused such kind of incompatibility. :-/ Best Regards, Thorsten.

Great work! :) And I'm not surprised that you added some bling as well ;-) For multi-channel recording I would recommend a different approach: with each loop, just record the old and new MIDI data into a new file, switch to this file with the next loop and delete the old file. Alternatively store the MIDI data in SRAM (STM32F4 memory is large enough for this purpose) Best Regards, Thorsten.

Are you working under Windows? It sounds like the typical USB communication issue which occurs once an application (like MBSEQ) provides multiple MIDI IN/OUT ports. This can either be solved with the "single_usb" option - see http://www.ucapps.de/mios32_bootstrap_newbies.html Or with an alternative USB MIDI driver like GM5 - see bottom of this page: http://www.ucapps.de/mios_studio.html Best Regards, Thorsten.

The configuration doesn't look correct. From the source code: __CONFIG _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_ON & _MCLR_OFF & _PWRTE_OFF & _WDT_ON & _HS_OSC __CONFIG _CONFIG2, _IESO_OFF & _FCMEN_OFF required changes in your config flags: disable the LVP flag enable the BOREN flag disable the MCLRE flag disable FOSC2 enable the WDTEN flag enable FOSC1 disable FOSC0 (FOSC[2:0] is 010 for HS oscillator) Best Regards, Thorsten.

I could program the PICs for you, just send me a PM to get my postal address. Best Regards, Thorsten.

The MIDI protocol doesn't allow to send values >= 0x80 in a stream, but I can see two 0xff in your configuration. Following configuration should work: EVENT_MF id=1 hw_id=1 type=SysEx stream="0xF0 0x7F ^dev 0x70 0x02 0x7F 0x06 0x00 0x01 ^val ^val_h 0xF7" Best Regards, Thorsten.

Thanks for the reminder, but it isn't implemented yet The firmware is currently in a phase where I had to do some hotfixes and need feedback from users if the existing functions are still working correctly. Please help me to test the latest firmware with your MIDIbox: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre7.zip Best Regards, Thorsten.