TK.

Fortunately there are no tracks routed to J16:D3..D0, therefore you can add the wires without special measures. I'm planning to update the firmware, so that a special flag can be set to enable the 8bit LCD interface option. I would provide you a special precompiled version for testing - but if you already able to compile by yourself, then this would help me (a bit less effort at my side, especially whenever I provide a new firmware) Note that I won't be able to test the enhancement at my side - I hope that it will work immediately at your side, otherwise I will need some time to buy & try the same OLED. Best Regards, Thorsten.

No, touch sensors are not supported by MIOS32, they consume too much CPU time. Btw.: did you already found somebody who will program the firmware for you? It would be bad, if you build this expensive hardware and then expect that I would take over the development - actually I'm not really interested to provide private solutions. Best Regards, Thorsten.

You have to remove the encoder entries at the bottom of the file: ;; additional CS encoders ;; SR Pin Mode ENC_ENTRY 0, 0, MIOS_ENC_MODE_DETENTED3 ; Osc delay/transpose/assign #1 ENC_ENTRY 0, 2, MIOS_ENC_MODE_DETENTED3 ; Osc attack/finetune/assign #2 ENC_ENTRY 0, 4, MIOS_ENC_MODE_DETENTED3 ; Osc decay/portamento/assign #3 ENC_ENTRY 0, 6, MIOS_ENC_MODE_DETENTED3 ; Osc sustain/release/assign #4 ENC_ENTRY 0, 0, MIOS_ENC_MODE_DETENTED3 ; Osc release/pulsewidth/assign #5 ENC_ENTRY 0, 6, MIOS_ENC_MODE_DETENTED3 ; LFO rate ENC_ENTRY 0, 0, MIOS_ENC_MODE_DETENTED3 ; LFO depth ENC_ENTRY 0, 4, MIOS_ENC_MODE_DETENTED3 ; Filter CutOff ENC_ENTRY 0, 6, MIOS_ENC_MODE_DETENTED3 ; Filter Resonance ENC_ENTRY 0, 0, MIOS_ENC_MODE_DETENTED3 ; Env depth/assign #1 ENC_ENTRY 0, 2, MIOS_ENC_MODE_DETENTED3 ; Env attack/assign #2 ENC_ENTRY 0, 4, MIOS_ENC_MODE_DETENTED3 ; Env decay/assign #3 ENC_ENTRY 0, 6, MIOS_ENC_MODE_DETENTED3 ; Env sustain/assign #4 ENC_ENTRY 0, 0, MIOS_ENC_MODE_DETENTED3 ; Env release/assign #5 because they overrule the button assignments Best Regards, Thorsten.

It's very likely a 4/8 bit thing. The solution would be a modified firmware (I could provide the modification if you are interested) and four wires to J16:D3..D0. Could you please already do this hardware modification? Connect: - PIC Pin RE2 to J16:D3 - PIC Pin RE1 to J16:D2 - PIC Pin RB1 to J16:D1 - PIC Pin RB0 to J16:D0 /edit: pinning corrected, this one is working (confirmed by RyuX) Compare following schematic for sammichFM J16 pinning: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?media=sammichfm:sammichfm_base_pcb_rev_1.pdf And following schematic for PIC pinning: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf Best Regards, Thorsten.

It's still on my TODO list, but with low prio because you are the only guy who requested this yet Best Regards, Thorsten.

Let's come back to these bizarre issues which I would like to solve :) Could you please describe in more detail, how I can reproduce and monitor the MIDI output based on the session that you gave me? Best Regards, Thorsten.

The MIOS32 based solution is only experimental, far from completion (e.g. there is no UI yet). It was some kind of learning example for me some years ago, therefore you also won't find documentation - probably it will never be released to public. E.g. SID core connection is a difficult topic, probably it would only be possible via CAN, which means that PIC based cores are still required, which makes the project too complex for newbies. In order to download all files, use a SVN client as explained in the Wiki. Best Regards, Thorsten. P.S.: next reply next week - I'm on a weekend trip

Then I also need exact instructions to reproduce this issue. Btw.: check the ensemble configuration of your MBFM, maybe multiple instruments listen to MIDI channels which are intended for other devices? Best Regards, Thorsten. P.S.: next reply next week - I'm on a weekend trip

In assembly language it mostly isn't a single line, but there are many places which need to be changed and dependencies which need to be considered. Sometimes it's even impossible due to higher execution times or missing resources (RAM, Flash) Therefore I was carefully asking if you really want/need this, because normally it will be some effort (1..2 hours) to do & test the change. And one mistake can lead to even more time since debugging without knowing the whole code is extremely difficult (e.g. where would you start if MBSID crashes sporadically after your change...) If you really want to start with this, it could make sense to read & understand the C based version (for MIOS32) of the firmware first: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v3%2Fcore%2F Because here most of the functions are mostly only a single line... Then try to find the same function in the assembly based version, see how things are done (e.g. how to add + multiply 16bit variables), try changes. Best Regards, Thorsten.

I still can't reproduce this problem. Could you please try the following: press the stop button two times before start - does this change something? Please try this with the same version like me (084_pre2 that is linked above) If this doesn't make a difference, I will need more specific instructions. So, every operation after power-on, like: enter song page, select song mode, press play, wait for 3 seconds, press stop, press play, look for MIDI events played by track 1 (this is exactly what I'm currently doing and where I don't see a problem...) Best Regards, Thorsten.

Your configuration is correct, in this case only a single AOUT_LC is required to control two VCAs Best Regards, Thorsten.

Thanks! I was able to reproduce the "multiple mixer map dump" issue, it should be fixed in this version: http://www.ucapps.de/mios32/midibox_seq_v4_084_pre2.zip But the strange "track step" behaviour still puzzles me. It doesn't happen at my side (resp. I don't recognize it because I don't know your tracks good enough, or I'm not using the same instruments...) Theoretically it can't happen, because a sequencer start will reset all variables which belong to the step progression. There is only one (known) way how this could happen: if an external device changes the song & pattern position with the appr. MIDI Event (0xf2) So: is there any device connected to MIDI IN which could send a 0xf2 event? If you are unsure: disconnect all devices from the MIDI IN ports. Best Regards, Thorsten.

I can generate similar peaks with the PIC when I take a long cable (> 5 m) ;) How long are your cables to the CLK and Ground pins? Best Regards, Thorsten.

Interesting! Where did you probe the signal, at the PWM output of the microcontroller, or at the CLK input of the SID? However, since the resistor doesn't help, using a cap against ground seems to be the right way to solve the issue. Best Regards, Thorsten.

Do you mean song steps (A1, A2, .. A8, B1, B2, ... B8) or track steps? If song steps: it's normal that MBSEQ starts a song from the currently displayed position to simplify editing. Just change to another page (e.g. EDIT) and push the start button from there - then the song should be started from A1 If you (and/or some other) people don't like this behaviour, I could make it optional. This is strange! I need your session directory, and the MBSEQ_GC.V4 file in the root directory to analyze this. Best Regards, Thorsten.

I'm a bit confused from your reply and guess, that you missed the message: you can modulate all six OSCs with a single modulation path by enabling the L/R switches of the direct modulation targets for OSC pitch. This will copy the modulation result to all (selected) targets. Did you every try this - where is the difference? Best Regards, Thorsten.

The breakout board is not an external board, it just brings all interfaces together and allows to mount the MBHP_CORE_STM32F4 (or MBHP_CORE_LPC17) under the frontpanel at the bottom of the case without tricks and with much more free space. Here a picture from orange_hand which shows what I mean: Original article (in german): Re: Midibox Sequenzer MBSEQ V4 / The Project I'm trying to highlight that there is a solution which makes LPC17 and future STM32F4 users happy. Such a breakout board would even open the possibility to upgrade the MIDIbox SEQ with future core modules w/o high costs, because most interface components are already part of the breakout board. We wouldn't have a dependency between the core module layout and the backpanel anymore. Best Regards, Thorsten.

Yes, I'm planning to provide timed events sooner or later. I've already some ideas for an efficient implementation (it could be similar to the MIDI event scheduler), but due to the memory consumption it might only be provided for the MBHP_CORE_STM32F4 module. Best Regards, Thorsten.

Hi, the DEFAULT_BPM_DIGITS_* configuration looks correct for your hardware. Could it be that the common lines are connected to the wrong Dx output pins? I'm a bit unsure if it was (D7, D6, D5) or (D2, D1, D0) Best Regards, Thorsten.

Very nice report! I'm also looking forward for the upcoming case design :) Best Regards, Thorsten.

It's started, but not finished, see: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2Fsrc%2Fcomponents%2FMbCvVoice.cpp 1st place: search for "transfer note -> linear frequency" 2nd place: search for "linear frequency -> CV frequency conversion" It won't be so easy to finalize this, if you would like to work on the implementation, step forward. :) Best Regards, Thorsten.

No, you need potentiometers (in the schematic called R_p) for the calibration to compensate the usual device tolerances. Best Regards, Thorsten.

As mentioned in another thread, I highly recommend to use a MBHP_CORE_STM32F4 module, since this will be the only one which will be able to run the upcoming "V4 Plus" firmware (due to higher amount of RAM and Flash resources, and higher speed). Accordingly the backpanel will look different. E.g. MBHP_CORE_STM32F4 natively supports 4 MIDI INs and 4 MIDI OUTs - is there still a need for 4 additional IIC based MIDI OUTs? For SD Card and USB Socket we need a breakout board, because the MBHP_CORE_STM32F4 module is too large so that it can't directly mounted at the backpanel (/edit: to be more precisely - instead it has to be mounted at the bottom of the case) For ethernet the MBHP_ETH module would be required. This opens the option that somebody designs a special breakout board with: - 4 MIDI IN/OUT based on two MBHP_MIDI_IO boards - USB, and here the question: do you prefer a B Socket like before, or would Micro USB be more interesting - advantage of Micro USB: an USB Host option would be possible! - SD Card Socket - Ethernet Circuit (MBHP_ETH module) + Socket. For LPC17 a direct socket connection would be required (MBHP_ETH not used) - 25 pin AOUT/SRIO Breakout Socket Optionally with line drivers to support cable lengths of up to 5m -> http://www.ucapps.de/mbhp/line_drivers.pdf - BLM Socket - Power Switch and Ext. Power Socket Such a breakout board would have another advantage: it would be compatible to the MBHP_CORE_LPC17 module as well! And we could create a common backpanel design for it. Best Regards, Thorsten.

For the records: Zenlogic had the same issue with an Atmel Microcontroller and solved it:

Yes, you need two MBHP_DIO_MATRIX modules, yes, these are 1N4148 diodes, and yes the LEDs are driven similar to the LED Ring schematic. Note that the 10x10 dimension isn't the best choice, because LEDs won't be so bright like on a 8x8 configuration. Best Regards, Thorsten.