TK.

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.

Are you already using the new app_lcd/clcd_multi driver I gave doc? ;) Best Regards, Thorsten.

Does the player send an "All Notes Off" CC? (CC#123) - MIDIO128 could be enhanced to parse this CC and to turn off all outputs once received Best Regards, Thorsten.

In distance to IIC, SPI doesn't allow to stretch a data transfer request, accordingly the SPI slave has to handle the request immediately during a block transfer to avoid data loss. An handshaking to sync the master with the slave can only take place at the beginning of a block transfer. Since SD is interfaced via SPI as well, the resulting overall bandwidth will be (much) lower than the speed which could be achieved on a direct connection. And it would probably be lower than using the more reliable IIC protocol. Only elegant solution I see for a multi-processor setup: searching for a ready-made open source solution which is running on a faster microcontroller. The microcontroller should be faster than the PIC to avoid performance loss. Once such a project has been found, let's compare the costs ;) Best Regards, Thorsten.

Thank you, the list of your favourite features is a really useful input for me! :) Best Regards, Thorsten.

I would propose to join the GM5 order, it's the best solution, especially better than COM->USB chips (read the thread for details) You won't find firewire based MIDI interfaces because the isochronous protocol makes it unusable for live playing. Best Regards, Thorsten.

I had the idea to use a PIC18F4550 to bridge the SD card to USB and IIC, but I skipped it because of the reduced flexibility, and the slow IIC transfer speed. I also think, that getting such a system stable and foolproven would cost me even more effort. Best Regards, Thorsten.

Polyphonic recording on a single track would be easier to realize than multi-track recording; I planned to go this way Unfortunately doesn't comply with the handshaking concept I used for chain mode (see also comments about handshaking in seq_core.inc), I would have to think about a new solution, and overwork it completely. Would this really be worth the effort? I know what you mean - In such situations, I activate the "sync to measure" function in the clock divider page, until the track rolls over. Thereafter I deactivate this function again. I could also provide an additional "push-button solution", but how should it be called so that nobody overlooks this feature? I mean: you already overlooked the possibilities of "sync-to-measure", no? ;) Second one: "manual trigger" page Btw.: you know, that my ToDo list works like a FILO? ;) [tt] +---------+---------+---------+---------+---------+---------+........ New User ----> | Request | Request | Request | Request | Request | Request | Requ... request +---------+---------+---------+---------+---------+---------+........ <-------------- will be implemented --------------> <--------- --> somewhere burried in the forum [/tt] Best Regards, Thorsten.

Yes, I know about the imperfections in live record mode - I also would like to have it more intuitive I'm thinking about a possible solution since months, but haven't found a good - feasible and completely working - one. I would prefer an absolute delay which works independent from the BPM - but there are no free HW resources (especially because Timer0 will be used for the Tap Tempo function in future) A delay depending on the microticks (96th's) would lead to a different feeling on slower BPM rates. I tried this some time ago, but it was more confusing than today - and the code looked really uggly and error prone. E.g. I wasn't able to properly record on chained tracks anymore! :( See my long explanation in the 808 forum: http://www.eight-oh-eight.org/phpbb2/viewtopic.php?t=169 Summary: there is an alternative firmware available which works perfectly for drum patterns. :) There are already two different chord modes, what is missing exactly? not sure if I will ever implement this... too many requests, not enough sparetime. However, some more ideas regarding CC automation can be found via search function Best Regards, Thorsten.

To give you some numbers: reading a 512 byte sector takes ca. 3 mS, writing a 512 byte sector ca. 4 mS For comparison to an IIC EEPROM: 512 byte read ca. 11 mS, 512 byte write ca. 100 mS Flash memory consumption of the driver: ca. 600 bytes of course, it would be better - but who is skillfull enough to implement such a tool? It could be difficult to get raw data access via a common SD card reader. However, writing/reading sectors of the card via SysEx would work as usual, we are speaking about a more comfortable, and especially faster solution (if you want to read/write data from any computer w/ a cheapo SD card reader). I think, that it wouldn't be so difficult to search in the root directory for a single file which holds the complete data (e.g. "SIDBANKS.DAT"), and to go through the FAT to find out the corresponding clusters/sectors. So long the used clusters are cached in a buffer, it wouldn't decrease the access speed. It's something which cannot be realized in one day, but maybe in two until it will work ;) Best Regards, Thorsten.

Haha ;) A PIC is too slow to take advantage of the bandwidth already provided by MMC/SD cards, so it doesn't really make sense to consider alternative solutions. Isn't it much more difficult to interface a CF card to a microcontroller? Best Regards, Thorsten.