TK.

yes, this is my assumption as well ;) Best Regards, Thorsten.

Ok, now I only need the time to analyze this... :unsure: (I'm on a business trip next week, and on holiday thereafter... if I don't feel boring it could be that I can't check this before april) Best Regards, Thorsten.

Die LC Meter werden ueber spezielle MIDI Events (und SysEx) bedient. Habe leider noch keine Zeit gefunden, das einzubauen - sie benoetigen eine Extrabehandlung an mehren Stellen. Aehnliches gilt fuer die LED Digits -> ebenfalls noch Baustelle Ist aber auf alle Faelle auf der TODO Liste Gruss, Thorsten.

Before I forget to notify you again: thank you very much for handling this bulk order. Got my "lifetime supply", and I'm also happy about the extra big knob! :) Best Regards, Thorsten.

The DOUT_GATE_SR* flags define the shift register assignments. Each shift register has 8 outputs Could it be, that you assumed that DOUT_GATE_SR* selects a DOUT pin number? Then this would explain the confusion. MBSEQ would output an error message if the file contains an invalid command. E.g. write an invalid command (such as XXX) at the top of the file, thereafter "reset" the core (enter the reset command in MIOS terminal). After startup, the MIOS terminal should output following message: [368171.630] [SEQ_FILE_HW] ERROR: unknown parameter: XXX Btw.: it's much more comfortable to edit the file directly with the MIOS Filebrowser Best Regards, Thorsten.

Yes, you could change this in the MBSEQ_GC.V4 (use the Filebrowser in MIOS Studio to edit this file) Change: MultiPortEnableFlags 0x011011 to: MultiPortEnableFlags 0x011031 Best Regards, Thorsten.

Needs more analysis at my side, need your files (and some time) Best Regards, Thorsten.

The Matrix of MIDIO128 (DIN Matrix) only sends events, it doesn't receive events. Therefore I don't see a conflict. In your matrix configuration: I can see that it not only sends to USB1, but also to OUT1 It might make sense to disable this port, so that matrix events are not sent to the core8: Best Regards, Thorsten.

Nice! :) Btw.: where did you buy the LCDs? I like them! :) Best Regards, Thorsten.

Please help us to understand why you are asking ;-) Otherwise it's really unclear which answer you expect. Are you asking because this configuration doesn't work, or behaves strange? Best Regards, Thorsten.

The Linux version is available at the bottom of this page http://www.ucapps.de/mios_studio.html You can use the integrated Filebrowser of MIOS Studio to edit the .MIO file, it's much easier (and should also work under Linux) No need to use the MSD function anymore (actually I consider to remove it from most applications because it doesn't work properly on most systems and only confuses users) Best Regards, Thorsten.

Both options are available: the MIDI merger can be enabled via the menu interface (you need a LCD for this) or optionally via SysEx See also this tutorial: http://www.ucapps.de/midibox64_tutorial.html MIDI Timeout: could happen if there is a problem with the optocoupler circuit - it could be, that your MIDI IN isn't working yet? Best Regards, Thorsten.

Good that you found this - because I had no idea what (aside from a connection issue) could cause such an effect! ;-) Best Regards, Thorsten.

I like the idea, but I think that it would be better to load such a file (let's call it .NGR for "NG Run Script") after .NGC, because the .NGC file could contain important configuration commands (e.g. DOUT_MATRIX) which you don't want to duplicate. Such a run script could also open additional possibility, therefore I wouldn't restrict the execution to the startup - it should be executed whenever a .NGC file is loaded. Possible commands: LCD "%CSelftest" SET LED:1 127 DELAY_MS 10 SET LED:1 0 SET LED:2 127 DELAY_MS 10 SET LED:2 0 SET LED:3 127 DELAY_MS 10 ... LCD "%CFinished." Best Regards, Thorsten.

You could also use the MIDIO128 app to test this. Each received MIDI note will write to the LCD, so you can control the "update rate" by yourself (just play some notes on the virtual keyboard of MIOS Studio). Alternatively: I just noticed that the MBSID application includes an alternative LCD driver (app_lcd) which is enabled by setting the LCD section of the PIC ID header to 7. It can also be set by software from USER_Init: clrf MIOS_PARAMETER1 clrf MIOS_PARAMETER2 movlw 0x07 call MIOS_LCD_TypeSet With this driver, the LCD can be used in 8 bit mode. Pin D2 and D3 are available at PIC Pins RE1 and RE2; see also http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fapp_lcd.inc Best Regards, Thorsten.

To 1) no idea :-/ Best Regards, Thorsten.

The bootscreen already uses 4bit mode. There shouldn't something significant different thereafter - ok, the LCD will be overwritten frequently. Best Regards, Thorsten.

You've to increase the number of scanned SRs as well. This can be done in the mios32_config.h file: // increased number of SRs #define MIOS32_SRIO_NUM_SR 20 Best Regards, Thorsten.

I guess that the MIDI merger is disabled by default to avoid unwanted loopbacks. The MIDI OUT should send a lot of "random" CC values when J5 pins are open (neither connected to pots, nor to ground) If this doesn't happen, then the PIC very likely doesn't run. Yes, this could be a problem with the config bits. Here is the expected configuration (which was manually selected): http://www.ucapps.de/howtoprog/icprog_conf2.gif Best Regards, Thorsten.

Sometimes it will get fixed by playing around with the panel. Sounds more like a connection issue Best Regards, Thorsten.

I guess that it crashes when the MSD driver is activated, right? This could be related to a RAM consumption issue again. You could use the MIOS Filebrowser instead, did you already try it? Best Regards, Thorsten.

(currently I've not so much time to give you direct help on this) I hope that my assumption: ;; note: if some memory is required, 0xa80-0xaff could be used, because the wavetable only needs to exist once is still true - I never checked this if any part of the firmware really never overwrites 0xa80..0xaff Anyhow, I guess the problem is, that j5_din.inc is not prepared for the case that somebody locates the variables to addresses >= 0x80 This code has to be changed, so that BANKED accesses are used. See also this documentation: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fdoc%2Fmios%2Fmios_ram_handling.txt Best Regards, Thorsten.

Well, the SRIO driver of MIOS32 wouldn't be suitable for such a kind of communication, and especially the new paged SRIO would conflict with this (it allows to dim the LEDs, which is especially useful for RGB LED configurations) Means in other words: your board would have to be accessed from J16 or J28 like other serial slaves, such as AINSER64, AOUT*, a SD Card, etc... I guess that you noticed this already by yourself: than higher the bitrate, than higher the danger that your microcontroller can't forward serial data fast enough which would result into data loss. So: you have to define a maximum bitrate at which it's ensured (under all conditions), that data can be forwarded on time without the danger for a buffer overrun at the SPI receiver site (e.g. by using an interrupt based SPI handler which is invoked at highest priority). As long as this is ensured, the number of connected slaves in the chain doesn't really matter anymore - they will only increase the latency of the data transfers. Best Regards, Thorsten.

There is probably a conflict with J5_IO* which is initialized in main.inc as well (e.g. if DEFAULT_J5_FUNCTION == 2 or DEFAULT_J5_FUNCTION == 3, search for this) Ensure that this function won't be called, because it will configure the J5 pins as outputs. Best Regards, Thorsten.

J8/9 is used to scan the shift registers periodically, it isn't used to "communicate" with a SPI slave device. For such a purpose, somebody would use J16 or J28 Well, I still don't know what kind of data has to be transferred, how should I estimate if 10 MBit/s are enough? And: I don't know what you mean with this statement... :-/ Best Regards, Thorsten.