TK.

Hi Dan, the firmware cannot forward incoming events to the output port by itself, so it must be a software routing issue (check your MIDI-Ox setup) or a direct feedback of the Rx/Tx signals at your board Best Regards, Thorsten.

Which display are you using, sounds like a graphical display? And are you sure about the 300 A, such a high current would melt the tracks? If you assumed that this is a character display, but it isn't, it could be a short because of the different pinning. And you would possibly need a customized display driver... Best Regards, Thorsten.

Thanks PayC :) Please wait with the Control Surface until all features are implemented. I change my concepts from time to time (remember the concept one month ago?). However, I guess that most of the hardware will be used for the final one, but I could add some more buttons and LEDs (e.g., for the chain mode I definitely want to add a Forward, Rewind and Pause button), and I will rearange some buttons of my current boards Btw.: the MIDIbox SEQ is grooooooovin' now :D With 4 times the common MIDI clock resolution (384 ppqn) Example: http://www.midibox.org/midibox_seq/mbseq_v2_demo3.mp3 (Bass drum is played on Track 1 w/o swing, HiHats are played on Track 2, Swing is varied from 1 to 16) Makes fun... Does anybody know other grooving styles? (from the mathematical point of view?) Best Regards, Thorsten.

It will be possible to switch between different patterns and to edit them during a performance w/o timing problems. But it won't be possible to save the changes w/o timing problems.... thats the limitation of the BankStick Best Regards, Thorsten.

Hallo, die Zahl 12000 bedeutet dass Dein Display ca. 4 mal langsamer als ein HD44780 kompatibles Display ist. Und daraus laesst sich wiederum schliessen, dass mit einem VFD der Display Update 3.2 mS statt 800 uS dauert (bei 2x20 Zeichen), und 6.4 mS bei 2x40 Zeichen Diese Zeit halbiert sich, sobald der getrennte Update Request fuer die obere und untere Zeile eingebaut ist. Damit kannst Du dann wahrscheinlich leben... ;-) Gruss, Thorsten (der in seinen U110 eine XG Wavetable Karte eingebaut hat ;-)

Hallo, dass CS_STAT_UPDATE_PARAMETERS bei Dir weniger ausmacht als das LCD, stimmt mich schon etwas nachdenklich. Ohne handfeste Zahlen kann ich Dir eigentlich keinen serioesen Vorschlag machen, deshalb habe ich mal schnell einen Benchmark geschrieben, mit dem man die Performance genaustens ermitteln kann (das hatte ich sowieso schon immer mal vor...). Siehe auch "MIOS Toy of the week" Welcher Counter-Wert ergibt sich bei einem VFD? Prioritaeten: nein, auch die eingehenden Noten und der SID Register Update werden mit niedriger Prioritaet behandelt (der PIC kann nur zwei Prioritaeten) - so etwas nennt sich kooperatives Multitasking, bekannt aus den alten Amiga, Atari und Mac Zeiten. Falls eine Routine mal laenger braucht, muss man sie splitten, wie weiter oben erwaehnt. Unter normalen Umstaenden ist das kein Problem, ein komplexeres Multitasking mit Kontextswitching, etc, wuerde nur zu groesseren Latenzen fuehren und nicht unbedingt ein Performancegewinn bedeuten (siehe Windows). Save-Menue: ist mir noch nicht aufgefallen, werde ich mir dann irgendwann einmal anschauen. Danke fuer den Hinweis! Gruss, Thorsten. P.S.: die SID Sound engine, MIDI In/Out Buffer, DIN/DOUT chains werden hingegen mit hoechster prioritaet behandelt und sind deshalb stets stabil im Timing.

Cool design for a MIDIbox SID w/o control surface, made by Trapstate:

It always makes sense to output some values on a LCD, or just to send them out via MIDI to get some kind of logfile (here you only have to ensure that the MIDI protocol won't be violated - means: first byte should be a status byte like 0xF0, thereafter as much bytes as you want, but 7th bit should never be set (ensure this by masking it with 0x7f - the stream must end with a 0xf7) Best Regards, Thorsten.

Ever wanted to know the performance of your LCD? -> please find a benchmark in the MIOS Download section. From the header: ; ; LCD Performance Measuring Application ; ; This is some kind of benchmark which helps to evaluate the performance ; of various character and graphical displays, as well as the execution ; speed of a custom LCD driver ; ; 16 characters are print 4 times (-> 64 characters), the execution time ; is measured with timer3, prescaler 1:8 - this means, that the counter ; result has to be multiplied by 8 and 100 nS (@40 MHz) to get the ; absolute delay ; ; The result will be print on LCD, but also sent via MIDI ; (F0 <hex-digit 1> <hex-digit 2> <hex-digit3> <hex-digit4> F7, MSB first) ; ; And here the results: ; ; Displaytech LCDs from Reichelt: ; o 2x16 KS0070B (HD44780 compatible): 3252 * 8 * 100 nS = 2.60 mS ; o 2x20 KS0076B/KS0063 (HD44780 compatible): 3177 * 8 * 100 nS = 2.54 mS ; o 2x40 KS0076B/KS0063 (HD44780 compatible): 3056 * 8 * 100 nS = 2.44 mS ; o KS0107/0108 based 240x64 GLCD (sold out): 6124 * 8 * 100 nS = 4.90 mS ; ; For reference: 2x40 with 4-bit interface, nearly no difference! ; o 2x40 KS0076B/KS0063 (HD44780 compatible): 3108 * 8 * 100 nS = 2.48 mS ; ; Various displays: ; o Matrix Orbital via IIC: 4612 * 8 * 100 nS = 3.69 mS ; o T6963C in vertical mode: 10647 * 8 * 100 nS = 8.51 mS ; o T6963C in horizontal mode: 37420 * 8 * 100 nS = 29.93 mS (!!!) Have fun - and publish your results here! :-) Best Regards, Thorsten.

The pointer calculation part could be wrong (looks dangerous ;-) - why not initialising FSR0 with CHANNEL_GAIN_7 before the outer loop will be entered, and accessing the register with POSTDEC0, so that it will be decremented automatically (But I'm not sure if this is the error...) Best Regards, Thorsten.

Hi, yes, it should be 5V - maybe a short. Btw.: there is a better measuring diagram which can be found here: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

No, in the main.asm somewhere within the USER_Init function Best Regards, Thorsten.

No, too much effort... :-/ Best Regards, Thorsten.

Hi, DrBunsen: I will do what I can (and what the PIC18F is able to do ;-)) ok, here some news: although the code is very modular now, I noticed that the performance of the SEQ_CORE is much better than expected. The worst case processing time I measured was about 150 uS (microseconds!) when all 4 tracks are playing arpeggios simultaneously. In the last days I only made some small additions to the user interface (ca. 50% is implemented), but mostly was busy with tweaking on some nifty sequences (see also the bottom of this posting) - to check the usability and to get some ideas which features make the editing easier. Sometimes I'm also changing some previous concepts, e.g. in the meantime there is a 3rd version of the arpeggiator which is now more understandable, resp. more intuitional than the versions before Once the user interface is ready, I will think on features like Morphing (no problem), Grooves (needs some evaluation) and Chains (...of pattern), and so on... Concerning the chain mode: with some cut backs it could be possible to play 4 patterns at the same time, in other words: to play 16 tracks. Drawback: only one pattern can be hold in the edit buffer and modified live, the other 12 tracks have to be played directly from BankStick. A good compromise for a simple step sequencer, isn't it? :) Ok, and here some impressions about the current design state (I don't work daily on it, only when I have some sparetime and feel motivated, so I cannot say you anything about the date of the first release): Some panel views (will be enhanced by more views): Ok, and here some auditable results for people who maybe don't know what they can expect from a simple step sequencer :) Very experimental (the original is about 3 hours long, but I forgot to record it ;-)), many Fx have been added, some of them are also controlled from the MBSEQ via CCs. all patterns made with MBSEQ and recorded with Logic whenether they worked (means: the MBSEQ doesn't play the whole song - yet) http://www.midibox.org/midibox_seq/mbseq_v2_demo1.mp3 Just an arpeggiator test, nothing more - edited within 5 minutes, played some random chords and took the best ones ;-) Only the lead sound is controlled from MBSEQ (you hear the MIDIbox SID in action :)), the drums are comming from my Groovebox which acts as MIDI clock master in this example. http://www.midibox.org/midibox_seq/mbseq_v2_demo2.mp3 Best Regards, Thorsten.

Do you have access to the MIDI Out of the slaves? Then you could use the CRC application to ensure that MIOS has been uploaded correctly, just add following lines to USER_Init: movlw 0xf0 call MIOS_MIDI_TxBufferPut swapf CRC_H, W andlw 0x0f call MIOS_MIDI_TxBufferPut movf CRC_H, W andlw 0x0f call MIOS_MIDI_TxBufferPut swapf CRC_L, W andlw 0x0f call MIOS_MIDI_TxBufferPut movf CRC_L, W andlw 0x0f call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut and MIOS should return the CRC digits after startup (see also the download page - MIOS V1.5b returns: F0 06 0F 05 0D F7 Best Regards, Thorsten. /edit: new version now available in the download section

Dan, your designs alway have a special touch - great :) Best Regards, Thorsten.

Hallo, die Analyse mit dem Oszi hat folgendes ergeben: Der Update des gesamten 2x20 Displays dauert ca. 800 uS (bei einem 2x40 HD44780 Display ca. 1.6 mS), die Abarbeitung von CS_MENU_UpdateCCPara ca. 1.2 mS. Doch damit nicht genug: in CS_MENU_UpdateCCPara wird faelschlicherweise ein zweiter Display Update requested, und der wird dann ca. 200 uS spaeter zusaetzlich abgearbeitet. Das bedeutet, dass bei einem 2x40 Display die eintreffenden CCs ein Delay von mindestens 2.8 mS + 1.6 mS erzeugen. Falls zwischendurch erneut ein CC eintrifft (was innerhalb dieser langen Zeitspanne durchaus moeglich ist), wird erneut ein Update erzwungen, und dieses unregelmaessige Verhalten kann durchaus zu einem hoerbaren Jitter fuehren. Abhilfe: in "CS_MENU_UpdateCCPara" den unnoetigen DISPLAY_UPDATE_REQ rausschmeissen, so dass schonmal 1.6 mS eingespart werden den unteren Teil von SID_MIDI_CC wie folgt aendern: #if CS_ENABLED == 1 IFCLR CS_MENU_MODE, CS_MENU_MODE_EDIT, rgoto SID_MIDI_CC_NoUpdate ;; request update of CS parameters bsf CS_STAT, CS_STAT_UPDATE_PARAMETERS ;; force a display update bsf CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ SID_MIDI_CC_NoUpdate #endif Vorteil: zero delay, Nachteil: die im CS gespeicherten Parameter koennen nur noch im Edit Modus von extern veraendern werden - das ist aber verkraftbar. Bleiben noch zwei weitere Aenderungen, die ich dann demnaechst einbauen werde: - einen speziellen Update Request, der lediglich die untere Zeile updated, um das Delay auf 400 uS zu minimieren. Die Uebertragung eines einzelnen MIDI Events dauert 1 mS, die LCD Ausabe wird sich nicht mehr bemerkbar machen - viel mehr Aufwand ist an dieser Stelle also gar nicht notwendig. - beim Wavetable-Sequenzer werde ich das WT_STATE_NEXT flag durch einen Counter-Mechanismus ersetzen, so dass er niemals aus dem Takt kommt. Diesen Mechanismus habe ich mittlerweile auch in die MBSEQ eingebaut, sie laeuft nun selbst nach einer Stunde noch synchron zur Masterclock. Soviel zu diesem Thema... ;-) Gruss, Thorsten.

Hello again, ja, Du kannst Encoder an die MIDIbox64 anschliessen, dazu muesstest Du jedoch den Source Code leicht modifizieren. Siehe auch: http://www.ucapps.de/tmp/mios_enc_integration.txt Gruss, Thorsten.

Hallo Martin, das sollte eigentlich mit SFB #02 [00-0F] problemlos funktionieren. Siehe auch: http://www.ucapps.de/midibox/midibox64_sfb_table.txt Scheinbar hast Du SFB #00 01 verwendet? Gruss, Thorsten.

Das mit dem USE_GLCD flag schaue ich mir irgendwann einmal an... Ja, die SID Applikation geht noch davon aus, dass es sich bei LCDs mit ID > 0 grundsaetzlich um ein graphisches LCD handelt. Deshalb gibt es nun das USE_GLCD flag, aber es wird so noch nicht funktionieren, das ganze befindet sich wie gesagt in Vorbereitung und wird vielleicht ab MIOS V1.6 oder spaeter in voller Schoenheit funktionieren (Prioritaet: ziemlich niedrig, zumal die Applikationen daran angepasst werden muessen) Das mit dem Busy hast Du wie bereits erwaehnt falsch verstanden. Es geht hier nicht darum, Zeichen zu unterdruecken, sondern eher darum, dass MIOS nicht in einer Endlosschleife haengen bleibt, wenn mal zufaellig kein LCD angeschlossen ist. Buffern: das moechtest Du nicht wirklich! Die MIDIboxSEQ kann bspw. 2x80 Zeichen darstellen, das sind 160 Byte, die kann man fuer schoenere Dinge verwenden. Das Control Surface der MBSEQ habe ich uebrigens etwas geschickter programmiert, hier werden nur die Items upgedated, die sich wirklich geaendert haben. Optimiert und verifiziert habe ich das ganze mit einem Oszilloskop (ein Item-Refresh dauert ca. 200 uS). Den Aufwand koennte ich auch irgendwann einmal fuer die MIDIbox SID treiben, aber nicht heute, und auch nicht in den naechsten 1-2 Wochen, aber vielleicht danach? Schaunmer mal... das waere jedenfalls der bessere Weg. Echtzeit: hier uebersiehst Du, dass die Echtzeit-Tasks jederzeit die Display-Ausgabe unterbrechen koennen, deshalb braucht die Ausgabe auch manchmal etwas laenger. Wenn es soweit kommt, dass andere Low Priority Jobs (wie bspw. der Wavetable-Handler) zu lange warten muessen, geht man normalerweise her und splitted die Display-Ausgabe in zwei oder mehrere Teiljobs, die dann mit jedem USER_Tick alternierend ausgefuehrt werden. Dies waere eine Loesung, wenn sich der Display-Inhalt komplett aendern wuerde, aber bei der MBSID ist es ja nur ein kleiner Teilbereich, deshalb wuerde sich hier die gleiche Methode wie bei der MBSEQ besser eignen. Du schreibst: mit der DISPLAY_UPDATE_REQ Methode wird so etwas aehnliches bereits gemacht. Es wird nicht sofort refreshed, sondern nur dann, wenn CS_MENU mal wieder dran kommt. Und das ist auch normalerweise ausreichend, solange die Displayausgabe < 1 mS dauert. Wenn bspw. viele MIDI Events aufeinmal eintreffen, arbeitet MIOS_MPROC erstmal den gesamten Buffer ab, bevor USER_Tick aufgerufen wird. Du verwendest ein 2x40 Display, hier dauert die Ausgabe doppelt so lange. So habe ich die MBSID noch nicht betrieben, und deshalb ist mir dieses Performanceproblem auch noch nicht so bewusst geworden. Ich verwende auch normalerweise kein Modwheel, sondern aendere die Parameter direkt am Control Surface... Aber wie ich bereits oben schrieb, gibt es geschicktere Methoden, das auszumerzen, allerdings kann man das nicht in 5 Minuten erledigen, sondern muss gezielt die Timings mit einem Oszi ausmessen und dort optimieren, wo es wirklich Sinn macht. Wenn ich mal nichts besseres zu tun habe (vielleicht hast Du ja mitbekommen, woran ich gerade bastle...) werde ich mir das mal anschauen. Companion: das ist die Loesung speziell fuer sehr langsame LCDs (insbesondere fuer die billigen graphischen LCDs), bei der die Befehle in einem grossen Buffer aufgefangen werden. Aber Dir waere wohl dann mit der Aenderung im MBSID CS_MENU bereits geholfen - abwarten und Tee trinken. Update ausbauen: klar, kannst Du machen, siehe sid_midi.inc, SID_MIDI_CC - dort stehen die beiden Update Requests. Schmeiss die mal raus, dann sollte das MOD-Wheel keine Auswirkungen auf das Timing haben. Du koenntest dieses Verhalten auch ueber einen zusaetzlichen Button steuern, wie waere es bspw. mit dem "CS_MENU_MODE, CS_MENU_MODE_EDIT" flag? Wenn es nicht gesetzt ist, einfach die beiden Befehle ueberspringen. Ich sehe uebrigens gerade, dass dort "CS_STAT_UPDATE_PARAMETERS" gesetzt wird - das ist evtl. der eigentliche Uebeltaeter, muesste ich auch mal mit dem Oszi ausmessen und gegenenfalls auf Zeit (und nicht auf Codegroesse) optimieren Aber wie ich bereits angedeutet habe: momentan liegen meine Prioritaeten woanders. Ich betreibe meine MBSID gerade mit der MBSEQ, da benoetige ich keinen Wavetable-Sequenzer ;-) Gruss, Thorsten.

Great! So sorry for all the trouble, till yesterday I was very sure that especially the MIDI Rx handler is 100% bugfree (ok, it was before MIOS V1.4 ;-)) and therefore assumed an hardware problem - such errors are very common when existing code will be extented after so long time and when no testsuite exists which covers all functions to ensure that they are behaving like before the changes. Note: the final MIOS V1.5b is different from yours, please use the released binary to avoid confusion if anything should fail again Best Regards, Thorsten.

How does it behave when you just solder the D6 input to another button? Best Regards, Thorsten.

Since I had to release a new MIOS version anyhow, I added some code which is necessary to access a 4bit display. Just use mios_v1_5b (or higher) and add following lines below USER_Init: ;; use a CLCD, E input of first CLCD at D.7, E of second CLCD @C.4 ;; using the 4-bit interface: ;; -> connect MBHP_CORE:J15:D7-D4 of the core module to D7-D4 of the LCD ;; -> left MBHP_CORE:J15:D3-D0 of the core module open! ;; -> tie D3-D0 of the LCD to ground movlw 0x37 | 0x80 ; E1: D.7, 4bit interface movwf MIOS_PARAMETER1 movlw 0x24 | 0x80 ; E2: C.4, 4bit interface movwf MIOS_PARAMETER2 movlw 0x00 ; LCD type 0 call MIOS_LCD_TypeSet It doesn't matter if you connect a second display or not to the core, this is just an excerpt from the MIOS_LCD_TypeSet example... Best Regards, Thorsten.

This "service pack" adds support for CLCDs with 4bit interface and contains an important bugfix for the MIDI receiver in conjunction with keyboards which are sending MIDI events in Running Status mode See also: http://www.ucapps.de/mios_changelog.html There is no new source code package, but the changes are available in the CVS Best Regards, Thorsten.

Hi Dan, strange - did you ensure that you've uploaded the change correctly? Or better: could you please check this MIOS version in your environment http://www.ucapps.de/tmp/mios_v1_5b.syx.zip Best Regards, Thorsten.