TK.

No, MBSID V2 doesn't send a MIDI clock, but I will add this to the next release. How/When should MIDI clock start & stop be sent? Best Regards, Thorsten.

Does your multimeter provide a "beeper"? Then you could compare if the connections are matching with (for example) this one: http://www.ucapps.de/midibox_kb/midibox_kb_scanmatrix_type2.pdf Pots: up to 4 pots can be connected to J5A The configuration is explained here: http://www.ucapps.de/midibox_kb.html Search for "pitchwheel" and "modwheel" Best Regards, Thorsten.

The MIDIbox Link topic is only relevant when multiple PIC based cores should be chained, and informations from the host should be tunneled from the first to the last PIC without feedback to the DAW. If multiple, chained PIC based cores should be connected to a single MIDI IN/OUT pair of the MBHP_CORE_LPC17 module, then the last PIC should be configured as "Endpoint", and all others as "Forwarding Point" - thats all. The MBHP_CORE_LPC17 module should run a firmware which provides an internal MIDI router, so that the data stream can be forwarded to USB MIDI (so that it acts as a MIDI interface to your DAW). This router is integrated into most applications meanwhile and can either by configured from the MIOS Terminal (-> type "help"), or from a control surface. They are not TTL, but working in a valid voltage level range so that they can be directly connected to J11 of the MF_NG Module; no optocouplers or levelshifters required. Note that you could also use the J4B port (MIDI IN/OUT 4) if you need J5 for other purposes. Best Regards, Thorsten.

Thanks for the feedback! :) I can imagine, why it gets stucked with a guide track with more than 16 steps: the current step is compared with the measure, which means if the measure consists of 16 steps only, the loop point condition will never be met. It would work if you configure the measure length with 32 or more steps in the UTIL->OPT page. I can fix this in the next version by giving the guide track an own (independent) measure. Best Regards, Thorsten.

Ok, I tested it at my side again, but haven't noticed an issue. It's very important that you are removing (or disabling via #) the default "BUTTON_PATTERN_RMX 0 0" entry, otherwise the assignment will be disabled. Background: for each function only a single assignment can be done. The last one will be taken over, previous definitions will be overwritten! There is an update for MBHP_ETH on STM32 (module sporadically missed incoming packets) MIDIboxSEQ V4.061 ~~~~~~~~~~~~~~~~~ o STM32: MBHP_ETH module working properly again [/code] Best Regards, Thorsten.

Very strange! What do you mean with "won't come up" - what is missing, a LCD message? How does it behave in Bootloader Hold Mode? (Jumper J27 stuffed) Best Regards, Thorsten.

Yes, Split Mode will do the trick! (it's supported by the DAW) Best Regards, Thorsten.

Wow, das Gehaeuse sieht ja schonmal sehr robust aus! :-) Ich habe letztens die geplanten Aenderungen in die MBLC Firmware eingebaut. So gibt es nun bspw. einen integrierten MIDI Router, und optional koennte man die MIDIbox sogar ueber Ethernet betreiben (USB MIDI ist jedoch schneller) Falls Du Dich nicht an den Original-Schaltplan haelst (identisch zur PIC basierten MBLC), benoetigst Du uebrigens noch eine SD Karte, um ein alternatives Setup einzuladen. Gruss, Thorsten.

@Midilab: could you please test this at your side? Best Regards, Thorsten.

Alright, under the assumption that the MIDI connection has been tested via TEST MIDI2, the voltages are present, etc. it's either related to a bad solder joint around the crystal which clocks the PIC, or the PIC itself. Best Regards, Thorsten.

...und Du hast mir geschrieben, dass Du mir das Rueckporto ueberweisen wirst. ;) Gruss, Thorsten.

I haven't changed anything to solve this issue, as I wasn't able to reproduce it. Please let me know if it fails again on future MBSEQ firmware updates, it could be related to a memory allocation issue which causes memory accesses to invalid addresses (this will be hard to troubleshoot -> therefore "hard fault" ;-)) Best Regards, Thorsten.

Vielleicht ist die LED falsch herum angeschlossen? Ich kann mich nicht erinnern, ob ich sie an Deinem Modul getestet habe... Der core laeuft ja schon (siehe Ilmenators Kommentar) Gruss, Thorsten.

Hi Djé, you will need two MBHP_CORE_LPC17 modules to realize this. One core which is using the MBKB firmware, another one which is running the MIDI controller firmware. For the MIDI controller you could start with a modified MIDIO128 - there is a hidden extension which allows to use rotary encoders instead of buttons. But using buttons in addition will be tricky, because it would require a second SRIO chain. Do you have programming experience? Best Regards, Thorsten.

From the docs: The AOUT page allows to assign the modulation sources of an instrument to an AOUT channel. Note that analog (CV) outputs are an optional feature which require a MBHP_AOUT, MBHP_AOUT_LC or MBHP_AOUT_NG module. AOUT: selects the AOUT channel which should be configured (1-8) Inst: assigns an instrument to the AOUT channel (1-4) Assg: assigns one or more modulation sources to the AOUT channel (L: first LFO, L: second LFO, E: envelope generator EG5) -- the modulation depth has to be adjusted separately in the LFO/EG5 menu page and is saved with the instrument patch Offs: adds an offset to the modulation sources (-64..63) I can point you to integration details (schematic) once you decided which AOUT* variant you would like to use. I'm using four AOUT_LC modules by myself to control 4 CEM3378 based filters, because it was the cheapest solution some years ago: See also: Meanwhile I would prefer the AOUT_NG module, because it's less expensive than AOUT, and less soldering effort than AOUT_LC Best Regards, Thorsten.

We need more input for remote diagnosis. E.g. you are writing that you've used it once for Traktor. Do you remember which MIOS version was installed? This is important to know, because versions less than v1.9 are not compatible with most tools. You are also writing that you finished the troubleshooting guide without results. I don't believe this - you definitely have results. E.g. if "TEST PC1" fails, than it's clear that you wouldn't be able to connect to the core as well. Please post the results of all tests. Once they are clear, it's easier for us to decide if the problem is related to the PIC (unlikely), software installation or whatever. Best Regards, Thorsten.

The "Guide Track" feature is now implemented in V4.060: Please let me know if it works at your side, and/or if the usage is too confusing. I think that the new possibilities are really interesting! :) Best Regards, Thorsten.

MBHP_AOUT module should work again with v4.060: I'm really sorry for the trouble! Again I was too lazy to test all modes before a release, after I tweaked the MBHP_AOUT_NG module configuration for another user to get him happy. Best Regards, Thorsten.

yes, just change from Pattern to Bank selection with encoder #8 this usecase is considered in v4.060 Yes: store your configuration without the quarter note triggers as a preset, and recall it whenever you need it. Intention behind the default triggers: you will hear the selected instrument, this speeds up the selection of MIDI port and channel. Best Regards, Thorsten. MIDIbox SEQ V4.060 is available now. ChangeLog: MIDIboxSEQ V4.060 ~~~~~~~~~~~~~~~~~ o fixed initialisation of MBHP_AOUT module o Song Mode now provides a "Guide Track" which can be configured by pressing SELECT in SONG page: the length of this track defines the loop length and once the last loop has been played, all tracks will be synchronized to step 1. This allows to program breaks with a step length which is independent from the measure. o Phrase Mode now syncs the pattern changes to the measure of SyncChange is set in the UTIL->OPT page o Phrase Mode manually triggers the "synch-to-measure" option for all tracks to ensure that all tracks are re-synchronized to step 1 o MBSEQ_HW.V4 files: changed encoder mode to MIOS_ENC_MODE_DETENTED3 since it's compatible with most encoders [/code] Best Regards, Thorsten.

I just tried a MBHP_AOUT with my own MBSEQ and can confirm, that the driver is broken (somehow). This needs further analysis - I will come back to this topic later today. Best Regards, Thorsten.

Welcome back! :) The change in the MBSEQ_HW.V4 file is obsolete, all parameters can now be configured during runtime in the CV configuration page: in addition, CV channels can be calibrated from there. However, as you wrote you already found this page, therefore I guess that it's related to an interconnection problem. According to this schematic: http://www.ucapps.de/midibox_seq/mbseq_v4_interconnections.pdf it's important that a 4x1k resistor array is stuffed for J19 - other resistor values might lead to an unstable communication. If this is already the case, then you could use an inbuilt diagnosis feature of the MBSEQ firmware: just type "testaoutpin" in the MIOS terminal and follow the instructions - it will allow to set AOUT:J1 pins to logic-0 and logic-1, the resulting voltage level can be measured with a multimeter - maybe two pins are swapped? Best Regards, Thorsten.

I think that all three issues don't belong together. @tupinamba: I need the copy&pasted system info (right-click in terminal window, copy, paste into the forum reply). In addition, I need your session directory. @pcbatterij: it isn't really helpful if you are reporting issues of a modified firmware in such a thread - I can't (and won't have the time) to analyze such an issue with your modifications, it could be related to something totally different, and since your only fragmentally inform me about your changes, it makes it even more difficult to understand the backgrounds - please open your own thread and just post your observations there, I will answer if I know an immediate answer, or if I can puzzle it from your descriptions. E.g. have you ever considered that the delays could be caused by the graphical LCD that you are using? @sneakthief: thats (unfortunately) a known limitation: loading a pattern from BankStick takes some time. It's usually done 2..3 MIDI ticks before the next step will be played, therefore you won't notice the delay in song/chain mode. But if you are requesting a pattern change from external, MB808 obviously can't predict your intention, therefore the delay can't be prevented. This is unrelated to the MBSEQV4 issue here, since a) in song mode the patterns are loaded some (micro)ticks before the change, in addition MBSEQV4 includes a clever preloading mechanism which should ensure 100% stable timings (therefore I really want to know, what could go wrong here)... and b) loading patterns from a SD Card is much faster compared to the BankStick Best Regards, Thorsten.

Nein - bitte wie folgt anschliessen: Pin T an J14:T0 Pin 2 an J2.A0 Pin 1 an J2:Vd Pin 3 an J2:Vs Motor (zwei Anschluesse) an M11 und M12 [/code] falls der Motor in die falsche Richtung dreht, M11 und M12 vertauschen Gruss, Thorsten.

The MM application stores the received LED status events in an array. Up to 256 LEDs are supported, some of them (128..256) are used by internal features such as the "general purpose controller" mode. Storing the LED status in an array is required, since we want to switch between these modes (means: button/LEDs will change their purpose) without requesting the DAW for sending the original LED status again when switching back to a different mode (e.g. because the DAW doesn't support such a function). Why is the array size divided by 8: because this saves some memory. A byte can store 8 bits, the led status for each LED is 1 bit (on or off), accordingly we don't need to allocate 256 bytes, if the same information could also be stored in 32 bytes. This is already "advanced programming" (required due to limited resources of the PIC), and this might have confused you. In general: if you need more customization, but find my method to complicated, just remove the code and start from scratch - it's sometimes faster than going through the legacy stuff... You probably already know that the free configurable MM function->LED/button map is located in mm_dio_table.c It assigns the functions to all SRs in a continuous list. Currently following functions are assigned to the second shift register (SR2?) // 2nd shift register // button LED ID_SOLO_CHN1, ID_SOLO_CHN1, ID_SOLO_CHN2, ID_SOLO_CHN2, ID_SOLO_CHN3, ID_SOLO_CHN3, ID_SOLO_CHN4, ID_SOLO_CHN4, ID_SOLO_CHN5, ID_SOLO_CHN5, ID_SOLO_CHN6, ID_SOLO_CHN6, ID_SOLO_CHN7, ID_SOLO_CHN7, ID_SOLO_CHN8, ID_SOLO_CHN8, [/code] But ID_SELECT_* functions are assigned to the 4th shift register: [code] // 4th shift register // button LED ID_SELECT_CHN1, ID_SELECT_CHN1, ID_SELECT_CHN2, ID_SELECT_CHN2, ID_SELECT_CHN3, ID_SELECT_CHN3, ID_SELECT_CHN4, ID_SELECT_CHN4, ID_SELECT_CHN5, ID_SELECT_CHN5, ID_SELECT_CHN6, ID_SELECT_CHN6, ID_SELECT_CHN7, ID_SELECT_CHN7, ID_SELECT_CHN8, ID_SELECT_CHN8, You have to reorder the assignments to adapt them for your needs. In addition you are asking to assign ID_SELECT_CHN1 to the D0 output pin, but DOUTs are counted from D7 (the "first LED" is D7) (this also related to following question which is probably the reason why you are asking this: ) This simply means, that you have to mirror the LED assignments this way: // button LED ID_SELECT_CHN1, ID_SELECT_CHN8, ID_SELECT_CHN2, ID_SELECT_CHN7, ID_SELECT_CHN3, ID_SELECT_CHN6, ID_SELECT_CHN4, ID_SELECT_CHN5, ID_SELECT_CHN5, ID_SELECT_CHN4, ID_SELECT_CHN6, ID_SELECT_CHN3, ID_SELECT_CHN7, ID_SELECT_CHN2, ID_SELECT_CHN8, ID_SELECT_CHN1, [/code] Best Regards, Thorsten.

Does this posting belong to your MM firmware modifications? If yes, it would really make sense if you would add your questions to a single thread, instead of starting new threads on each new question, because for somebody who doesn't follow your history, it's difficult to determine how to help you. Not to forget how somebody should understand your question when he reads this posting in 2..3 years (it will be almost impossible to find the other postings) So, if you mean the MM firmware modification: the ENC_*_SPEED_* definitions are used in mm_vpot.c, search for MM_VPOT_Init(), this function has to be extended. Best Regards, Thorsten.