TK.

yes, of course! The metal plate is like a huge 50 Hz sender - take care! In general I would never tinker with electronical gear on a metal workbench, you should put an additional wooden board at the top Best Regards, Thorsten.

Hi Moxi, My proposal: just try it out, there are always cases which nobody do consider, regardless how often they look into the code (it's also my own problem - therefore I cannot release variations without the possibility to try it with the appr. hardware) Best Regards, Thorsten.

it looks like a 0x55 with wrong baudrate - did you setup your RS232 interface correctly? baud rate: the PIC always sends with 19200 baud. It sends a 0x55 for autobaud detection after startup Resets: there are two cases where this can happen: 1) the 1k pull-up is not connected to the IIC SC(K) like, or 2) MIOS_IIC_Stop() hasn't been executed from the Init() function I guess that you've considered both (I just checked your code again, you have a call to SPEAKJET_Init, which propably contains MIOS_IIC_Stop() Have you ever accessed an IIC device (e.g. BankStick) from this core module? Is the cable between PIC Pin #28 and J4:SC connected? ;-) Best Regards, Thorsten.

All the switches and levers can be found in main.asm, or in the setup_*.asm file you are using. I know that there are so many options in the meantime, that it is hard to get an oversight. But hey, you guys asked for these features, and never helped to write a documentation about them - so it's on you to read my comments in the code! ;-) Kobayashi: the switch for which you are searching is named CS_MENU_DISPLAYED_ITEMS Best Regards, Thorsten.

It is difficult to enhance the meter code, so that only activated LFO/ENVs are displayed, because the informations are located in different variables - each modulator needs different masks. So, it's nothing which can be done and tested within one afternoon (from my experience, I would build in at least one new bug ;-) I'm happy with the current handling, and I would like to continue with new stuff, is this ok for you, Rio? Best Regards, Thorsten.

It won't be possible to control MBSID V1 slaves from a MBSID V2, because the data formats will be very different. My main intention is to get rid of the old format and not to take compatibility into account. This is very important, otherwise V2 wouldn't provide so many new features (it's not only the stereo option...) Today I cannot say if it will be possible to run V2 slaves on a PIC18F452. Propably not, because my focus on the new subsystems will be "optimized for speed" and not "optimized for code size" I won't continue on MBSID V1, maybe only for bugfixes if they are still required, but for nothing else. There will be a converter script which allows you to transform V1 patches to the new V2 format Best Regards, Thorsten.

You mean an Audio Out cable which leads to a audio jack (3.5" or cinch) directly soldered on J3 of the SID module? This would be the best. I wouldn't use an connector for J3 Best Regards, Thorsten.

This page contains some sound examples, what an arpeggiator is doing: http://www.ucapps.de/midibox_seq_tutorial4.html Best Regards, Thorsten.

The specs are in the release package: midibox_sid_sysex_implementation.txt lists the SysEx commands, and sid_sysex_table.inc the SysEx -> CC mapping (plus some values which are not accessible via CC, e.g. patch name or Layer split points). Details can be easily found out via try&error (or by reading the source code ;-) I'm aware of the JSynthLib limitations. I'm not a Java programmer and was happy enough to get this JSynthLib based GUI running... :-/ Best Regards, Thorsten.

Das ist ein PIC18F4550 mit 4 MBHP_IIC_MIDI modulen (PIC16F88) als MIDI Port Erweiterung Gruss, Thorsten.

Just upload the srio_interconnection_test and check, if the SC and RC signal goes to each shift register 5V/0V are important as well of course Best Regards, Thorsten.

Upload the program properly via first level bootloader, "invalid code" really means "random behaviour". It doesn't make sense to think about symptoms when the application is not complete! Best Regards, Thorsten.

Also ich betreibe 5 MIDI In und 4 MIDI Outs :) -> Guckst Du hier Gruss, Thorsten.

0E 0B means MIDI overrun error, this matches with the message on the display (time out) The rest doesn't need to be taken into account, because I think that the reason for the failure is obvious: there was a problem with the upload some time ago, now some invalid/random code is executed, and data cannot be uploaded anymore once the application has been started. This means in other words: just overwrite the invalid code via first level bootloader. This must be done within 2 seconds after power on Best Regards, Thorsten.

Just type "perl hex2syx.pl -os_upload update_without_installed_mios.hex" (attend the "-os_upload"!) Best Regards, Thorsten.

Some words to the MIOS_SRIO_Number parameter (number of SRs): it's allows to set 16 by default, if less shift registers when the given number are connected, the pull up resistor at the end of the DIN chain will ensure that no random values will be scanned (the last buttons values are read as 1 -> inactive) When you remove a DIN shift register from the middle of the chain, the last ones are not connected to the core anymore, therefore they won't be scanned. if the upload cannot be completed, invalid code will be executed. Anything can happen, the MIDI time out is only a random side effect. Use the latest MIOS Studio version, and try to upload again. Don't continue debugging until the upload was successfull, it doesn't make much sense Best Regards, Thorsten.

Most host applications support the possibility to include a special driver for a controller today. Best example is Logic/Mackie Control or Korg Micro Kontrol, the drivers have direct access to parameter names and therefore can send it to the external device via MIDI, USB or a similar interface. Unfortunately the API to the drivers are not standardized, and they are not open like VST or VSTi Another approach is the way how NI Kore is working - it acts as a host or extender, has direct access to all VST parameters and communicates with the external control device via USB - NIK is also no open interface, no benefit for us But if you search for a nice programming experience, just try to implement the Micro Kontrol protocol. The spec is available somewhere at the Korg homepage, and you could use midibox_mm as a template Best Regards, Thorsten,

I thought more about the possibility to use a USB PIC in connection with a SD card. The card could be accessed as mass storage device from the PC, and as non volatile memory via I2C from another PIC. But in general it's just a nice toy, and there is not so much benefit. Using battery backuped SRAM brings much more new possibilities, because data can be stored faster. Best Regards, Thorsten.

Hi Rio, it's not possible to determine the current LFO/EG meters of a slave, therefore the matrix always shows the values of the master. Does anybody have objections against Rio's proposal, to show LFO/EG meters only when they are routed to a target? Best Regards, Thorsten.

Hi Jess, do I oversee something? Comprehensive SysEx capabilities are already available, you can request and store patches, and you can change single parameters in realtime. The JSynthLib based editor uses these functions, did you ever use this tool? (it's nice :)) Best Regards, Thorsten.

Hallo Pico, ok, Du hast also lediglich die Uebertragungszeit ueber die MIDI Ports gemessen, hier sind die Werte realistisch. Fuer USB kannst Du nochmal mindestens 1-2 mS draufrechnen - das Ergebniss aus dem MIDI Benchmark messe ich sowohl mit dem MBHP_USB Interface (AN2131SC basierend, USB 1.1) als auch mit dem MBHP_USB_PIC Interface (PIC18F4550 basierend, USB 2), das Delay wird also im wesentlichen vom Windows Driver bestimmt, und der ist im Vergleich zu anderen Treibern sehr performant (das muss man Microsoft lassen) Die USB Performance laesst sich also nicht weiter erhoehen. Um den MIDI Benchmark zu verwenden, benoetigst Du zumindest einen zweiten PIC, und idealerweise ein LCD (ansonsten muesstest Du nach einer anderen Moeglichkeit suchen, an die Messwerte heranzukommen, sie koennten bspw. via SysEx gesendet werden). Die MIDI In/Out Ports des zweiten PICs werden mit den In/Out Ports des USB Interfaces verbunden, und der Loopback geschieht softwaremaessig mit MIDI-Ox (oder wesentlich interessanter: mit einem MIDI Sequenzer wie Logic oder Cubase) Alternativ koenntest Du auch einfach Dein Keyboard an das Interface anschliessen, eine Note senden und mit einem Oszi ermitteln, wie lange es dauert, bis das Event zurueckkommt - gemessen wird direkt an den Rx/Tx pins, genauer geht es nicht. Gruss, Thorsten.

The simplest solution is to clear the appr. DOUT registers within the USER_SR_Service_Finish hook after the serial chain has been updated. This ensures a pulse of 1 mS (if the SRIO update cycle is set to 1) See also http://www.midibox.org/forum/index.php?topic=2701.msg17627#msg17627 Best Regards, Thorsten.

There is a USB mass storage example available at the Microchip website - have fun! Best Regards, Thorsten.

For playing speach elements it is not required to enter serial control mode. Just send bytes >= 0x80 to the SpeakJet after reset, I would avoid the control mode for the first checks to avoid any side effects. The IIC_SpeakJet firmware just forwards incoming bytes to the serial out, it doesn't need to know which kind of data is sent (ok, it would be nice for proper merging of the Rx and IIC stream, but I think that this would only be nice-to-have, but no must) To continue debugging, you could do the following: don't connect the SpeakJet Rx line to the PIC16F88 Tx output, but just connect the PIC with your RS232 interface: PC RS232 -> PIC Rx -> PIC Tx -> PC RS232 Now the data should be forwarded directly to your terminal like with the direct loopback test. And - this is important - you should be able to send additional characters from the MIOS core via IIC! This should also allow you to check, if the RS232 connections to the MAX232/PIC are ok. Best Regards, Thorsten.

MIOS is already doing "preemptive multitasking". This means for example, that after all pot values have been checked for changes, Tick() will be called before the pots are checked again. Therefore I think that there must be a problem with your program - it's very important, that functions never block the main thread! Best Regards, Thorsten.