TK.

Yes, this could explain the behaviour (and based on that what I see on the video, I can say that this isn't normal) Please try it with a proper MIOS and MBSID installation: - power-off the sammichSID - load the mios_v1_9h/pic18f4685/midi/mios8_v1_9h_pic18f4685.hex file - press the Start button - now power-on the core -> upload should be finished within ca. 10 seconds After MIOS has been installed successfully, the MIDIbox SID application can be uploaded without this special trick. Btw.: is your MIDI interface on the blacklist? -> http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist Best Regards, Thorsten.

No; the notes which are visible on the screen will be transposed, just straightforward without special dependencies. And the firmware uses the standard function to change octave/semitone transpose values, the function itself takes care for multi-track selections. Which means: if you notice such a problem in the transpose page, you would notice the same in most other pages where the standard function is used. Could you please explain a bit further what you mean with this? It would really be helpful if you could explain the steps which are required to reproduce the problem, such as: - power-on - MENU+GP7 (Transpose) - Push&Hold Track1, Push Track2: both tracks should be selected - press GP10 to change Octave Transpose from +0 to +1 I tried the "TUTOR2" session that you gave me, but without success - meanwhile I assume that we are speaking about different pages. Ok, this is an easy enhancement and it's also no critical change, since people who want to use the function have to reconfigure track assignments (so: they have to know what they are doing) -> no compatibility issues to be solved. Try this version: http://www.ucapps.de/mios32/midibox_seq_v4_089_pre2.zip Change to the Menu+GP9 (Trigger) page, disable the Roll trigger assignment (normally C), and assign RollGate (displayed as "RollG" under GP10) to C -> rolls will only be played if the RollGate is set, and the Roll or Roll2 parameter layer doesn't show "----" for the step. Best Regards, Thorsten.

Both tracks get transposed at my side, regardless in which order the tracks have been selected. Just to be sure: can you transpose the first track when only this one is selected? Could you please pack your session subdirectory into a .zip file and attach it to this thread? Best Regards, Thorsten.

It was just an assumption... I don't know (and I'm too lazy to install Ubuntu14 in order to check your source files there) Let's see if anybody else has an idea what could cause the warnings that seem to worry you. Best Regards, Thorsten.

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.