TK.

Did you select the AOUT module correctly in your setup file? There are different numbers for AOUT/AOUT_LC/AOUT_NG. Since AOUT_NG requires some additional configuration, it could be important that you power-cycle your MBSID after the new firmware has been uploaded, just to ensure that AOUT_NG starts properly. Best Regards, Thorsten.

Under http://www.ucapps.de/tmp/mbhp_usb_v1_3_variants.zip you will find two variants of "v1_3" (from March 2006, it has never been released) - it would be interesting, if one of this variant is working better that v1_2 Best Regards, Thorsten.

Yes, v1.2 has been released in February 2004 There is a newer version on my PC (but I haven't used it for the MBHP_USB connected with the Mac) with a new Vendor ID that I got from Voti, and some other optimisations that I don't remember anymore. It could be worth a try, just to check if 0x8ef1 somehow conflicts with another USB device. However, chances are low, especially if we consider, that I'm using a very similar MBP (6 months old) and the latest Leopard release as well Best Regards, Thorsten.

Could you please record the noise with and without connected CS in a short .wav file, and attach it to this thread? Best Regards, Thorsten.

Which firmware version are you using? I remember, that v1_0 (or v1_1?) was compiled with reduced (non-compliant) USB device descriptors as workaround for a WinME bug. v1_2 has been compiled with complete descriptor table. Also the vendor/product ID could be for interest. Go to "Apple->ABout my Mac->More Informations" (naming could differ in your installation), select the USB tab, select MBHP_USB interface. You should see Version: 0.01 Bus-Strom (mA): 500 Geschwindigkeit: Bis zu 12 MBit/s Hersteller: Thorsten Klose Produkt-ID: 0x8ef1 Hersteller-ID: 0xac89 [/code] (german installation) Best Regards, Thorsten.

Works fine at my side. Best Regards, Thorsten.

Ca. one year after Wilba introduced his famous MB-6582 to the world, which became one of the most popular MBSID designs with dozen of PCB/kits orders, he created a new version with a lot of improvements: the MB-6582 MkII More photos (for example with the first happy owner of a MkII :)) can be found at Wilba's flickr page

Great! :) Best Regards, Thorsten.

You could use the 74HC00 based In/Out indicator circuit of the MBHP_LTC or MBHP_USB module Best Regards, Thorsten.

I've a similar issue with my MBP with any MIDI USB interface (e.g. MBHP_USB*, GM5, modified MIDIsport 2x2), whenever the MIDIbox is externally powered, and MIDI In/Out are not isolated against USB power. The interface will only be regognized, when the MIDIbox is not powered while plugging the interface into the USB port. So, are you using optocouplers at the MIDI INs of MBHP_USB and Core module? It makes sense to add them. Best Regards, Thorsten.

I moved it to the assembler section. If there isn't another volunteer, I will do the changes in MIDIO128. It shouldn't be so difficult, just need some time for testing (e.g., the inversion flags have to be taken into account) Best Regards, Thorsten.

This topic has been moved to MIOS programming (Assembler). [iurl]http://www.midibox.org/forum/index.php?topic=11583.0[/iurl]

I've a rough assumption why it could fail, but it doesn't match exactly with your observations: The bootloader toggles pin RC0 one time, and RC1 128 times during startup in order to perform a "soft-reset" of a evtl. register chain which is connected to this port. This could "confuse" LCDs, which are connected to these pins. The pins are also toggled by MIOS before a reboot. This "soft-reset" is especially important when MBHP_MF is connected to port J7 to ensure that all motorfaders are stopped during/after reset. It's also required for AOUT modules. A long term solution to overcome such conflicts with IO pin usage is to provide a flag in the ID header which disables this pin toggling. But currently, the CLCD module would be the first one which would require such a flag... On the other hand, for the multi-CLCD driver there is a much better solution: as you probably already noticed, I've prepared it for 4bit mode to free pin RB0..RB3 for enable lines. I just have commited a modified version of clcd_multi which allows to use these lines for the last 4 LCDs: http://svnmios.midibox.org/trunk/modules/app_lcd/clcd_multi Note that the pin assignments can be changed externally (-> Makefile) - you don't need to modify the original module in order to assign them to other IO pins You especially don't need to copy the driver into a new directory to change the number of supported LCDs The changes are totally untested, I cannot exclude that there are one or two mistakes in the code, because I don't own this hardware, and I'm currently too lazy to double and tribblecheck the routines. So, if there are problems: please start to debug this by doing code changes in order to get a feeling about the effects before saying "it doesn't work". E.g., if some displays are working unstable, add some NOPs before the return instruction of USER_LCD_Strobe_Set and _Clr to check, if this is a timing related issue (enable pulse too small). Best Regards, Thorsten.

IRQ handling seems to be ok, so I would propose to swap the enable pins in order to check, if it is really a SW issue. If the same LCDs are failing to work, you know where you don't need to search for errors before doing speculations into the wrong direction. Best Regards, Thorsten.

Hi Lars, the source code isn't compatible to MPASM anymore, instead you have to install this toolchain: http://www.midibox.org/dokuwiki/windows_toolchain_quickstart Best Regards, Thorsten.

Fine that it is working now. No, there is no need to change the LCD type for the slave cores, since no LCD is connected anyhow. Btw.: which type of LCD are you using exactly, and where did you buy it? I need this info for the records - because normaly a LCD should work fine in 4bit mode, so that no sw/hw modification is required. Best Regards, Thorsten.

LCDs should never be concurrently handled by the main task (DISPLAY_Init/Tick) and an ISR (Timer()) In fact, I would never control the LCD from an ISR, because if a LCD is busy for more than 640 uS, this could result into MIDI data loss at the input side. Best Regards, Thorsten.

Klar, das kann man seit Urzeiten mit Transformern und Kabelumschaltern realisieren. Und davon kann man 1000te in ein Environment einpflanzen. Aus dem Logic Handbuch: Der Clou: Transformer lassen sich ueber einen oder mehrere Kabelumschalter kombinieren - und diese lassen sich ueber bspw. ueber externe MIDI Events, aber auch ueber ein selbstgebasteltes graphisches User Interface, umschalten: Falls ein Umstieg auf Logic fuer Dich keine Sache ist: mit Logic8 gibt es auch "MainStage" als kostenlose Zugabe. Da ich kein Live Keyboarder bin, kann ich nicht einschaetzen, ob es wirklich was taugt, aber Google hilft Dir sicherlich bei der Entscheidungsfindung. Gruss, Thorsten.

Der Core ist schnell genug ist, um neben Motorfadern, Buttons, LEDs, LCD Ausgabe... auch noch MIDI Processing zu betreiben. Die Uebertragung eines MIDI Events dauert ca. 1 mS, in dieser Zeit kann der PIC 10.000 Befehle ausfuehren. MIOS uebernimmt die Uebertragung im Hintergrund, waehrend also gerade ein MIDI Event empfangen oder gesendet wird (oder auch beides gleichzeitig), kann die CPU mit anderen Tasks weiterbeschaeftigt werden. Wenn ich Deine Applikation mal grob umreisse, benoetigst Du wohl 2 Cores (weil jeder Core nur 8 Motorfader handeln kann), eine handvoll Encoder, Buttons und LEDs, und eine LCD Ausgabe. Schaetzungsweise wird dies den Core nur zu ca. 40% auslasten, da ist also noch eine Menge Luft, selbst fuer suboptimal programmierten Code. ;) Andererseits moechte ich Dir auch folgendes mitgeben: Du verwendest ausschliesslich Software-Instrumente, der Flaschenhals befindet sich also zwischen den beiden Core Modulen und dem PC. Die Uebertragung eines MIDI Events dauert 1 mS, wenn Du es vervierfachst, wird das vierte Instrument 3 mS spaeter erklingen. Falls das fuer Dich akzeptabel ist, dann bist Du auf dem richtigen Weg. Ansonsten ein Alternativ-Vorschlag: MIDI Routing intern im PC. So mach ich das, wenn ich Software-Instrumente ansteuere, und zwar innerhalb eines Logic-Environments. Hier kann ich auch problemlos Konfigurations- und Rueckmeldungskomponenten einbauen, die mit dem externen Kontrolgeraet kommunizieren. Aehnliches ist evtl. auch mit Cubase moeglich Vorteil: hoehere Flexibilitaet, einfache Konfiguration (Klicki-Bunti), einfaches abspeichern zusammen mit dem VST Setup Die Core Module und das Keyboard koennen bspw. extrem preiswert via GM5 angekoppelt werden. Der Chip ist die Loesung fuer viele MIDI Probleme, und eroeffnet mit seinen 5 IOs voellig neue Wege. :) Uebrigens: wuerdest Du - so wie ich - externe MIDI Geraete ansteuern wollen, wuerde mein Vorschlag voellig anders ausfallen: MIDI Router statt Routing ueber PC, ein eigener MIDI Out fuer jeden Klangerzeuger, so dass MIDI Events parallel versendet werden koennen. Doch da sich Deine Klangerzeuger im PC befindet, sollte das Routing auch dort (lokal) geschehen. Gruss, Thorsten.

No Problem! :) Status Update: the layout is finished, and Ploytec will organize a sample, so that I can test the PCB before 400 pieces will be ordered: (/edit: final v1.1 version) I've also already ordered 500 GM5 chips. Atmel has a lead time of up to 14 weeks, therefore it could take a while - we've enough time to collect the money (more details about the final prices and the procedure soon) Best Regards, Thorsten.

This topic has been moved to Testing/Troubleshooting. [iurl]http://www.midibox.org/forum/index.php?topic=11591.0[/iurl]

To which PIC pins are D0..D3 connected? Best Regards, Thorsten.

Wow, gear porn! :) Do you allow me to blog this picture? I looked into the code, and it seems that Note Off won't be handled correctly (only Note On with velocity 00, as this is what MBSEQ uses internally). A bugfix was easy, but I'm currently not able to try this out by myself... So, could you please check if the modification is working? -> http://www.ucapps.de/tmp/midibox_seq_v3_snapshot.zip Best Regards, Thorsten.

You can do this in the manual trigger page with all selected tracks - you can re-start from any step you want Alternatively, go into the loop page and change the loop end pointer to 1 - change back to the original value (e.g. 16) after you heart enough MiMiMiMis - this will result into a similar effect Best Regards, Thorsten.

I uploaded the driver we used on a MBLC with 4 CLCDs to: http://svnmios.midibox.org/trunk/modules/app_lcd/clcd_multi/ And the test application to: http://svnmios.midibox.org/trunk/apps/examples/lcd7/clcd_multi/ Feel free to enhance & test the driver for 8 CLCDs Best Regards, Thorsten.