TK.

New release: Best Regards, Thorsten.

I don't think that you need a new STM32F4. It would be interesting if you still notice the same issue under MacOS. Please use one of my latest prebuilt binaries for reference, e.g. this one: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre4.zip You can upload the .hex file directly with the ST Link tool (under Windows) - it contains the bootloader + the MIDIbox NG application. If no success: we should continue the troubleshooting under MacOS (I will give you further instructions in this case) If success: try also under Windows. If the USB device is not recognized, you could uninstall the MIDI driver assigned to the USB port somewhere in the system settings, and re-connect the USB cable. This enforces a driver re-installation which might help. Btw.: did you already try another USB cable? I remember that there a Micro-USB cables which are only intended to supply power, e.g. for recharging mobile phones. They can't be used for the USB connection itself! Best Regards, Thorsten.

Welcome on board & have a lot of DIY fun! :) Best Regards, Thorsten.

Hi David, yes, the second AOUT based gate should work (but I haven't tested it yet - I only use DOUT pins in conjunction with a AOUT_NG board). However, I just checked the MIDI channel selection with the Lemur patch and noticed that the value display wasn't accurate. In a certain range Channel 2 was displayed, but actually Channel 1 was still selected. I fixed this (for all dials) by surrounding the calculated value with floor() - this seems to work now The updated Lemur template can be found in the repository (I hope that I haven't damaged something because I manually edited the .jzml file instead of doing the changes in the editor) DOUT pins: there is no interconnection test available for MIOS32, but maybe the Lemur update will already help to clarify this. Note that the first gate is available at D7, the second at D6, etc... Best Regards, Thorsten.

Hi Robin, I'm not sure why the wget command itn't working. Could you please try to download the file from your webbrowser? (just click on the link) Best Regards, Thorsten.

Hi, it seems that you are trying to upload SysEx with a bad MIDI interface. Please check the blacklist: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist&s[]=whitelist There is also a whitelist: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_whitelist The recommended "least cost" interface is Neusonik uMIDI/O22, available for 15 EUR e.g. from Thomann: http://www.thomann.de/de/neusonik_umidi_o22.htm Best Regards, Thorsten.

Hi Bartosz, this is a quite old posting, did you solve this meanwhile? I'm a bit unsure if a SD Card will be required for these tests - it shouldn't, but to be honest: I never tried out a keyboard without writing the definitions into a .NGC file. It might be required to enter "RESET_HW" before these commands to ensure that no other configuration overlays the keyboard functions. Best Regards, Thorsten.

:flowers: Best Regards, Thorsten.

The default settings are available in the hwcfg directory of the release package. You can also access it from the web: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fhwcfg%2F Best Regards, Thorsten.

Added to the wishlist, setting will be stored in one of the next releases. Best Regards, Thorsten.

I guess that this issue has been solved meanwhile, right? Best Regards, Thorsten.

Hi, you can configure this in the MENU->MIDI "Ext. Ctrl" page. With GP Button 12 select the "PrgChange" function, and set the mode to "Pattern". In the same page you can define the MIDI IN port and Channel over which the Program Change event should be received. Best Regards, Thorsten.

Meanwhile this configuration can be done in the Util->Options page, Option 5/13 called "Dump a predefined Mixer Map on Pattern Changes: disabled/enabled". You've to enable this function. Does this help? Best Regards, Thorsten.

Hi, unfortunately you can't simply add this chip to the SRIO chain because of a dedicated protocol which has to be used. It requires some programming knowledge to support it MIDIbox NG, I can't help you on this topic in the next weeks... It will be easier if you would just use a PIC based MIDIO128 V2 and connect it to your MIDIbox NG via MIDI. Especially since MIDIO128 V2 supports up to 128 touch sensors, not only 8! Best Regards, Thorsten.

Hi Robin, please use a qualified MIOS32 toolchain release, and not anything else found somewhere in the internet. The packages for Windows, Linux and MacOS can be downloaded from: http://www.midibox.org/mios32_toolchain/ Best Regards, Thorsten.

Yes, definitely a MBOTW! I'm happy that there are still people who build a MIDIbox from scratch for total customization - well done! :thumbsup: Hint: if you set the DEFAULT_LCD_LINES parameter to 4 in your setup_*.asm file, and rebuild the application, the 4x20 display will show more informations. Best Regards, Thorsten.

Hi Robin, Tutorial 005 is working at my side with a STM32F4 core. It's important that you compile the application with the right MIOS32 toolchain release which is available under: http://www.midibox.org/mios32_toolchain/ Best Regards, Thorsten.

It's the default behaviour that note assignments will be reset with the CLEAR function. You can change this behaviour in the options page (e.g. UTIL->Opt): select the option 8/13 "Paste and Clear button will modify Only Steps" (and not "Complete Track") Recovery from a preset works at my side. It's important that the Cfg import is selected with "Yes" in the PRESET page (during the import steps), otherwise the previous drum note map will be kept. This means that you've enabled the FTS option in the Opt->Live page for runtime scaling. It's normal that the recorded notes are not scaled but reflect the original entry. Can you please doublecheck that the track specific ForceScale option is enabled in the MENU->MODE page? (it's not called "FTS" there) Best Regards, Thorsten.

Should be lpc175x_6x (setting works for LPC1750..LPC1769) Best Regards, Thorsten.

Hi, very strange, especially since this even happens under MacOS (which is the least problematic OS with the most robust MIDI drivers) Could you please doublecheck that you are using the right STM32F4DISCOVERY module? There is a downstripped version available with a similar name and pinout, but it's only stuffed with a STM32F401 You need a STM32F4DISCOVERY board with STM32F407 > Or perhaps some residual code somewhere if it connects under boot hold? No... only difference: it's a separate USB MIDI driver without USB Host support, and it's located in the first flash sector which also exists in the STM32F401 - therefore the assumption above. Best Regards, Thorsten.

Great that this fix solved the problem! :smile: MBSID: project is still in hypersleep mode, I just migrated the AU and VST to a newer Juce version in the hope that it works more robust, but the VST still seems to be unstable - nothing for a public release, going into sleep mode again ;) Best Regards, Thorsten.

Das ist bereits moeglich, und zwar fuer jeden einzelnen Step frei definierbar - selbst mit einem negativen Delay: Das dann eben auf Microtick Basis, was jedoch fuer ein tempo-unabhaengiges Groove Template auch Sinn macht (hier moechte man nicht mit absoluten Zeiten rumrechnen). Im Grunde wuerde ein Custom Groove Template bereits Deinen Anforderungen genuegen, es ist jedoch umstaendlich zu handeln, da Du die Konfiguration fuer jeden einzelnen Track vornehmen muesstest, und fuer jedes neue Pattern neu zuweisen muesstest. Deshalb waere es wahrscheinlich besser, einen Port-bezogenen globalen Delay-Parameter anzubieten, der fuer die gesamte Session gueltig ist. Gruss, Thorsten.

Die von Hawkeye vorgeschlagene Loesung wird in diesem Fall leider nicht weiterhelfen, da die MIDI Verzoergung lediglich 1 mS betragen wird. Egal ob V3 oder V4 Firmware, eine zeitbezogene Verzoegerung laesst sich nur sehr schwer in die Firmware einbauen, da der Scheduler den MIDI Takt als Referenz nimmt (was gegenueber klassischen Sequenzern Vorteile bietet, vor allem im Slave Betrieb). Das Einzige, was ich evtl. in die V4 einbauen koennte waere ein "MIDI Clock Microtick" Delay, das dann jedoch vom Tempo abhaengt. Bei 120 BPM und 384ppqn dauert ein Microtick ca. 1.3 mS, mit einer Verzoegerung von 8 Microticks waeren also fast 11 mS erreicht. Bei 140 BPM waeren es dann nur noch 1.1 mS, Du muesstest das Delay dann auf 10 Microticks einstellen. So muesstest Du dann fast alle Tracks verzoegern, nur der MPX16 sollte die MIDI Meldungen unverzoegert erhalten. Zu umstaendlich? Ich denke schon! ;-) Nachtrag: ok, man koennte das Delay als Zeit in mS eingeben, und MBSEQ koennte die Microticks in Abhaengigkeit vom Tempo selbst ausrechnen. Das waere von der Usability her dann evtl. doch noch tragbar. Die MPX16 Latenz ueberrascht mich uebrigens nicht, beim MIOS32 basierten Sample Player (der ebenfalls direkt von SD Karte abspielt -> ) gibt es ein aehnliches Problem, hier konnten wir die Latenz jedoch mit Hilfe eines Tricks zumindest halbieren. Gruss, Thorsten.

Koenntest Du mal das Delay ausmessen, und zwar bei verschiedenen Tempos? So laesst sich herausfinden, ob der MPX16 ein Problem mit der MIDI Clock hat. Ausmessen geht am einfachsten, indem beide Geraete gleichzeitig eine (kurze) Note erhalten. Die Audiosignale nimmst Du dann mit einer DAW auf, und dort ermittelst Du dann auch den Abstand zwischen den gespielten Sounds. Gruss, Thorsten.

:thumbsup: