TK.

Yes, the routing is correct now - it should work. MIDI In should not be connected, it should only be monitored. Whats about the loopback test, is it working now? Do you receive a proper the Upload Request message after power-on now? Did you also try to upload MIOS with the SysEx tool of MIDI-Ox? Best Regards, Thorsten.

Addendum: wenn Du "DEFAULT_MORPH_FUNCTION_ENABLED" auf 0 setzt, erzielst Du den gleichen Effekt (es spart etwas Speicher) Gruss, Thorsten.

es gibt zwar einen (siehe Posting von Pilo under MIOS Programming), der ist jedoch nicht 100%ig MPASM kompatibel. Vor ein paar Jahren habe ich MPLAB unter wine gestartet, das lief eigentlich. Habe es allerdings lange nicht mehr ausprobiert Gruss, Thorsten.

Coool! Was lange waehrt, wird endlich gut - danke fuer den Hinweis! Gruss, Thorsten,.

Hallo, Basti: kannst Du mal eine Auflistung machen, welche Geraete Du genau zusammenschliessen moechtest (bspw.: Controller, Sequencer, Sampler, ...), wie stark die Chips so in etwa ausgelastet werden (hierzu reichen ein paar Eckwerte, wie bspw. die Anzahl der Bedienelemente, die Anzahl der gleichzeitig abgespielten Tracks, die Samplerate...), ob und wie sie untereinander kommunizieren sollen, welche Art von Daten ueber die Schnittstelle uebertragen werden sollen, und alles, was dazu hilfreich sein koennte, die Auslastung des gesamten Systems abzuschaetzen. Dann kann ich Dir sagen, ob I2C ausreichend ist, ob andere (oder mehrere verschiedene) - einfach zu realisierende - Schnittstellen besser geeignet sind, usw. Ein Hinweis am Rande: neben Pitch Bender (leider nur 16 Kanaele) ist es via NRPN ja bereits moeglich, 14-bittige Werte nach MIDI Standard. zu uebertragen. Mit NRPN sind es bis zu 16*65536 Adressen - wenn man sich auf 16 * 256 moegliche Adressen beschraenkt, sind fuer einen NRPN Stream nur 7 Bytes notwendig. Angenommen, man betreibt eine serielle Schnittstelle mit 1 Mbit/s, dann waere dieser Stream in --- sagen wir mal --- 100 uS uebertragen. Hier habe ich bereits einen pessimistischen 25%igen Protokolloverhead eingerechnet (alternativ ginge auch ein propritaerer SysEx String mit 5..6 Bytes, doch solche Streams werden von den meisten MIDI Programmen nicht unterstuetzt) Reaktor (ich beziehe mich auf ein voriges Posting von Dir) erlaubt bei Steuerdaten eine Updatefrequenz von maximal ca. 3kHz (den genauen Wert weiss ich gerade nicht, ich weiss nur, dass komplexere Synths damit auf meinem 2.8 GHz PC nicht mehr laufen - das kommen noch andere Probleme auf Dich zu) --- Werteaenderungen werden also ca. 300 uS verarbeitet. Somit kannst Du (schaetzungsweise, ich habe es noch nie ausprobiert) 3 High-Resolution Werte gleichzeitig zu Reaktor senden, ohne dass die Information bis zum naechsten Updatecycles verloren geht. Ich habe nur zwei Haende... ;-) Ok, das ist uebertrieben, sobald ein Sequencer oder bspw. ein AD-gewandelter externer Oszillator die Werte schickt, wird es schwierig. Hier sollte man wohl doch lieber von MIDI absehen und direkt eine Soundkarte zur Erfassung der Werte verwenden. Was ich jetzt schon sehe, ist das Problem des Interfacings an den PC. I2C laesst sich jedenfalls nicht direkt betreiben. Was bleibt ist USB oder der Parallelport. Und so komme ich zu Deinem Angebot, Thomas: :-) Ich suche jemanden, der Interesse daran hat, einen alternativen MIDI-USB Treiber zu programmieren, welcher Multiclient faehig ist. Das MIDI-USB Protokoll ist eigentlich ziemlich einfach, es arbeitet mit 32bit Worten, die lediglich fuer das MIDI API aufbereitet werden muessen. Sowohl Cypress, als auch Microchip bieten ein Driver Framework fuer Borland C - man muss es eigentlich nur noch richtig konfigurieren, und dann sollte die Kommunikation schon klappen. Das Problem: das MIDI API muss noch bedient werden, es muessen "MIDI Ports" bereitgestellt werden --- mangels Dokumentation weiss ich nicht, wie das zu realisieren ist, doch die Sourcen zu Hubis Loopback Device koennten vielleicht weiterhelfen (die sind allerdings nur in Pascal verfuegbar) Alternativ zu USB wuerde es mich auch interessieren, ob ein aehnlicher MIDI Treiber fuer den Parallelport moeglich ist, und welche Performance hiermit zu erreichen ist. Hintergrund: sollte ich irgendwann einmal die Zeit dazu finden (und meine laufenden Projekte abgeschlossen haben... ;-)) werde ich mich an das geplante FPGA basierte 2x16 MIDI Interface setzen. Doch ohne Multiclient Treiber wuerde es mich waerend des Debuggens von MIDI-Appliklation eher behindern, als nuetzen :-/ Gruss, Thorsten.

Hallo Markus, kommentarleser wissen mehr ;-) ; The morphing function uses addresses within the MIOS address range which are ; reserved for the AIN handler. ; NOTE: morphing is automatically disabled if analog pots/faders are connected #define DEFAULT_MORPH_FUNCTION_ENABLED 1 ; ; Although MIDIbox64E has been designed for rotary encoders, it can also handle with ; up to 64 pots/faders or up to 8 motorfaders. ; Pots and faders are mapped to the "encoder" entries 64-128. ; Example: if group width is 16, and group 1 is selected, encoders are using ; entry 1-16, and pots are using entry 64-70 ; NOTE: morphing is automatically disabled if analog pots/faders are connected #define DEFAULT_NUMBER_AIN 0 [/code] Das heisst: mit DEFAULT_NUMBER_AIN == 0 wird der Morphing Code nicht eingebunden Gruss, Thorsten.

you can change this in seq_enc.inc by mapping the encoder numbers to different values when drum mode is active. But this is the only way, because the order of encoders reflect the order of variables in the pattern memory Ok, this should be an easy change for the next release ;-) Best Regards, Thorsten.

Hi Robin, you are possible right, the transfer of 2000 bytes takes 640 mS, this should be ok. The watchdog resets the core after ca. 2 seconds in this configuration (it's an independent timer which is not clocked by the external crystal) So, I've no idea what could cause such an effect. You've already checked for the second F0 in the software at a place where all transmitted MIDI events are reported (USER_MIDI_NotifyTx) and haven't detected the failure. This means that the PIC software cannot be the reason... Best Regards, Thorsten.

Alright - thats the problem! Do you see the feedback between the USB Audio Device In- and Output? I do! :) So, right-click on this connection and remove it. Thereafter the test application as well as the MIOS upload should work Best Regards, Thorsten.

Hi Ludo, the ALL function is not supported in this mode - maybe I should disable it here. it is not possible due to memory limitations. I was lucky enough to integrate the drum mode like it is after a lot of code size optimization effort on other routines (and I'm happy that they are still working like before). Normaly the drum mode would require different encoder and button handlers which modify the variables within the 256 pattern in another way, but an alternative handling would cost at least 500 bytes, and this would mean that other features, which are planned, could not be integrated anymore. It's not a programming, but a code size problem... (like always - I would switch to a completely different chip if the support effort wouldn't be so high, but this is another topic which has been discussed several times before) What do you mean exactly (can you please describe this in other words?) Best Regards, Thorsten.

Doch, ist ist ein DIN (mindestens ein 74HC165) noetig. Theoretisch koennte man die vier Buttons auch direkt an den PIC anschliessen, doch ich bevorzuge hier das modulare Konzept - vor allem die Moeglichkeit, die MBCV Firmware auch mal schnell auf eine andere MIDIbox aufladen zu koennen, und umgekehrt (mit diesem User Interface kannst Du auch andere Firmwares bedienen, wie bspw. die MIDIbox SEQ V2 --- wenn auch die Bedienung via MIDI Remote nicht wirklich spass macht ;-)) Gruss, Thorsten.

Der Speicher ist voll! Aber es gibt eine einfache Abhilfe - schmeisse die Features raus, die Dich nicht interessieren. Soviel ich weiss, ist kein LCD angeschlossen. Deshalb koenntest Du bspw. die Noten-Strings in midi_evnt.inc rausschmeissen, dadurch haettest Du wieder 512 Bytes Luft - es geht auch noch wesentlich mehr (bspw. das komplette Menuehandling, die Motorfaderkalibrierung/Touchfader/etc...), doch dafuer sind dann jeweils mehrere Handgriffe notwendig... Also: midi_evnt.inc oeffnen, nach "MIDI_EVNT_NOTE_TABLE_ENTRY_LEN" suchen, und alles, was darunter steht (die db Eintraege) loeschen Gruss, Thorsten.

Frieden! Ich versuche Dir nur zu helfen, und dabei ein bisschen aus meiner Erfahrung zu vermitteln. Wenn Dir meine Antworten arrogant erscheinen, dann bitte ich dies zu entschuldigen - es faellt mir nicht einfach, zu erraten, was Dich wirklich interessiert, worauf Du hinaus willst, welcher Input Dir hilfreich ist. Unter diesen Bedingungen ist es nicht einfach, ein gemeinsame Gespraechsbasis zu finden. Um den Gespraechsverlauf zu skizzieren: Du hast urspruenglich nach einem USB Chip gesucht, der einfach zu verloeten ist. Niemand hat geantwortet, Du fragst erneut, und ich denke mir, dass ich vielleicht zumindest erwaehnen koennte, dass die PIC18Fxx5x Derivate gar nicht so schwer zu programmieren sind, und dass man sie aehnlich wie einen Standalone USB Chip betreiben kann --- mit einem schnellen Interface nach draussen, an das Du dann den AVR haengen kannst. Danach wechselst Du das Thema (oder verstehe ich das falsch?) - Du fragst nach der Moeglichkeit, die Baudrate (der UART basierenden MIDI Schnittstelle?) zu erhoehen, um den Durchsatz zu erhoehen. Mein Beitrag dazu: ich halte es (fuer die UART basierte MIDI Schnittstelle) aus den erwaehnten Gruenden nicht fuer sinnvoll, vor allem eben wegen des fehlenden Handshakings. Differenzierter betrachtet kann man natuerlich sagen, dass es in vielen Faellen doch geht, und dass man fuer hoch ausgelastete Prozessoren eine andere Loesung findet muss, doch soweit wuerde ich gar nicht erst gehen - vor allem nicht in der Situation, in der ich nicht weiss, welche Anwendungen Du eigentlich realisieren moechtest (um es mal aggressiv zu formulieren: Du koenntest solche Details ruhig erwaehnen, bevor Du jemanden oeffentlich an die Wand stellst!) Erst nach diesem Posting erwaehnst Du, dass Du eigentlich gar nicht mit USB arbeiten moechtest. Nun moechtest Du fuer Deine eigenen Geraete eine eigene Schnittstelle nehmen, mit der auch Handshaking moeglich ist - haettest Du das gleich erwaehnt, waere ich vielleicht darauf naeher eingegangen - ich kenne Deinen Vorlieben nicht! (Mein Tip: I2C, sehr einfach aufzusetzen, und im Gegensatz zu MIDI UART keine Point-to-Point Verbindungen - somit koennen die Geraete direkt untereinander kommunizieren. Auch sind mit einem synchronen Interface hoehere Datenraten als mit einem UART drin - Stichwort Stoersicherheit). Ok - dies nur, um das Kommunikations-Dilemma aufzuklaeren ;-) Nun die Antworten zu den oberen Fragen: ja, ich muesste entweder Features streichen, oder einen zweiten Baustein fuer die Kommunikation hernehmen. Wie sieht das bei Deinen Anwendungen aus? Sind die stark ausgelastet, oder ist da noch eine Menge Luft? Oder planst Du sowieso eine Multichip-Loesung? Basierend auf Deinem oberen Posting bin ich davon ausgegangen, dass Du ein Fan von USB bist, und Dich auf diesem Gebiet auch schon auskennst (falls nicht: ich kann Dir eine fertige Firmware ueber den Zaun werfen, in die Du nur noch die Kommunikationsroutinen zu Deinen AVRs einbauen musst). USB-MIDI hat immerhin den Vorteil, dass es von allen gaengigen Betriebssystemen unterstuetzt wird - und zwar Plug&Play maessig. Unter Windows koennte der Driver zwar besser sein (er ist bspw. nicht Multiclient-faehig). Die Performance ist verglichen mit dem Programmieraufwand akzeptabel. Alternative zu USB: http://www.mlancentral.com/ - leider kein offener Standard Dann lieber Ethernet? MIDI-over-Ethernet wurde ja bereits IEEE standardisiert, Treiber sind frei erhaeltlich, ein RTL8019AS laesst sich einfach an einen AVR anschliessen Doch lassen wir das Thema. Verstehst Du unter "MIDI+" einen UART mit erhoehter Baudrate? Dann liegen die Gruende auf der Hand: Du kannst Dich nicht an einen fertigen Treiber auf PC Seite dranhaengen - hast Du Erfahrung in PC Treiberprogrammierung (falls ja: dann koenntest Du mir bei einem Programmierproblem weiterhelfen :) Mit bis zu 115200 Baud koenntest Du die "MIDI+" Geraete bspw. an einen normalen COM Port anschliessen - doch der ist leider ein Auslaufmodell, also nicht zukunftssicher. Auch einen fertigen Treiber haettest Du damit nicht zur Hand. Die CBX/"to-Host" Treiber von Yamaha/Roland/Kawai unterstuetzen nur 38400 Baud, und waere kein wirklicher Fortschritt. Ein weiteres Problem: was, wenn mehrere Geraete vom PC aus sternfoermig betrieben werden sollen (z.B fuer mehrere gleichzeitig laufende bidirektionale Verbindungen?). Wieviele COM Ports bietet Dein Motherboard, wieviele Interruptleitungen sind frei fuer weitere Ports? Waerst Du mit 115200 Baud bereits zufrieden? Gruss, Thorsten.

Note: there was an error in my quickly written example - I wanted to write "bcf" at the end, not "bsf" --- and I forgot to mention that BSR has to be set to the right bank again before doing this modification --- I've changed this in the original posting Best Regards, Thorsten.

Hi Sasa, me too! Which MIDI interface are you using? Port number 10 is displayed, this implies that you either have a lot of MIDI interfaces, or a big one with many ports - can you please post a snapshot of the MIDI Devices Window? How did you route the ports? A second snapshot of the "Port Routings" window could also be useful, because it seems that KEY events will never be forwarded to port 10. It seems also that incoming events from port 10 will be forwarded to the output of port 10 (classical MIDI loopback) - this will cause a problem during MIOS upload So - the two additional snapshots should bring some light into this strange behaviour Best Regards, Thorsten.

ok - tabellenloesung: schmeisse das die #if Abfragen wieder raus (dies sind uebrigens Praeprozessor-Anweisungen und keine Assembler Befehle), und ersetze das "movlw ... call MIOS_MIDI_TxBufferPut" Paerchen, das sich aendern soll, wie folgt: TABLE_ADDR MY_SYSEX_VALUE_TABLE movf MIDI_EVNT_VALUE, W TABLE_ADD_W tblrd*+ movf TABLAT, W call MIOS_MIDI_TxBufferPut [/code] Ganz unten im File fuegst Du noch die Tabelle ein - sie muss 128 Werte enthalten: [code] MY_SYSEX_VALUE_TABLE db 0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f db 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d,0x1e,0x1f db 0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f db 0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f db 0x40,0x41,0x42,0x43,0x44,0x45,0x46,0x47,0x48,0x49,0x4a,0x4b,0x4c,0x4d,0x4e,0x4f db 0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5a,0x5b,0x5c,0x5d,0x5e,0x5f db 0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x68,0x69,0x6a,0x6b,0x6c,0x6d,0x6e,0x6f db 0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7a,0x7b,0x7c,0x7d,0x7e,0x7f Die Hexadezimal-Werte koennen auch durch Dezimalzahlen (ohne 0x) ersetzt werden Gruss, Thorsten.

Hi Robin, First of all - this cannot cause such an error. A "goto <function>" behaves exactly like "call <function>" and then a "return". I'm mostly using a "goto" at the end to save one instruction (2 bytes saved which can be used for something else ;-) "MIOS_MIDI_BeginStream" will send a 0xf9, "MIOS_MIDI_EndStream" a 0xfe - but only, when "MIDIbox Link" is enabled. It is not required for your software - and it will do nothing so long the Merger Mode is either "enabled" or "disabled" (ignore these functions) it's ok you've commented out the "clrwdt" instruction - this is dangerous and especially this could cause the problem! If the watchdog is not serviced within a certain time, the core will be reset, and a MIOS upload request will be sent - did you notifce something like this? This could also explain why pin 27 never toggles on two following F0 bytes (the PIC is reset after the first F0) Best Regards, Thorsten.

Hallo Markus, du kannst die verschiedenen Werte mit der gleichen Routine senden - hier gibt es zwei Ansaetze, aber um zu verstehen, welcher fuer Dich am besten geeignet ist, muesste ich wissen, ob sich die Werte mit einer simplen Formel berechnen lassen, oder ob sie so verschieden sind, dass man sie lieber in eine Tabelle ablegen sollte Gruss, Thorsten.

thats exactly the problem which has been fixed in v2.2a as mentioned in another thread, I will add this to the ToDo list :) Best Regards, Thorsten.

yes, this would be possible - I will add this to the ToDo List Best Regards, Thorsten.

Hi Moxi, the bsf enables the menu mode, the bcf disables it again. The intention is to do this when one button of the alternative menu button row is pressed --- you can handle this like if you would press the menu button, press a common GP button, and depress the menu button again (it's some kind of "Macro" operation) Best Regards, Thorsten.

Ich habe nicht behauptet, dass es schwierig waere, eine schnellere Version zu entwickeln. Ich habe nur versucht, Dir zu verdeutlichen, warum es zu schwierigkeiten fuehrt, wenn man einfach nur die Baudrate erhoeht, und weiter keinen Aufwand treibt. Ok, beschraenke dich auf primitive Applikationen, oder nimm einen schnelleren Mikrocontroller mit viel RAM, und es ist wirklich kein Problem - vielleicht war Deine Frage an the Godfather of MIDI etwas zu undifferenziert ;-) Gruss, Thorsten.

Hallo, schaue Dir mal das Meta Events an (-> mb64_meta.inc bzw. mb64e_meta.inc) Gruss, Thorsten.

Finally a MIDIbox SEQ with 4 LED rows! :) Moxi wrote

This is a MIDIbox SID made by SJakie - he wrote: