TK.

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.

thanks for the info! I know this effect from a bad USB connection I had some time ago. I used an USB hub in order to extend the USB wire by 3 meters, but this had lead to an unstable connection. Under heavy load, the MIDI interface was shortly not available, and I had to re-select the interface in the device list to initialize the driver again. But I guess that this is not the problem here. Something seems to be wrong with the MIDI interface, the driver or with Java. I'm not sure, but maybe it's related to the same Java problem which is mentioned at the bottom of this page: http://www.ucapps.de/jsynthlib.html. Although nobody has noticed this issue with MIOS Studio yet, maybe you are the first one? Could you please try the proposed workaround which uses MIDI Yoke and MIDI-Ox? And could you please try it with and without the "waiting for upload request" feature? Best Regards, Thorsten.

no, I guess that you missunderstand my statements. The new engine will be much more powerful than the old one, but I cannot consider the whishes of everybody and I tried to express, why. The MIDIbox projects require always a consideration between features vs. performance vs. development effort vs. support effort. I cannot mention it in every thread, but I've mentioned it several times in the past: the aim of the project is to allow even newbies to build an electronic device. I'm trying my best to keep it so easy than possible, so that not only a elitist circle of people with deep electronic skills and expensive equipment is able to build a MIDIbox. When you read the troubleshooting section, you know what I mean - I'm hard at the limit where the high complexity demands for more support effort than ever planned at the beginning. I just want to highlight: I don't see it as limitation that not all your suggestions can be realized. There are already a lot of new features which will be very nice and useful, and I guess that the majority of people will be happy to use them. If it would be important to get features of professional synths as a "must have", I would skip my plans and do something else This is a future product, from my experience it takes 1-2 years until you can dare to start a project with a high lifetime, in the hope that the chip won't be cancled in the meantime. This controller comes in a 100pin package, I guess that only 5% of the community is able to handle this. Another problem is the availability: you cannot buy the chip at common mailorder companies, you have to contact a distributor, and they expect an order of 1k or more as minimum limit. And even if it would be available in small quantities, the price would be propably so high, that newbies would get really sad if they damage one device during soldering with a non-adequate iron. The success guarantee is much lower. I think the biggest problem is, that embedded programming is splitted into different worlds, therefore it might be hard to understand, why certain things are not possible with different platforms. There is the hobbyist world where people are working with established devices, which are mostly in DIP packages, therefore easy to handle and easy to replace. Programming these SoC is easy to learn, there is a lot of free literature available in the internet which helps for the first steps, and programms can be developed with free toolsuites. Then there is the professional world where the device package doesn't matter, they are able to handle with 4 layer PCBs, they buy thousand of pieces and distributors are their friends. They pay some thousand of dollars for programming tools and analysis equipment, and they don't rely on reproducability - instead, they are very happy that not everybody is able to clone their hardware. Are my statements more clear now? Best Regards, Thorsten.