TK.

Hi Seppoman, too bad that I just have release alpha2 ;-) Could you please check it with the new version? See also: http://www.ucapps.de/midibox_sid_changelog.html Best Regards, Thorsten.

Hallo, die erste Idee ist eigentlich schon obsolet, wenn Du Dir mal die v1.6alpha1 anschaust. Hier wird das Display nicht aufeinmal, sondern schrittweise mit jedem USER_Tick aufgebaut. So ist es nun voellig egal, aus wievielen Items ein Menue besteht, Du wirst das Delay von ca. 300 uS pro Parameter (bei Deinem Display ca. 1.2 mS) nicht merken! Die Kopplung an den Edit-Button waere nicht ideal gewesen, sie wuerde die Bedienung nur noch komplizierter machen. Egal, wo ich auch etwas dokumentiere, meistens landen Dinge, die man nicht auf Anhieb versteht, doch im Forum. Und die Frage "warum zeigt das dumme Control Surface keine Parameter an, wenn ich an einem Knopf drehe" haette sich sehr schnell zu einem Dauerrenner entwickelt... Zum Vorschlag fuer das Menue-Handling: Anfangs war die Menuesteuerung sogar ohne den laufenden Cursor programmiert, genauso wie Du es vorgeschlagen hast, aber aus irgendeinem Grund habe ich es dann doch anders gemacht - leider kann ich mich an den Grund gerade nicht erinnern, aber vielleicht faellt es mir irgendwann mal wieder ein... ;-) Ja, CS_MENU_ENC_CS_Handler muss in diesem Fall angepasst werden - hier habe ich bisher auf Code Size optimiert, deshalb laesst er sich nicht so bequem erweitern. U110: habe die XG Karte einfach zusaetzlich eingebaut, und dabei an den MIDI Thru sowie an die Audio-Ausgaenge 5 und 6 angeschlossen. Habe das Teil aber auch schon seit Monaten nicht mehr angeruehrt... ;-) Gruss, Thorsten.

Hi Thomas, 1) check the MIDIbox64 and MIDIbox MF applications, they already support remote access via SysEx, and therefore give you some good examples. The control bytes for MIDIbox Link are sent by MIOS_MIDI_BeginStream and MIOS_MIDI_EndStream --- see also the functional description (http://www.ucapps.de/mios_fun.html The easiest way for sending MIDI events: just copy the "midi_evnt.inc" driver from the MIDIbox64 application into your project. 2) > When exactly will this functions be called You know where to find the documentation of MIOS functions? > USER_MPROC_NotifyFoundEvent After a complete MIDI event has been received and have been found in MIOS_MPROC_EVENT_TABLE > USER_MPROC_NotifyReceivedByte After any byte has been received > USER_MPROC_NotifyReceivedEvent After a complete MIDI event has been received > What happens if two events come directy after each other? USER_MPROC_NotifyReceivedEvent will be called twice, for every event seperately. > What happes if there are to many events to store? MIOS provides a Rx buffer of 64 bytes, so an overrun could only happen if your application would stall the USER_Tick for about 60 mS - so long as your project is programmed properly, this shouldn't be an issue. The max. usage of the Rx buffer is normaly about 3 bytes > Does the last one win or will it be lost? The last bytes will lost - but as I wrote: this is no issue with the fast PIC18F > What happens after MIDI-Timeout? The whole buffer will be cancled Btw.: some additional infos about latency, delays etc. can be found in the uCApps FAQ Best Regards, Thorsten.

Hi John, there are a lot of simple and also more complex examples for parsing SysEx in the MIOS download section. A simple one: see the led_digits_mtc_v1_3.zip example or the midimon (mtc.inc) More complex ones: see the MIDIbox applications like "midibox64" or "midibox_lc" Don't use USER_MIDI_NotifyRx for parsing SysEx streams, this is an interrupt service routine which should only be taken on very special cases (e.g. for receiving a MIDI clock or for a software implemented MIDI In LED) USER_MIDI_NotifyReceivedByte is a low priority task (at the same level like USER_Tick) - which doesn't mean that it has a mentionable latency!). Best Regards, Thorsten.

Hi, normaly the MIOS device ID has to be specified when burning the bootstrap loader (see also the Bootstrap Loader help page), but the change_id application allows you to set a new ID w/o using a PIC programmer. Best Regards, Thorsten.

The easiest way to change the MIOS device id is the use of "change_id_v1_4" - it can be found in the MIOS download section. Best Regards, Thorsten.

"rastnest" renders the layout again, thereafter you will see a ground plane between the pins (which fortunately also can be found on Mikes premade PCBs) SmashTV has updated the .brd file - thanks! :) Best Regards, Thorsten.

Hi Wilba, like already mentioned somewhere else in the forum, the AOUT circuit is stable, I will maybe add some caps (although they are not really required, but just to improve the quality), and I will add an additional port to the upcoming AOUT_MUX module before starting with the layout (AOUT_MUX won't be supported by MIDIbox SID!) > How do you get the +12v/-12v supply? I'm using the same one like for the LFOs: http://www.ucapps.de/midibox_ext/lfo/lfo_powersupply.pdf I guess it makes no sense to use a voltage converter for the negative voltage, you definitely want to have stable (and not pumping) signals Best Regards, Thorsten.

Hi *, Due to requests I've decided to release an alpha version of MIDIbox SID V1.6, which is now available in the download section in parallel to the old (and stable) V1.5c. See http://www.ucapps.de/midibox_sid_changelog.html The final v1.6 will be released in some weeks or months... Please report bugs here! Best Regards, Thorsten.

Hallo, sieht doch gut aus! Am Master musst Du nichts aendern, fuer den ersten Slave DEVICE_DEFAULT_ID auf 0x01 setzen und CS_ENABLED auf 0. Nach dem Start noch den Link aktivieren (den entsprechenden Button druecken), und schon kannst Du auf dem Slave ein paar Noten spielen. Gruss, Thorsten.

Not really, now you know that the problem must be located somewhere around IC8. Sorry, I cannot give you much more suggestions anymore... but I hope that you've learned from this session how to detect shorts in a circuit when visual control doesn't help anymore Best Regards, Thorsten.

Hi Wilba, you are absolutely correct - I've fixed this in the posting above Best Regards, Thorsten.

Thats simple: now cut the track near by IC8, Pin 12/13 (so that is has no connecection to the rest of the PCB blabla), and solder a cable from the TxD0 pin directly to those pins - results? Best Regards, Thorsten.

So, there is no connection between the TxD0 pin and the first MIDI Out anymore (see question (1)), but it sends MIDI Data? In this case I will give you some new instructions ;-) Best Regards, Thorsten.

Ok, once again, step by step, please answer every question: 1) cut the track near by the TxD0 pin of the Cypress chip, so that this output hasn't a connection to the rest of the PCB anymore, ok? 2) cut the track near by the RxD0 pin of the Cypress chip, so that this input hasn't a connection to the rest of the PCB anymore, ok? 3) cut the track near by the optocoupler output of the first MIDI In port (IC4, Pin 6), so that this output hasn't a connection to the rest of the PCB, ok? 4) now connect an external 1.2k resistor to pin 6 of IC4, ok? 5) solder a wire between IC4, pin 6 and the RxD0 input of the Cypress chip. Note: a direct connection, not via any PCB track! Does the MIDI In receive proper MIDI events now? 6) if not: connect the RxD0 pin with IC5, pin 6 instead and send some events to MIDI Port 2, does MIDI-Ox display proper events? Best Regards, Thorsten. P.S.: connection to 3.3V was just a test to ensure that the RxD0 pin is not floating. With 3.3V you should receive *no* MIDI event

...and you are receiving also invalid MIDI events when the Rx line is connected with 3.3V or with the output of the second optocoupler? This would mean that your wire is not soldered correctly... Best Regards, Thorsten.

...means you are receiving any (but invalid) MIDI events in MIDI-Ox from the first MIDI In port? What is the exact status now? (I'm also confused ;-) ) Best Regards, Thorsten.

Great! :) Did you create the PCBs by yourself? I just noticed that the .gif contains the wrong snapshot, but the layout data in .brd is correct once you enter the "ratsnest" command - I will fix this. Best Regards, Thorsten.

Hi, so long as the MIOS ID of the slaves is different from the MIOS ID of the master core, you can program the chips through the master (MB Link has to be enabled). Note that this requires also a different "-device_id" when using the hex2syx.pl script. The SID slave IDs have to be different anyhow. Best Regards, Thorsten.

Hi Chriss, You've to start jsynth with "java JSynthLib" from the command shell. The .jar file doesn't contain the MBSID driver. MIDI related issues: the developers of jsynth have prepared a new release v0.18 which provides proper MIDI drivers based on the new MIDI engine of Java v1.4.2 Unfortunately it hasn't been released yet, so you have to download the sources from the CVS view and compile it by yourself (requires Java JDK): http://sourceforge.net/cvs/?group_id=41208 The CVS package already contains the MIDIbox SID driver (will be part of v0.18 ) Best Regards, Thorsten. Btw.: great to hear that MBHP_USB is running under Mac OSX! :-)

You are doing this to ensure that there is no "invisible" short between the Tx and Rx track. Some days ago a user sent me his core module since he assumed a mysterious problem with the PIC (it went into reset during programming via MIDI). It turned out that there was an invisible, parasitic resistance (maybe flux) between the MCLR# pin and ground which caused the reset once the power consumption was too high during programming. Such errors can only be detected by cutting tracks and bypassing the connections. Based on your descriptions I expect a similar problem Best Regards, Thorsten.

ok, so add an external resistor. Alternatively you could connect the Rx pin directly with the output of the second (working) optocoupler, just to check if the receiver works Best Regards, Thorsten.

P.S.: the 1.2k pull-up resistor between the optocoupler output and +5V is still required Best Regards, Thorsten.

So, now do the same with the Rx track, but cut it near by the Cypress chip and near by the optocoupler. Use a cable to connect the optocoupler directly with the chip - results? Best Regards, Thorsten.

alright, and what does happen when you rip up the track to TxD0 (pin #15) very near by the Cypress chip? This is just a simple test to ensure that there isn't a short between Rx and Tx, later you can patch this connection with a short piece of cable Best Regards, Thorsten.