TK.

A MIDI Thru is not really required if you chain the core modules. MIDI Out PC -> MIDI In Core 1 -> MIDI Out Core 1 -> MIDI In Core 2 -> MIDI Out Core 2 -> MIDI In PC Best Regards, Thorsten.

Hi Stefan, I will get 4 x CEM 3378 in the next days from a group order which was organized by p-cord. So, there will be some people who will use this chip with their MIDIbox SID/FM in the future :) Independent control: it's a planned feature to allow free-assignable analog outputs (to any MIDI or internal event, with offset and depth, setups stored in BankStick), but it's low-priority. I use currently only one external filter, which can be quickly connected to the outputs of MBSID/FM/SEQ, therefore I don't need such a flexible solution by myself... but it will come (at least, once the PIC18F4620 is fully working) Best Regards, Thorsten.

Hi, the LED behaviour can be configured on a very flexible way - maybe too flexible? ;-) Just read the midibox64.ini file, which is part of the mk_syx package: ################################################################################ # LED Map: assignes the LED shift registers to the Button Shift # registers or special values # Currently following values are supported: # 0 Default Setting (see Map below) # 1 Button Shift Register 1 (Button ID #1-#8) # 2 Button Shift Register 2 (Button ID #9-#16) # 3 Button Shift Register 3 (F1-F4 and Navigation Buttons: ID #17-#24) # 4 Button Shift Register 4 (Button ID #25-#32) # 5 Button Shift Register 5 (Button ID #33-#40) # 6 Button Shift Register 6 (Button ID #41-#48) # 7 Button Shift Register 7 (Button ID #49-#56) # 8 Button Shift Register 8 (Button ID #57-#64) # 9 reserved # 10 External Bank (1 of 8) # 11-15 reserved # 16 MIDI Status received for Button ID #1-#8 # 17 MIDI Status received for Button ID #9-#16 # 18 MIDI Status received for Button ID #17-#24 # 19 MIDI Status received for Button ID #25-#32 # 20 MIDI Status received for Button ID #33-#40 # 21 MIDI Status received for Button ID #41-#48 # 22 MIDI Status received for Button ID #49-#56 # 23 MIDI Status received for Button ID #57-#64 # 24-31 reserved ################################################################################ [LED_MAP] LED_SR1 = 1 # (Button ID #1-#8) LED_SR2 = 2 # (Button ID #9-#16) LED_SR3 = 3 # (F1-F4 and Navigation Buttons: ID #17-#24) LED_SR4 = 4 # (Button ID #57-#64) LED_SR5 = 5 # (Button ID #25-#32) LED_SR6 = 6 # (Button ID #33-#40) LED_SR7 = 7 # (Button ID #41-#48) LED_SR8 = 8 # (Button ID #49-#56) [/code] So, let's say you want to map the incoming events, which are assigned to button #1..#8, to the first DOUT shift register, then write: [code] LED_SR1 = 16 Best Regards, Thorsten.

(Sidenote: please add such knowledge to the Wiki, it could be very useful for newbies when we could just refer to the appr. page: http://www.avishowtech.com/midibox/wiki/index.php/Live%21) Best Regards, Thorsten.

Hi George, in general such mechanisms can be realized very easily, especially with a C based application. But I cannot give you a fast solution for especially your needs. My hope is, that somebody else feels motivated to program on such special variations, for myself it wouldn't make fun. To the problems with Greg's board: the pull-up resistor at the end of the 74HC165 (pin #10, see mbhp_dinx4.pdf) is not part of Greg's PCB, you have to add it in order to avoid the random events. It's also required to clamp all unconnected analog inputs to ground Best Regards, Thorsten.

Hi, first I would suggest to take a screwdriver, open your computer keyboard with it and check the contact of the CAPS-LOCK key, it seems that it is stucked ;-) Could you please check if the same problem exists in this release: http://www.ucapps.de/mios/midibox_lc_v2_0_alpha1.zip Best Regards, Thorsten.

Hi Rainer, the input voltage to the 7805 is too high, the recommented voltage range is between 7V and 10V... But you are right, it's strange that the 7805 gets hot with such a low power consumption, could it be that there is a short circuit at one of your boards? What is the total current draw? Like for the LCD this could be a side effect which is caused by the overheaded 7805. no I would suggest to try the circuit with a second power supply which delivers a lower voltage for Core:J1. If this works better, you know where to "debug" (the cheapest solution is the use of a 7809 between the 12V supply and the 7805 input) Another potential problem that I saw at your pictures is, that you propably forgot to mount R2 of the core module? Best Regards, Thorsten.

Hallo Ulrich, ich kann Dir den Bootstrap Loader in den PIC flashen. Meine Adresse findest Du im ucapps.de Impressum, schicke mir den PIC einfach zusammen mit dem Rueckporto zu. Gruss, Thorsten.

In the meantime I had some fun with VGA on my Spartan III board... no need for PIC hacking anymore ;-) Best Regards, Thorsten.

I don't own the source code of the windows application, maybe you could ask the name for such extensions Best Regards, Thorsten.

Hi, you could use the debug functions of MIOS Studio in order to check if anything is working. For instance, the MIOS_DIN_SRGet function allows you to check the current state of the buttons. If this function doesn't work at all (no response from core), it could mean that MIOS hasn't been uploaded correctly. In general it makes sense to upload the most recent releases of MIOS and the MIDIbox application. Best Regards, Thorsten.

Hi Jorge, updating MIOS on SID slaves is a not so well documented "corner case" - you have to reset the slave core manually. This can be done with a short cable, which is connected to ground - just tip it on the MRST# pin (pin 1) of the SID which should be updated. Thereafter send MIOS to the slave within 2 seconds. If you are using MIOS Studio, you have to enable the "Don't use feedback from core" option Best Regards, Thorsten.

Hi, for distances > 20 cm I would suggest to use the common MIDI port instead of the MIDI Link port. The functionality is the same, but the signals are more stable over such distances. Best Regards, Thorsten.

TB303 breakout box: no, I cannot tell you how it will look like exactly. I can only say, that it will have up to 24 buttons and up to 16 LEDs (means: 3*74HC165 and 2*74HC595). It won't get additional knobs, since they are already part of the control surface (step C) Best Regards, Thorsten.

the link was wrong, it's: -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta9.zip Best Regards, Thorsten.

Meine letztes Paeckchen aus den USA hat ca. einen Monat gebraucht, dabei lag sie wohl die meiste Zeit auf dem Zollamt - obwohl ich letztendlich keinen Zoll bezahlen musste... Gruss, Thorsten.

Hi, maybe this posting gives you some inspirations: http://69.56.171.55/~midibox/forum/index.php?topic=4140.0 with 512k backuped SRAM you don't need a BankStick Best Regards, Thorsten.

(I've no solution) Best Regards, Thorsten.

It's described here: http://www.ucapps.de/midibox_seq.html (search for hardware costs) Best Regards, Thorsten.

Hi, why not changing the pinning with the soldering iron? ;-) Best Regards, Thorsten.

0E 06 means: MIDI timeout - it seems that your MIDI interface (of the PC) has a problem - did you also try it with MIOS Studio? Best Regards, Thorsten.

Hi Jens, I've created a new version which should work better now, but not all "imperfections" can be fixed, due to various reasons. -> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta9.zip I wrote about the reasons some time ago, but since the answers are spreaded over this forum, I will summarize them here (with some new insights and outlooks) additional hardware for TB303 sequencer: thats possible, my private blocking point is, that I haven't found a nice case for a "breakout box" yet (which then will be connected to a joystick port of the C64 case). I don't want to start with the implementation before I've a ready-built hardware, because it makes a big difference when everything is right in place before the programming phase, or if some stuff can only be prepared but not be tested. Play mode: yes, thats a known "problem". I had to decide if I either send a "play command" via SysEx, or via a common MIDI note. I prefered to use a MIDI note, since it is transfered faster (minimum latency) and since it is compatible with the old PIC16F hardware (I didn't know that your slave uses it - but it seems that it was good that I considered this) Sending a note instead of SysEx has also the advantage, that if SIDs are assigned to the same channel, they will be started at exactly the same time without a delay. Doing the same with SysEx would mean that I would have to implement something like a "broadcast" function (SysEx message which is taken independent from the Device ID), and this would increase the code size too much for such a minor feature. For the PIC16F firmware it wouldn't be possible (out of memory) Continue playing while changing a complete patch: this would lead to many unwanted side effects and wouldn't work properly in all cases. A patch change does not only refresh the SID registers, but especially resets the whole sound engine, which is so mighty like a soft synth. There are many dependencies between the registers (values which have to be stored and written back after the change), which makes such a feature to a mess for a programmer. A proper patch change without reset would also require that the whole patch data is transfered to the SID as well as to the sound engine within one update cycle (0.8 mS), this is not possible with the PIC. It's especially not possible to send so much data to the slaves within this short timewindow, since the transfer takes ca. 260 mS. Update of incoming CC values: it should work better now, parameters to the master SID are updated regardless of the menu page. The change will be visible after one second (worst case), but it should never got lost now (in edit mode!) Update of CCs to slaves: nearly impossible with the concept. At the time where I started with the implementation of the SID application on the PIC18F I had to decide how to store the data structures. I choosed a dual storage method: one compressed structure which reflects the SysEx dump and which is easy (and fast) to handle for the control surface when multiple SIDs have to be serviced, and another structure which is optimized for the sound engine. A third structure is given by the CC->parameter assignments, but this is (fortunately) not stored in memory, but directly transfered into the SID and SysEx memory. This works fine in most cases, but it has disadvantages which must be accepted. E.g., since it is possible to change multiple parameters with a single CC (e.g. CC#16 which changes the transpose value of all three oscillators), an incoming CC cannot be easily mapped to a byte in the SysEx structure. The current solution is to read back the data from the sound engine data storage and copy it into the SysEx storage when the CPU has some free time. This works fine, but only for the master SID, because the control surface has no access to the sound engine storage of the slave SIDs (unidirectional interface...) Another solution could be to write a large function which decodes the incoming CCs and passes them to the appr. registers of the SysEx structure. This would work for the master and the slaves, but it would consume so much code memory, that other features would have to be removed. Therefore I prefered the "cheaper" solution. There are two good points which I want to mention here: 1) for the MIDIbox FM I solved such problems very early in the design phase - MBFM has a single data structure which is optimized for SysEx/CC and OPL3 accesses (it took some time to find out all relationships) - so, in MBFM the data is always consistent 2) sometimes I'm thinking about a major redesign of the SID application which doesn't consider compatibility issues, but results into an "perfect" implementation based on my experiences in the last years. But on the other hand I think that the current implementation isn't that bad, that everybody can live with such imperfections when he knows how to handle with it... However, just another remark: if the PIC18F4620 wouldn't have that f*cked EUSART and CPU bugs, all these issues wouldn't exist anymore, because this chip offers twice the flash memory, and much more RAM... the existing firmware could be freely extended without such "50% solutions". So, my hope is, that Microchip releases a new chip revision, so that it is possible to make the application perfect without the previously mentioned redesign. Best Regards, Thorsten.

Hi Jens, I put the changes into this version: http://www.ucapps.de/mios/midibox_sid_v1_7_303beta8.zip (see CHANGELOG.txt for the handling) Could you please check if everything is working now? Best Regards, Thorsten.

Hi Taylor, ok - now I understand what you mean with pulse effect. It's possible to dim the LEDs via pulse-width-modulation. It wouldn't cost much performance (and wouldn't consume too much memory) if only one or two LEDs are dimmed, but for 50 LEDs I see no chance to integrated this into the MBLC application - the CPU load is already very high, especially when the host application sends a lot of MIDI events at the same time. An additional PWM handler for so much LEDs would provoke MIDI buffer overruns. Best Regards, Thorsten.

Hi, the midibox_seq package contains preassembled .hex files, but even if you would have to rebuild the project, it wouldn't cost you additional money - the MPLAB IDE from Microchip is available for free Best Regards, Thorsten.