TK.

MIDI doesn't provide handshaking, this means: it's not enough to send the bitstream, you need some error correction or a second level protocol in order to ensure data coherency Best Regards, Thorsten.

No, you need to download the MPLAB toolchain from the microchip homepage as well in order to assemble the source code. The resulting .hex file can be uploaded with MIOS Studio Best Regards, Thorsten.

I also think that this is because of a missing heatsink - the two LCD backlights make the 7805 really hot, sooner or later the voltage will drop much below 5V, and this resets the chip Exit button: it should work, you will get into the menu Drum mode: the future MBSID V2 will offer more possibilities, but I don't plan to enhance the drum mode. Instead I'm planning a more general way to assign values to the layers, which makes the drum mode obsolete. (as Moxi has mentioned - check the wishlist -> http://www.ucapps.de/midibox_seq_v3_wishlist.html :) Best Regards, Thorsten.

Rio, I think that you've just missed all the infos I've already written down here: http://www.ucapps.de/midibox_sid_v2_wishlist.html Best Regards, Thorsten.

Changes in cs_menu_io_tables.inc are only required when you've built a Control Surface, and when the control elements (rotary encoders, buttons, LEDs) are not connected to the original pins which are documented in my connection diagrams. In general: so long you are building a MIDIbox which doesn't differ with my own hardware, then you normaly don't need to change the sources, and you can use the precompiled .hex files Perl: I think you don't really need it for MBSID so long you already have MIOS Studio and Java, is this the case? Your "problem" with internet bandwidth brought me to the idea, that somebody could compile a CD which contains all tools which are required for MIOS based applications. It could be distributed via mailorder. Unfortunately I don't have that much time to do such things in parallel to all the other stuff, but maybe somebody else feels motivated? Writing docs: this would be really great, especially because I think that you will see the projects more from the user, and not from the developer side. This should result into a much more understandable documentation for normal MIDIbox users who don't have the technical background knowledge. The Wiki is predestinated for such "user manuals" - regardless how much will be contributed, it makes me and all the users happy :) Best Regards, Thorsten.

I think that even driving a matrix with let's say 1024 buttons (via 1 DOUT and 4 DINs) is not impossible, it's only a question of RAM consumption and desired latency Best Regards, Thorsten.

Hallo Pico, ich glaube, dein Projekt wuerde auch die Allgemeinheit interessieren! :) Solche Messstreifen sind schon etwas feines, wie hoch ist die Aufloesung? Und wieviel kosten sie? Man koennte sie bspw. als Ersatz fuer Motorfader hernehmen :) Gruss, Thorsten.

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.