TK.

I agree as well on both topics. Especially number 2 would match with my plan to make the menu selection in the bookmark file implementation-independent (provide names instead of numbers). So: once I've the names, it would also be possible to make everything which is related to pages configurable in a file without the danger that numbers are changing over different versions. Best Regards, Thorsten.

Are you using the MBHP_CORE_STM32F4 module, or a bare STM32F4DISCOVERY board? STM32F4DISCOVERY: you've to bridge the PA9 pin to the 5V input with a short cable: http://www.ucapps.de/mbhp/mbhp_core_stm32f4_standalone.jpg If MBHP_CORE_STM32F4 module: you've to stuff a jumper at J17 Best Regards, Thorsten.

No, there is no direct possibility available; because of the danger for multi-hop loops which has to be detected to avoid hang-ups I haven't implemented a solution for this yet (I fear that it could consume too much CPU time). I read somewhere in the forum that somebody just uses a HW loopback for this purpose: see Best Regards, Thorsten.

Ok, in this case I would prefer the simple slot option which works nicely together with the Slots in song page. The dedicated button would be called "QUICK_SAVE". Are there other opinions (from other users?) Would somebody use such a button? What do you mean exactly with the BLM pattern screen? It isn't possible to store patterns from a BLM16x16+X - is this really necessary? Do you own a BLM? Yes, I understand it this way and therefore will only provide a solution if multiple users request this and if we come to a conclusion. Best Regards, Thorsten.

Servus, generell ist das schon machbar, es sind jedoch einige Dinge zu beruecksichtigen: Core Modul: unbedingt STM32F4, da ist mehr drin fuer den Preis ;-) Das groesste Problem ist, dass Du ausgerechnet 9 Motorfader anstatt 8 anschliessen moechtest, denn das MBHP_MF_NG Modul ist auf 8 limitiert, Du wuerdest also zwei Module benoetigen (die Fader lassen sich nicht direkt ans Core Modul anschliessen). Mehrere OLEDs: vor allem Novski und Marxon haben Erfahrungen damit gemacht; Novski hat sogar eine eigene Wiki-Seite dafuer eingerichtet, auf der er sein VLR-8oDisp PCB beschreibt. Siehe auch: > Kurz gefasst: Kann der Controller so vollständig mit Cubase funktionieren? Ich bin leider kein Cubase User... > Lassen sich mit sysex-Befehlen theoretisch (notfalls durch ausprobieren) jede Funktion einer DAW steuern, die irgendwie durch einen anderen MIDI-Controller gesteuert werden kann? Bei Logic geht das bspw. (man kann mehrere Protokolle parallel fahren). Bei Cubase weiss ich es nicht. Gruss, Thorsten.

He means the project.hex file It can be found one folder above (same folder like the Makefile) Best Regards, Thorsten.

Hi Xavier, welcome on board! :smile: I just have doublechecked the usb_midi_2x2 application, it's working with various USB MIDI devices. Debugging: in this application the green LED should flicker whenever a MIDI event is received or sent, regardless from which MIDI port. Use it to check if your USB MIDI device sends messages, and that you are able to receive messages from a MIDI IN or OUT port. If this doesn't work, you could recompile the application with: #define MIOS32_MIDI_USBH_DEBUG 1 added to the mios32_config.h file This will enable some debug messages in mios32_usb.c which are sent to the MIDI OUT1 port and can be displayed by the MIOS Studio terminal. E.g. you should see a notification about the USB MIDI Device name, manufacturer, ID when the device is plugged in. Best Regards, Thorsten.

Well, both proposals don't really make the SAVE function more comfortable. Multiple key presses are required for this "safe save" handling, but actually you wanted a simplified solution. Back to a dedicated SAVE button, which you could somebody could assign to a free button (e.g. F1..F4) and/or to a bookmark? Best Regards, Thorsten.

Many proposals, but somehow they don't harmonize with the way how I would do this. E.g. I would never make a save function accessible from the PATTERN page - this page is intensively used during a live session, an unintended SAVE will hurt. Or predefined slots not only in the SONG, but also in the SAVE page... too much programming effort at my side for a single guy who requested this. Meanwhile I don't implement individual requests anymore, only if I see the potential need for many users, or some special need for myself. How about the following approach: in the SAVE page, press SELECT, then select A-H via GP#1..8 (if required), and trigger the save function by selecting 1-8 via GP button #9..16. This is similar to your request, but wouldn't be in the (dangerous) PATTERN page. And/or a dedicated SAVE button with the same capabilities? Parsing a long list from SD Card w/o RAM caching will slow down the user interface, and/or could affect the sequencer timings (especially if the sequencer loads from SD Card in parallel, e.g. the .mid file player). Doing some clever caching (pre-fetch entries depending on increments/decrements) is possible, but not worth the effort. So, I hope that a dumb "doesn't work" from my side is a sufficient answer for such a request. Best Regards, Thorsten.

The most simple way to save a pattern is in the main page: press EXIT, then GP#10: this will save the patterns of all 4 groups at once "Pressing a button twice" is not a good solution, because if a bad button is bouncing, you would store the pattern w/o a name unintentionally. It was my intention to use a different button, and it was intended that it doesn't trigger a destructive action, such as SAVE, Ins, Del...) However, with the SAVE function in the main page, I guess that your request is already satisfied, no? Maybe there is a better way that you probably haven't explored yet. This was an outcome of a discussion with multiple users - we wanted to achieve a comfortable save function and a well structured bank (so not just picking up a random free patch slot. This feature was introduced with V4.077 (see changelog): o a very useful "quick save" function has been added which significantly improves the song phrases handling. The new function will store the current mixer and pattern setup into predefined bank positions: - Phrase A will use Mixer Map #1 and Patterns 1:A1 2:A1 3:A1 4:A1 - Phrase B will use Mixer Map #2 and Patterns 1:A2 2:A2 3:A2 4:A2 - Phrase C will use Mixer Map #3 and Patterns 1:A3 2:A3 3:A3 4:A3 - ... - Phrase P will use Mixer Map #16 and Patterns 1:B8 2:B8 3:B8 4:B8 After the store operation, following references will be copied into the phrase slot of the song: - 1st phrase step: the current mutes - 2nd phrase step: selects the new mixer map - 3rd phrase step: selects the new pattern set - 4th phrase step: jumps to the 3rd phrase step (could be useful in song mode) How to use this function: Start a new session, edit some tracks, start jamming. Whenever you've found sequences which play well together, change to the SONG page, press&hold the SELECT button, then select "Save&Take over Patterns" with GP button 16. Thereafter release the SELECT button, and select the target phrase slot with one of the GP buttons -> this will store the current mutes/mixer map/patterns into the predefined bank positions and insert references into the phrase slot. Now you can continue jamming, change tracks, change mixer values, change mutes. Whenever you found a new nice working sequence, go to the SONG page and store it into another phrase slot (or overwrite an existing slot). The stored phrases can be restored as usual with the GP buttons in the song page. Interesting idea ;-) This would consume RAM memory, but there is not enough memory free on a MBHP_CORE_STM32 or MBHP_CORE_LPC17. I could add this feature to the "MIDIbox SEQ V4 Plus" request list (MBSEQ V4 Plus will require a MBHP_CORE_STM32F4), but it could mean that then I've to refuse other feature request which consume memory as well. How important is this idea? What do other users think about this? Good idea, added to the Wishlist: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2FCHANGELOG.txt Best Regards, Thorsten.

A new version is available: MIDIbox NG V1.031 ~~~~~~~~~~~~~~~~~ o the STM32F4 variant of the firmware supports USB Host mode! See also o MIDI clock input ports now disabled by default to avoid feedback loops in various setups o improved "ain_filter_delay_ms" implementation to support sensors (experimental stage) o Covered new use case which allows to transform velocity values of incoming notes. See cfg/test/conev_6.ngc EVENT_RECEIVER and EVENT_SENDER have to be specified with "key=any", so that any key will be received and sent. o support for DIN/DOUT emulation on digital IO ports J10A/J10B (LPC17: J10/J28) See examples in cfg/test/diocfg_1.ngc and cfg/test/diocfg_2.ngc Best Regards, Thorsten.

Hi Przemek, hm... at least I can say that this isn't related to the software, especially because all inputs are debounced. Maybe buttons and encoders are damaged, e.g. because the guy who soldered the components overheated them. E.g. I had a similar problem with a button which is also used in the sammich devices and had to replace it. Best Regards, Thorsten.

Hallo Julian, vermutlich hast Du die Device ID (ueber dem Query Button) verstellt. Sie sollte auf "0" stehen. Gruss, Thorsten.

Fine! :) The J10 ports overlay DIN shift register positions. So, with this default example DIN 1 and 2 wouldn't have a function anymore. If somebody would add a MBHP_DINX4 module, and still would like to use the J10A/B based inputs, he would change the emu_din_sr parameter to higher numbers (of unused DIN SR positions) No, this isn't possible. Just build the Low-Cost adapter as documented here: http://www.ucapps.de/mbhp_sdcard.html Best Regards, Thorsten.

Great! Thanks also for the detailed report. I guess that sooner or later somebody else with similar interests will come back to us. :) > Is that easy to "just" remove the PID controller in the MF soft and assign output not to the PIC PWM but AOUT ? yes, this would be easy. Do you have a schematic of the PID controller? Best Regards, Thorsten.

@stuartm: V4.084 got a new function which helps to overcome this issue. In the UTIL->Options page you can define the order at which particular CC layers are sent (before or after program change). @Luke: I haven't changed the format in the last years... this seems to be an unintended change. Could you please send me one of your preset tracks so that I can compare? And do you remember with which version you created the problematic tracks? Best Regards, Thorsten.

Cool! :) I've released a new version of the usb_midi_2x2 and usb_midi_4x4 application which supports the USB MIDI host mode. It's the most simple application for this purpose. Best Regards, Thorsten.

Maybe the number is too high so that an overrun happens? Which note is played when you are using din_key_offset=1 which note when you are using din_key_offset=2 and 3... and 4... are you able to increase it until the expected note will be played? At which value an unexpected note will be played? Best Regards, Thorsten.

Hi Marc, from the HW side it should be possible with MIDIbox NG. But do you already know, if these parameters are accessible via MIDI? Best Regards, Thorsten.

Hi, the encoder behaviour has been improved in an unreleased MIOS8 and MBSID version. Please join the beta test! :-) An update is very easy: install MIOS Studio (if not done yet): http://www.ucapps.de/mios_studio.html Connect MIDI IN/OUT of your MB6582 to your computer, open MIOS Studio, select the MIDI interface, try the bidirectional communication with the "Query" button. If working, first upload the new MIOS V1.9h version, thereafter the new MIDIBox SID application. Both are linked in this posting: Best Regards, Thorsten.

Hi Chris, did you enable the FANTOM_XR_VARIANT switch in keyboard.c? In fully customized variant the din_key_offset parameter isn't considered. Best Regards, Thorsten.

Of course, providing something to such an audience is a nice motivation :smile: (as long as the requests don't get too illusory or clash too much with given concepts ;-) Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_031_pre3.zip Configuration examples can be found in cfg/test/diocfg_1.ngc: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fdiocfg_1.ngc and cfg/test/diocfg_2.ngc http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fdiocfg_2.ngc I haven't tried this, but with this new feature is should also be possible to scan a 8x8 DIN *or* a 8x8 DOUT matrix (unfortunately 3 8bit ports would be required to scan a 8x8 DIN and DOUT matrix at the same time). Best Regards, Thorsten.

The wishlist is located at the bottom of this file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2FCHANGELOG.txt But I only take over requests where I think that they are useful for myself, and/or the implementation & testing isn't so difficult. When you don't find certain functions in the documentation, then it's very likely not available. Either because nobody requested such a function yet, or there is a conflict with another function which you've overlooked. When you are writing "Cant find any documentation about it" it sounds to me like a complaint, and not like a request! :no: J10B (on MBHP_CORE_LPC17: J28) is typically used as extension port for CLCDs/GLCDs. Normally I prefer to use the ports only for a single purpose to avoid conflicting configurations which could lead to the next request from somebody else to make it somehow possible without considering what it means at my end. I spend some thoughts about possible solutions anyhow, and came to the conclusion that the most simple way would be to provide a new function which maps J10A/J10B to DIN or DOUT shift registers (some kind of "shift register emulation") E.g. with: DIO port=J10A emu_din_sr=1 DIO port=J10B emu_din_sr=2 I could provide the possibility to handle J10A and J10B pins the same way like pins of the first and second DIN shift register (id=1..16) Advantage: this would work completely transparent for the firmware, so that encoders could be connected as well, and configured like if they are connected to shift registers. With: DIO port=J10A emu_din_sr=1 DIO port=J10B emu_dout_sr=1 it would be possible to use J10A for buttons (id=1..8), and J10B for LEDs (id=1..8) Is this the right direction, or do you have something else in mind which conflicts with this approach? Best Regards, Thorsten.

Yes, this works: But as you can see in the schematic, the emulated soft1 button is at J10A:D3 = PE11 and not PE8 PE8 (=J10A:D0) is the first encoder pin. Best Regards, Thorsten.

Fine! :) Yes, 10k pull-ups are too weak for the LCD signals, therefore I recommend 1k Best Regards, Thorsten.