TK.

Hi Jasper, unfortunately it won't be so easy to add such an option to the firmware. However, if you are already using a STM32F4 core module, there is hope that the MIDIbox SEQ V4+ Firmware could support "free-style" tracks :) But I won't start to work on this before end of this year (and I already postponed the start of development by +1 year) Best Regards, Thorsten.

Thank you for the video, more please! :) I will collect them and publish in the tutorial: http://www.ucapps.de/midibox_seq_manual_tut.html Best Regards, Thorsten.

Hi Bartosz, do you still notice the issue? If not, I will push the release button. Best Regards, Thorsten.

I'm not aware of this - maybe the MIDI load is too high on each port, and the I2C peripheral of STM32F4 can't handle the throughput anymore? Does this only happen under high load, resp. does the problem disappear if you change certain tracks to other MIDI ports? Best Regards, Thorsten.

Tja, ich verstehe das leider auch nicht. Microsoft hat es auch nach 15 Jahren noch nicht geschafft, einen stabilen USB MIDI Treiber bereitzustellen, und bei den Herstellern gibt es viele Dilettanten, die ein Produkt ohne ausgiebige Qualitaetssicherung auf den Markt werfen... die dann leider auch noch jahrelang auf Ebay rumgeistern, weil sie niemand gebrauchen kann. Das perfekte Fertig-Produkt war bisher das Neusonik uMIDI/O22 fuer 15 EUR. Leider war es auch schnell ausverkauft, nachdem wir es auf die Whitelist gesetzt haben. Seitdem habe ich nichts vergleichbares in dieser Preislage gesehen. Gruss, Thorsten.

Alright, the new version is released now: MIDIbox KB V1.016 ~~~~~~~~~~~~~~~~~ o Support for AINSER8 module It has to be connected to J19; chip select line RC1 will be used (set jumper J4 accordingly) In the AIN configuration it can be selected as pin 128..135 o added 4th AIN pin for "expression pedal" (CC#11 by default can be re-assigned). and the documentation has been updated: http://www.ucapps.de/midibox_kb.html This was already described with some examples in the documentation (search for "midi_ports") Best Regards, Thorsten.

Nobody requested this so far, the firmware was not prepared for this, and therefore it wasn't available. (or did you find this somewhere in the documentation?) However, here it is: http://www.ucapps.de/mios32/midibox_kb_v1_016_pre2.zip The 4th analog pin is called "expression pedal" and assigned to CC#11 by default (but the CC can be changed) Some of your old configuration settings (especially delay values for black keys) will get lost once you upload the firmware, you've to reconfigure them. Best Regards, Thorsten. P.S.: I won't have the time to add new features in the next 2 months. I will only implement urgent bugfixes in the next weeks

Seems that you want to introduce help texts with longpressed keys - I don't really want to start with this, because either this has to be supported everywhere, or nowhere - I prefer nowhere, since "push&hold" functions are sometimes used for other purposes. A common user won't understand the purpose of the GTE function without a more detailed documentation anyhow. I think that it would be better if there is a tutorial in the Wiki (written by you, because you initiated this feature ;-) which describes your use case, and how the generator has to be prepared to work properly. Here the entry point for the documentation: http://www.midibox.org/dokuwiki/doku.php?id=mididocs:index In order to set all gates, and to clear all notes of parameter layer A, just use the ALL function in the edit page. UNDO: press COPY before the operation, press PASTE if you want to undo the change. Best Regards, Thorsten.

Please test it at your side: http://www.ucapps.de/mios32/midibox_kb_v1_016_pre1.zip o Support for AINSER8 module It has to be connected to J19; chip select line RC1 will be used (set jumper J4 accordingly) In the AIN configuration it can be selected as pin 128..135 Best Regards, Thorsten.

Which configuration capabilities do you need for a AINSER8? If predefined CCs should be sent, it would be an easy enhancement, if more flexibility is required, more work has to be done and this has to be properly discussed (because from the past I know that sooner or later you will ask for a "very important missing feature" which contradicts with the concept and then will result into a lot of work to support a special option for you...) Best Regards, Thorsten.

Ein character LCD sollte die Zeichen eigentlich ziemlich schnell ausgeben (in 20..30 uS wenn ich mich richtig erinnere), ueber MIDI kommt jedoch nur alle 320 uS ein neues Zeichen. Somit ist es evtl. doch kein Problem mit der Zeichenausgabe, und Du kannst den Code erstmal so lassen wie er ist. Wie vertrauenswuerdig ist eigentlich das MIDI Interface, das du verwendest? Koennte es sein, dass bereits bei der Uebertragung zum PIC Daten verloren gehen? Am einfachsten laesst sich das mit einem hardwaremaessigen MIDI Out->IN Loopback am Interface ueberpruefen. Sende mit dem SysEx Tool die Daten, und ueberpruefe, ob sie auch wieder komplett empfangen werden. Gruss, Thorsten.

Euclid generator enhancement: there is a general problem with this idea Currently the generator just enables/disables the gate based on the selected pattern. This has the advantage, that we can prepare all steps with different note values (in all available parameter layers), and play them based on the euclid pattern selection. The same approach isn't possible if notes should be enabled/disabled in a dedicated parameter layer. Instead, the only simply way I could imagine would be to leave the gates untouched, and to overwrite the parameter layer with a selectable note value, which is set whenever the normal function would set a gate, and cleared (0) whenever the gate wouldn't be set In distance to the original function, this would be a destructive change, which means that previous note values of the layer will get lost. But the actual problem is, that the note pattern written into the parameter layer won't be played according to the euclid pattern since it has no individual gate! Notes will only be played if the gate is set Please try following version, it will be easier to understand the problem just by trying out: http://www.ucapps.de/mios32/midibox_seq_v4_089_pre4.zip - change to euclid generator - ensure that the first parameter layer is selected - select 5 Pulses - now change to another parameter layer which plays notes with GP4 encoder - change the note value so that you can differ between the one played by ParA with GP5 encoder - change pulses for this layer with GP10 encoder -> at the right side of the display each note which can't be played due to a missing gate will be marked with '-' Currently I only see one solution at the user side: - in parameter layer A, enable the gate for all steps and disable all notes (set them to "---") - use the remaining layers to play different notes based on different euclid patterns Other ideas? Best Regards, Thorsten.

Today I spent some time to analyse this issue. Unfortunately I wasn't able to reproduce it at my side (are you using a MBHP_CORE_STM32F4, or MBHP_CORE_LPC17 module?) However, I found a potential with the Snapshot Meta event: it didn't use a Mutex while accessing the SD Card, with the danger that any other task could try to access it concurrently. This would result into the error message that you mentioned. Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre8.zip For the second issue I changed the Snapshot Dump, so that LCD output will be inhibited during dump, which should result into a more deterministic behaviour Best Regards, Thorsten.

ok, this is easy ;-) Added to the wishlist No, but since there is no better idea yet, I finally added it to the wishlist Euclid generator: allow to select the note layer into which the pattern will be copied ok, added to the wishlist as well so that it doesn't get lost Best Regards, Thorsten.

No, currently this isn't possible Best Regards, Thorsten.

Hi Jasper, no, unfortunately this isn't possible because of the way how MBSEQ stores MIDI events. It would require a different concept to store the data (like on a pianoroll known from DAWs) with the disadvantage that some step based features wouldn't work anymore. Best Regards, Thorsten.

Hallo Andre, Du verwendest ein graphisches Display, richtig? Dann dauert die LCD Ausgabe zu lange. Abhilfe: die Zeichen in einem RAM Buffer zwischenspeichern, und im LCD Handler ausgeben. Hier hat man dann die Zeit, die fuer die Display-Ausgabe spendiert wird, besser unter Kontrolle. Ich weiss jetzt nicht auswendig, wie lange die Ausgabe bei GLCDs dauert (das haengt vom Display-Typ ab), doch der PIC sollte nicht mehr wie 10 mS spendieren, ansonsten laeuft der MIDI IN Buffer ueber (der kann in dieser Zeit ca. 30 Bytes empfangen) Die LCD Ausgabe sollte also so aussehen, dass der LCD Handler im RAM Buffer nach neuen Zeichen sucht, sie ausgibt, und nach (bspw.) 10 Zeichen abbricht. Wenn er erneut aufgerufen wird, kann er die restlichen Zeichen abarbeiten, bis der Display-Content mit dem RAM Buffer uebereinstimmt. Wie erkennt man neue Zeichen? Am einfachsten, in dem man im Buffer die bereits ausgegebenen Zeichen auf 0 setzt, oder auch einfach bit #7 setzt (so mache ich das ueblicherweise - Vorteil: die Zeichen gehen nicht verloren, man koennte also bspw. temporaer auch etwas anderes auf dem Display darstellen, und dann zurueck zum gebufferten Screen) Gruss, Thorsten.

too bad that this wasn't the reason - it was the last hope that such a minor issue could be the reason. No, this comparison is important for the case that somebody wants to record parameter changes with an external DAW. The MBSEQ UI will only send actual changes via CC to simplify editing of the recorded data. Mixer page extensions are expensive (resource & conceptional effort wise) and have to be prioritized with other items in the wish list. I won't work on major features extensions in the next 2..3 months, so don't try to request everything which comes into you mind, instead please start exploring the given possibilities first and try to consolidate your ideas so that they fit into the given framework (and into the $10 chip of the core module which sets the limits as well ;-)) Best Regards, Thorsten.

Finally a stable design for jam sessions so that I can put the prototype into the MIDIbox museum - thanks for the great work!!! :thumbsup: Name PCB BLM PCB miniCore Case Shift button M2 hardware 4xLED availability 5 5 - 9 6 17 latigid on 1 1 1 1 1 1 Rowan 1 1 1 1 1 1 Phatline 2 2 1 1 1 1 TK 1 1 1 1 1 1 Total 5 5 4 4 4 4 Best Regards, Thorsten.

This makes sense (actually I miss this possibility as well! :-)) Added to the wishlist Best Regards, Thorsten.

I think that I found the issue: Track 1 has Octave Transpose +0 Track 2 has Octave Transpose -1 If both tracks are selected and the configuration of Track 1 is visible, Transpose +0 has no effect If both tracks are selected and the configuration of Track 2 is visible, Transpose -1 has no effect Because the global parameter handling function breaks if the changed value is equal to the visible value. So, if you would select +1 instead after power-on, the change takes place, and that's the reason why I haven't noticed this. ;-) Please try this update: http://www.ucapps.de/mios32/midibox_seq_v4_089_pre3.zip Change should take place independent from the visible value now (for all parameters, not only transpose) Best Regards, Thorsten.

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.