TK.

Yes, alcohol (like isopropanol) will be fine for cleaning up the flux. Best Regards, Thorsten.

The ribbon cable shouldn't cause a problem, my own modules are connected this way as well. Could you please try the IIC MIDI Software Loopback test? -> http://www.ucapps.de/mios/iic_midi_sw_loopback_v1c.zip See this README.txt for details: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fiic_midi_sw_loopback%2FREADME.txt Maybe it gives us some additional hints. Best Regards, Thorsten.

Update: how many MBHP_IIC_MIDI modules are connected to your router? It's very important that IIC_MIDI_MAX_NUMBER (defined in iic_midi_tick.asm) matches with the number of connected modules. This is especially important for the experiment I described above (some PIC16F88 pulled out) If less than 4 modules are connected, and IIC_MIDI_MAX_NUMBER isn't matching, the firmware will retry MIDI transfers multiple times - this can result into delays. Best Regards, Thorsten.

Did you connect the 4 RI lines to J5 of the core module in the right order? http://www.ucapps.de/midi_router/midi_router_interconnections.pdf And what happens if only a single IIC_MIDI module is running? (just pull out the PIC16F88 ICs of the remaining modules) Best Regards, Thorsten.

Hi Koert, sorry for the late reply, the simple reason is that I'm a bit puzzled about this case (but I don't want to say that I don't find this puzzle interesting! ;)) My own MIDIbox Router is running with latest MIOS, and latest released application and MBHP_IIC_MIDI firmware. Forwarding the MIDI input of an IIC input to a MIDI output of an IIC output is a very common case at my side, e.g. if MBSEQ sends MIDI events to my MBSID and MBFM. I'm still thinking about a test strategy which could help to find the root cause - I'm very interested in this case to improve robustness. Btw.: the delay of 1.5 seconds probably means that the MIDI protocol is violated (a "MIDI timeout" should happen in this case) Could you please describe, which devices you are using to test the router? Best Regards, Thorsten.

Martin: I second this! And I saw Hawkeye live in my room! Just enter a certain sequence and he starts to improvise lovely tunes immediately! :) This video triggered me to find a solution for detecting bad encoders, and to filter out unwanted jumps. Noise leads to high increment values, they should be limited. Best Regards, Thorsten.

Nils: the pure software approach isn't optimal, as it will introduce some jitter, especially when this routine is interrupted. The better approach would be the usage of an integrated timer + capture/compare unit which outputs the waveform directly on an output pin. Than faster it is running, and than higher the resolution, than better (see also the comments on the frequency accuracy of Juno DCOs at Tom Wiltshire's website) E.g. on a PIC you could use MIOS_TIMER_Init to initialize the frequency (assigned to TIMER3), and use the CCP1 unit to output 0 or 1 on pin #17 based on the compare value. More details about these units can be found in the PIC18F452 datasheet (and in the user manuals) The signal will be available at pin 17 (J7:SO of the core module). There will be a 0->1 transition when the compare value is reached, and it will go back to 0 when the timer period is reached. This means in other words: you are not only able to output a pulse waveform, but also to generate PWM with a few register writes. I remember that somebody implemented a very simple synthesizer based on this approach, the code is buried somewhere in this forum. Best Regards, Thorsten.

:ike: MIDIboxSEQ V4.0beta39 ~~~~~~~~~~~~~~~~~~~~~ o BUTTON_PAR_LAYER_A working again (was overwritten by BUTTON_DIRECT_TRACK16) [/code] next bug, please! ;) Best Regards, Thorsten.

Since some months we consider to change to the TAPR Noncommercial Hardware License, which would allow everybody to build and sell up to 10 units in any 12 month period on a non-profit basis w/o need for a special permission from our side. Without going too much into details (please open a new thread if you feel that this needs more discussion, but there will be a topic soon anyhow): this license would explicitly allow a professional or hobbyists to build and sell a MIDIbox to another user if he is only paid for his expenses (w/o profit) It would also make it less complicated to resell a used MIDIbox, no special permission required from our side as long as the NCL isn't violated. TBS violated the old license (no commercial use without my permission), and they would also violate the new license (e.g. by renaming the project and not mentioning the copyright holders - also the announced price of 1500 EUR somehow doesn't match with the "non-profit" term). Btw: for the case that you are interested on a MB6582, check this fleamarket sale by Lucem: Best Regards, Thorsten.

The owner of Mode Machines replies in facebook: These statements are simply not true! Some months ago we found a MIDIbox SID on the TBS product page. Nils contacted the company, explained the legal status (during a long phone call) and got the answer that they are not planning to sell the MIDIbox anymore. But it can still be found on their page, and now we saw it at Musikmesse as well. false, they never contacted me. false, they are currently not talking to us (in distance: Nils had to pro-actively contact them some weeks ago and thought that this topic is clarified). And I must say that I'm not interested to talk with profiteers with such attitude. Especially since it seems that they have no experience with the MBSID hardware/software - who should support the customers? Best Regards, Thorsten.

Btw.: Could it be that you moved your posting into the trashcan by yourself? ;-)

Sorry, I don't know who moved it into the trashcan, and I don't know how to undo this. I must admit that I'm very unfamiliar with all the options provided by this forum system... For the records: Param1 wrote at 18:01 (and I'm sure that this doesn't need to be censored): Best Regards, Thorsten.

yes, for those who are planning to build a new case. You can be sure that there will be an inexpensive and simple upgrade path! :) Best Regards, Thorsten.

I'm not amused about this - they haven't asked me for permission! :-/ Best Regards, Thorsten.

Because with a STM32F103RE it isn't possible to run USB and CAN in parallel, and the alternative STM32F105 derivative has only 256k flash maximum, which isn't sufficient for the software. I was waiting more than 2 years for a real alternative... but no suitable soluation from STM. So I tried a NXP LPC17 derivative instead and it's much better for the intended usecase. Not only that USB, CAN can run in parallel, and that an ethernet controller is integrated (unfortunately w/o PHY)... the performance is almost twice as good, giving me more headroom for more features (and/or extremely high update rates) The price is the same - so no real need to stick on a STM32 anymore. Best Regards, Thorsten.

Hi Chriss, I'm glad that it works at your side again! :) Best Regards, Thorsten.

You won't find details yet, as the project is still in the definition phase. I'm targeting end of this year for a first public release - hardware can change until then. Meanwhile I'm sure that it will be possible to upgrade an existing MBSID V2 (also MB-6582 and sammichSID) by connecting the new core32 module (*not* MBHP_CORE_STM32) via a simple two-wire CAN cable. PIC18F4685 will still be required to adapt the SIDs to the Core32 module, otherwise SID accesses would slow down the CPU too much. Also the existing CS can be re-used. So, must users only have to build a new core module and connect it to their existing MBSID V2 - thats all! They could build it into a breakout box. As a bonus they will get two MIDI IOs, USB, Ethernet (for OSC) and more. So, the core32 module will also be a nice MIDI interface replacement, and you could control your MBSID with an iPad/iPhone (or similar) as well if the ethernet interface is connected to a WiFi router. But MBSID V3 will also provide a shiny new (still DIY friendly) CS for improved usage - just two words: Hires-OLED and mulicolour! :) Best Regards, Thorsten.

Thanks for feedback, this bug was obvious! Fixed in Beta38 - as a bonus, the performance has been improved. :) MIDIboxSEQ V4.0beta38 ~~~~~~~~~~~~~~~~~~~~~ o CPU load reduced by more than 20%, this especially results into faster SD Card operations! o fixed move step function for moves which select the next step view [/code] Best Regards, Thorsten.

Hi Chriss, you are absolutely right, this was a bug! Fixed in V1.4a :) Best Regards, Thorsten.

You have to sync register accesses to the 1 MHz SID clock. It's especially important to prevent any setup or hold violation on the bus - depending on the microcontroller that you are using this can be very tricky! Due to this frequency limitation it's also better to control multiple SID chips from multiple microcontrollers. Some time ago I wrote a report about this issue: Best Regards, Thorsten.

Very nice ideas, I like the command decoding! :) And I've nothing more to add - they would already very useful! I gave you access to the programmers section where you will find informations about the latest developments (especially about MIOS32 and the new core module) I guess that you would add the MBHP_IIC_MIDI extensions by yourself? Best Regards, Thorsten.

Alright, it looks like this interface (MIDI cable at one side, USB cable at other side, case has similar shape and three LEDs) It's on the blacklist. If it isn't already too late: send it back and complain about the bugs - meanwhile I read from many users (not only in this forum) that SysEx transfers are not handled reliable by this cheapo interface. Best Regards, Thorsten.

Do you have a picture of this MIDI interface? Best Regards, Thorsten.

With MIOS32 we don't program in assembly language anymore; C programs written for MIOS8 are not 1:1 compatible, but have a similar look and feel. See also: http://www.ucapps.de/mios32_c.html The README files describe the new concepts in detail. MIOS32 already uses DMA for SRIO transfers, this article will give you some additional background informations for your "mission": Since your application is even more timing critical than we one described in, you could also disable the normal SRIO handling, and call MIOS32_SPI_TransferBlock directly. See also http://www.midibox.org/mios32/manual/group___m_i_o_s32___s_p_i.html Best Regards, Thorsten.

I read your observations, but there isn't enough input for a successful remote diagnosis. Could you please go through the troubleshooting guide and tell us, which tests are passing, which ones are failing? -> http://www.ucapps.de/howto_debug_midi.html Check also that your MIDI interface is not on the blacklist: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist Best Regards, Thorsten.