TK.

2.7 nF The schematics are always the reference! Best Regards, Thorsten.

Hi Moxi, there is not only one place which needs to be changed, multiple files are affected, and I cannot tell you which places exactly have to be modified. Maybe a simple solution would be to "emulate" control button toggles, e.g., if you want to use the encoder buttons to change the menu, then you could do this in the following way (pseudo code!) SET_BSR SEQ_BASE bsf SEQ_MODE0, SEQ_MODE0_MENU, BANKED ...call the SEQ_BUTTON_GP button handler with the right button number... SET_BSR SEQ_BASE bcf SEQ_MODE0, SEQ_MODE0_MENU, BANKED [/code] or to edit the mutes: [code] SET_BSR SEQ_BASE movff SEQ_SELECTED_LAYERS, MY_SAVED_LAYERS ;; new variable which has to be declared in app_defines.h movlw 0x01 ;; edit layer 1 movwf SEQ_SELECTED_LAYERS, BANKED ...call the SEQ_BUTTON_GP button handler with the right button number... movff MY_SAVED_LAYERS, SEQ_SELECTED_LAYERS But you will have a big problem, because the 4 LED rows don't reflect the layer state - and a change is not so easy, since drum mutes/accents are not saved like common mutes. See SEQ_GP_Mode0_LED how these flags are saved. In order to make the interrupt handler for the 4 LED rows as fast as possible (really wanted!), the LED state should be prepared from the main task (in USER_Tick) when nothing else is to do It requires some programming knowledge Best Regards, Thorsten.

There is an update available in the MIOS download section which includes a bugfix for the drum mode (-> midibox_seq_v2_2a) Best Regards, Thorsten.

Hallo, lege die Buttons einfach auf ungenutzte Eingaenge. Im Zweifelsfall: 128, 129, 130, 131 Gruss, Thorsten.

Freut mich, dass nun alles funktioniert! :) Gruss, Thorsten.

Hier die vorlaeufig letzten Diagramme zum Thema Motorfader - zumindest die RSAON11M9 und Panasonic Fader lassen sich mit dem neuen Algorithmus besser ansteuern. Ich habe nun doch wieder eine PWM zur zusaetzlichen Geschwindigkeitsregulierung eingebaut, jedoch diesmal eine niederfrequente und besser konfigurierbare (Pulsweite und Duty Cycle lassen sich einstellen). Der RSAON11M9 summt vor sich hin, im Vergleich zur vorigen PWM ist das Geraeusch jedoch leiser und angenehmer. Der Panasonic Fader zeigt sich von der PWM unbeeindruckt - der Ueberschwinger laesst sich nicht vermeiden, dafuer ist er im Gegensatz zu vorher nun etwas schneller am Ziel. Bei den restlichen Alps Fadern ist diese PWM nicht zu empfehlen, sie werden dadurch noch lauter. Zeit fuer ein Fazit: die letzten Optimierungsarbeiten haben zu einer besserne Ansteuerung der RSAON11M9 und Panasonic Fader gefuehrt, fuer RSAOK11VP und RSAOK11W ist die MIOS MF Hard- und Software jedoch nicht wirklich geeignet - man muss eher mit Nachteilen rechnen (Laute Fader, ungenaue Ansteuerung), somit laesst sich der hoehere Preis nicht rechtfertigen. Abhilfe koennte zumindest eine bessere, und vor allem uC regulierbare Spannungsversorgung fuer jeden einzelnen Fader schaffen. Ein eigener Mikrocontroller pro Fader sollte die Ergebnisse ebenfalls verbessern. Diese uC koennten bspw. per IIC an den MIOS Core angeschlossen werden, so dass auf der Applikationsseite relativ wenig geaendert werden muss. Anstatt auf ein Fader Event (USER_AIN_NotifyChange) zu warten, muesste der Core regelmaessig (bspw. in USER_Tick) die Slaves nach neuen Daten fragen, und Aenderungen dann nach USER_AIN_NotifyChange weiterleitern - das ist ein Fuenfzeiler Erhaelt der Master eine neue Faderposition vom Host, leitet er diese dann an den Slave weiter - auch das ist auf MIOS Seite sehr einfach machbar (-> MIOS_IIC_*) Wirklich aufwaendig ist die Implementierung des Slaves - und dies ist eine Sache, aus der ich mich heraushalten werde! ;-) Gruss, Thorsten.

Update: evtl. habe ich eine Loesung fuer das Spannungsproblem gefunden. Wir erinnern uns: der Panasonic Fader ist bei einer Spannung >6V so schnell, dass er gegen den Anschlag knallt (siehe violette Kurve): wenn man nun die Geschwindigkeit reguliert, indem man den Motor kurzzeitig abschaltet, wenn er zu schnell geworden ist, und wieder einschaltet, sobald er langsamer geworden ist, bekommt man die Ueberschwinger wohl in Griff. Hier ein Extrembeispiel, bei dem ich die Spannung auf 8V (!) eingestellt habe - bei einer Geschwindigkeit > 5/1024 pro 1.6 mS wird der Motor ausgeschaltet: Wie sich das bei meinen Alps Fadern verhaelt, teste ich morgen :) Gruss, Thorsten.

Um ein Gefuehl dafuer zu bekommen, wie sich der neue Algorithmus mit den verschiedenen Fadern verhaelt, habe ich eine DatenLog-Funktion in den MF Handler eingebaut, welche die Positionen waehrend einer Faderfahrt aufnimmt. Hier die Ergebnisse: Der ALPS RSAOK11VP verhaelt sich bei einer Spannung von 5.8V nahezu ideal, "kratzt" jedoch ein wenig. Den Endwert erreicht er meistens nach ca. 300-400 mS Der ALPS RSAOK11W (coreless) ist extrem laut, dafuer jedoch etwas schneller. Bei 7.5V funktioniert er gerade noch so, ist hier am leisesten, dafuer jedoch sehr langsam (deshalb sieht man auch den seltsamen Knick bei 7.5V - hier hat der Log-Speicher nicht ausgereicht). Wenn man die Lautstaerke akzeptieren kann (bspw. bei Abruf eines Snapshots), sind < 300 mS durchaus drin! Der ALPS RSAON11M9 ist der Fader-Typ, den ich bei meiner MIDIbox LC verwende. Er erreicht den Endwert meistens nach ca. 400 mS. Hier nicht zu sehen: manchmal ist er extrem am pendeln - das war damals der Grund, warum ich ueberhaupt die PWM Steuerung eingebaut habe. Evtl. laesst sich das nun durch eine andere Deadband Einstellung ausgleichen (siehe unten) Und hier noch ein Panasonic Fader. Besonderheiten: er pendelt extrem, ist jedoch auch sehr leise! Bei hoeheren Spannungen schlaegt er soweit aus, dass er gegen den Anschlag knallt - bei niedrigeren Spannungen (5V) ist er eigentlich erstaunlich gut Hier der Erklaerungsversuch, was ich unter "Dynamic Deadband" verstehe: Anstatt die Spannung per PWM langsam runterzufahren (was zu einem unangenehmen Geraeusch fuehrt), wird der Fader zunaechst kurzzeitig ausgeschaltet, sobald er den Zielwert +/- 32 erreicht. Ein Counter beginnt zu laufen, nach ca. 25 mS wird das Deadband auf 8 heruntergesetzt, nach 13 mS auf 4, nach 10 mS schliesslich auf 1 Befindet sich der Motor ausserhalb des Deadbands, wird er fuer diese Zeit wieder eingeschaltet. Durch seine Traegheit bewegt er sich jedoch langsamer. Alle Fader haben typischerweise einen Fehler von +/- 0..3 (wenn die Zielposition im mittleren Bereich von 20%..80% liegt, ist der Fehler meistens +/- 0..1) Weitere Dinge, die mir aufgefallen sind: fuer optimale Ergebnisse wuerden alle 8 ALPS Fader meiner MIDIbox LC eigentlich eine seperate Spannung benoetigen, die sich einzeln einstellen laesst eigentlich benoetigt man auch eine unterschiedliche Spannung fuer Auf/Abwaertsbewegung wenn ich vor der Entscheidung stuende, neue Fader zu kaufen, wuerde ich wahrscheinlich die Panasonics nehmen ;-) Gruss, Thorsten.

Ich glaube, das Gedankenspiel mit den verschiedenen Modi hat sich gerade eruebrigt - ich habe einen Weg gefunden, die Fader ohne PWM relativ schnell und exakt zu steuern (der Fehler liegt meistens bei +/- 0..3/1024) - Stichwort "dynamisches Deadband" - doch ich glaube, das muss ich nun erstmal ueberschlafen und morgen mit verschiedenen Fadern ausprobieren. Mit dem Coreless-Motor ist der Fehler wesentlich kleiner als mit gewoehnlichen Fadern, doch ich habe noch nicht alle "Schraeubchen" herausgefunden. Skunk, bin besonders an den alternativen Treiber-Schaltungen interessiert - meine Fader (gleichen Typs) bewegen sich bspw. mit verschiedenen Geschwindigkeiten, eigentlich muesste man fuer jeden Fader die Spannung einzeln kalibrieren Gruss, Thorsten.

Hallo, danke fuer die Infos! Ich habe zum Thema Motorfader aufgrund neuer Erkenntnisse mal einen neues Topic eroeffnet: http://69.56.171.55/~midibox/forum/index.php?topic=4244.0 Gruss, Thorsten.

ich habe heute mal wieder ein wenig mit den ALPS Motorfadern herumgespielt, dabei ist mir aufgefallen, dass sich beide Fader (RSAOK11VP und RSAOK11W) zufriedenstellend ansteuern lassen, wenn man die Spannung soweit herunterschraubt, dass sie sich relativ langsam, dafuer jedoch extrem leise bewegen. Ein paar Abhaengigkeiten sind mir dabei wieder bewusst geworden, die ich vorher nicht fuer wichtig gehalten habe. Beispielsweise die Periodendauer der PWM - sie betraegt momentan 32 * 100 uS = 3.2 mS, so dass MIOS 32 verschiedene Geschwindigkeitsstufen einstellen kann, wobei jedoch meistens nur die oberen 16 Stufen verwendet werden (bei <16 bewegt sich der Fader aufgrund der Traegheit nicht) Diese PWM erlaubt zwar, den Fader je nach Pulsbreitenverhaeltnis sehr langsam (und somit exakt) oder sehr schnell zu bewegen, dafuer wird der Fader jedoch sehr laut. Also habe ich die Periodendauer mal auf 4 * 100 uS eingestellt - der Fader erzeugt nun einen hoeherfrequenten Ton, der jedoch leiser wird, wenn man die Spannung herunterschraubt. Wenn der Fader ausreichend langsam bewegt wurde, bleibt er auch sofort stehen und faengt nicht an, um die Zielposition herum zu pendeln, bis er sie wirklich erreicht hat - mit nierdiger Spannung und einem PWM Verhaeltnis von 1:3 ist das moeglich Weitere Beobachtung: 8 Fader koennen nur innerhalb von 1.2 mS komplett erfasst werden. Wenn ein Fader innerhalb dieser Zeit an seiner Zielposition vorbeifaehrt, faengt er an zu pendeln und wird dadurch wieder sehr laut. Diese Zusammenhaenge haben mich auf folgende Idee gebracht (eure Meinung ist gefragt): eigentlich gibt es zwei verschiedene Ansteuerungsstrategien fuer Motorfader - in einer laufenden Automation mit vielen Faderfahrten moechte man eigentlich sehr leise Motorfader haben - und es ist vielleicht auch nicht so wichtig, ob ein Fader auf 1/1024 Bit genau die Position anfaehrt, wenn er eine halbe Sekunde spaeter sowieso weiterbewegt wird. Dann gibt es die Situation, in der man einen "Snapshot" abrufen moechte, bei dem die Fader moeglichst exakt die gespeicherte Position anfahren. Wenn es hierbei mal kurz laut wird, waere es nicht weiter schlimm. Und: es waere ebenfalls nicht tragisch, wenn die Fader erstmal gleichzeitig die ungefaehre Position anfahren, und dann - fuer einen kurzen Moment - nacheinander exakt justiert werden. Dieser Vorgang wuerde vielleicht 2-3 Sekunden dauern. Und diese beiden Strategien koennte man miteinander kombinieren: die Motorfader werden grundsaetzlich grob (Fehler ca. 2-3 Bit), dafuer jedoch sehr leise bewegt, und wenn sie laengere Zeit (also bspw. 5 Sekunden) nicht mehr bewegt wurden, nacheinander exakt einjustiert. Was haltet ihr davon - ist dieses Verhalten akzeptabel? (immerhin wuerde es bedeuten, dass sich dadurch RSAOK11VP und RSAOK11W einsetzen lassen), oder dann doch lieber ein voellig anderes Ansteuerungskonzept (welches von mir nicht supported werden kann ;-)) Weitere Frage: wie schaut es bei professionellen Konsolen aus - wie schnell erreichen die Fader die Zielposition? Sind sie schneller als ca. 0.5...1 Sekunde? Gruss, Thorsten.

Es hat noch niemand die Zeit gefunden, genauere Infos zur MBCV aufzuschreiben - meldest Du Dich freiwillig? :) (eigentlich bekommt man sie nur mit einem Display heraus, oder man schaut in den Source Code, bspw. cv_presets.inc) Per Default reagieren die 8 CVs auf Noten - MIDI Kanal 1-8 Die V+/V- Eingaenge sind essentiell! Hier wird die Versorgungsspannung fuer die OP Verstaerker angeschlossen Siehe auch http://www.ucapps.de/mbhp/mbhp_aout.pdf Du koenntest das Modul auch erstmal ohne OP Verstaerker testen - miss einfach die Spannung an den Jumpern zwischen MAX525 und TL074, sie sollte sich je nach gespielter Note zwischen 0V und 2.048V bewegen. Hinter dem OP Verstaerker dann zwischen 0V und 11.37V Hier auch noch ein Tip zur Kalibrierung (Sourcecode-Leser wissen mehr): ; Calibration: play the note C-8 at channel 1, and adjust the trimmpot ; until the first AOUT pin is 10V ; Then try other notes: ; c-0: 0V ; c-1: 1V ; C-0: 2V ; C-1: 3V ; C-2: 4V ; C-3: 5V ; C-4: 6V ; C-5: 7V ; C-6: 8V ; C-7: 9V ; C-8: 10V ; ; Do the same for the other CV Outs by playing Notes on Channel 2-8 [/code] Gruss, Thorsten.

1) beim ersten Core "mblink_fp" (MIDIbox Link Forwarding Point) aktivieren, beim letzten Core "mblink_ep" (MIDIbox Link Endpoint) 2) das hast Du bereits getan. D0 sendet bspw. auf Kanal 1, D1 auf Kanal 2, D2 auf Kanal 3, etc... 3) nimm die MB64 Applikation und schau mal in die midibox64.ini Datei, dort stehts beschrieben Gruss, Thorsten.

Hallo Markus, ich sehe gerade, dass die MIDIO128 nicht automatisch die Device ID von MIOS uebernimmt, sondern stattdessen seine eigene ID hat, die in app_defines.inc festgelegt wird (macht eigentlich nur wenig Sinn, sollte ich vielleicht mal aendern) Gruss, Thorsten.

Als generelle Loesung halte ich das nicht fuer sinnvoll, da von der Baudrate noch viele andere Dinge abhaengen, die Du vielleicht auf Anhieb nicht siehst. Zwei Punkte: je hoeher die Baudrate, desto groesser sollte der MIDI Buffer sein. In MIOS ist der Eingangsbuffer bspw. 64 Bytes gross, damit lassen sich bei normaler Baudrate 20 ms ueberbruecken, in denen die Daten nicht abgearbeitet werden. RAM ist sehr wertvoll (zumindest bei PICs) - in anderen Worten: je groesser der Eingangsbuffer, desto weniger bleibt fuer die eigentliche Anwendung uebrig, desto weniger Features kann man implementieren. Naechster Punkt: Receiver Buffer Overruns - falls der USART keinen internen FIFO bietet, muss eine ISR das eingehende Datum sehr schnell in den Eingangsbuffer bringen, ansonsten kommt es zu einem Ueberlauf. Bei MIDI Baudrate und doppelgebuffertem USART innerhalb von < 640 uS - diese Zeit ist bei einem simplen MIDI Controller sehr einfach einzuhalten, bei einem Synthesizer (ich spreche hier bspw. von der MIDIbox SID und FM), bei dem eine Menge Echtzeit-Berechnungen anfallen, die nicht blockiert werden duerfen, wuerde eine hoehere Baudrate sehr weh tun. Deshalb macht ein normales MIDI Interface fuer hoehere Transfergeschwindigkeiten nur wenig Sinn - doch es gibt auch alternative Interfaces, und dies waere bspw. USB. Im Gegensatz zu MIDI bietet USB ein Handshaking - der USB Host wartet auf den Slave, wenn dieser die Daten gerade nicht entgegennehmen kann. Somit ist die Gefahr fuer Buffer-Ueberlaeufe gebannt. Da das USB-MIDI Protokoll standardisiert ist, waere es eigentlich erste Wahl fuer zukuenftige MIDI Interfaces, wenn da nicht die Macken im Windows Driver waeren, sowie die generellen Probleme mit USB (Latenz, Jitter)... nunja... Noch einen Hinweis: zur Datenuebertragung zwischen PIC und AVR wuerde ich I2C empfehlen, da auch hier so eine Art Handshaking stattfindet (Clock Stretching). Alternativ koenntest Du Dir auch ein parallel-Interface programmieren - uebertragungsraten > 1MByte/s sollten damit kein Problem sein Gruss, Thorsten.

Hallo Markus, bei der MIDIO128 ist die Device ID im Kommando versteckt. 14 bedeutet: Kommando 4 (Schreiben), Device ID 1 Doch warum aenderst Du die Device ID? Betraegt die MIOS Device ID ebenfalls 1? Wahrscheinlich nicht - deshalb probiere folgende Zeile: "perl mk_midio128_syx.pl midio128.ini" Gruss, Thorsten.

MIDIbox SEQ V2.2 is now available. From the ChangeLog: a drum mode has been implemented which allows to play three drum lines per track (makes up to 48 drum lines which can be played in parallel) In this mode, each layer contains one drum line. Limitations: each line has a dedicated note and gatelength. Only two velocity values can be specified (normal and accent) The accents can be set when the FAST button is activated. More details are described in Tutorial #3: http://www.ucapps.de/midibox_seq_tutorial3.html single events can now be triggered multiple times (up to 4 times per step) with a delay value of 1-31. The number of triggers and the delay can be selected in the gatelength layer. This feature allows to play doubled, triplet and quadrupled notes, which is especially useful for drumrolls, ratterbeats and flams. More details are described in Tutorial #3: http://www.ucapps.de/midibox_seq_tutorial3.html Note: the new definition of the gatelength makes old patterns incompatible to previous releases (better to do it now than never) - the gatelength has to be divided by 4 in old patterns a humanizer function has been added which allows to add/subtract random values from the 2nd MIDI byte (e.g. Note), from the 3rd MIDI byte (e.g. Velocity, CC value, Aftertouch...) and from the gatelength. The humanizer mode and intensity can be selected in the Groove menu two additional gate trigger pins are now available for the AOUT option. The 3rd gate is located at pin RC0 (CORE::J6::RC) The 4th gate is located at pin RC1 (CORE::J6::SC) These pins are only used when no AIN multiplexers are connected (which is normaly the case when no pots are used) Download: http://www.ucapps.de/mios_download.html Have fun! :) Best Regards, Thorsten. P.S.: try the humanizer function on note values in arpeggiator mode - it rocks!

Hallo Markus, das unterscheidet sich je nach Applikation - bei diesem Testprogramm werden die MIDI Events in mios_tables.inc eingetragen (siehe die dortigen Kommentare). Allerdings ist es hier nicht moeglich, den Wert1 vorzugeben (man muesste das in main.asm selbst programmieren). Nimm lieber die MIDIO128, die Konfiguration kann ueber das mk_midio128_syx Script vorgenommen werden Beispiele (siehe auch Kommentare in midio128.ini) [MIDI_OUT] ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = D0 01 00 D0 00 00 @OnOff 2 = D0 02 00 D0 00 00 @OnOff 3 = 90 19 7F 90 19 00 @OnOff [/code] Gruss, Thorsten.

Hallo, nein, das ist nicht notwendig, solange die ungenutzten analogen eingaenge (an J5 und am AIN Modul) auf Masse liegen jep! Wahrscheinlich musst Du in Deinem Fall lediglich das midibox64_generic.syx File aus dem mk_syx.zip Packet aufladen Gruss, Thorsten.

Hallo Basti, ich wuerde einen der neuen PIC18Fxx5x nehmen, den USB Bootloader draufbrennen (lassen), und dann das USB Framework von Microchip so modifizieren, dass die USB datenstreams bspw. ueber die I2C oder SPI Schnittstelle zum AVT weitergeleitet werden. Das ganze erfordert zwar etwas Einarbeitung, kostet jedoch weniger Aufwand, als einen eigenen USB Stack fuer den AVR zu programmieren. Microchip bietet saemtliche Sourcen umsonst an, ausserdem kann man den C18 Compiler fuer 60 Tage testen - das sollte ausreichen, um die "USB-Bridge" auf die Beine zu bringen. Kostenpunkt: ca. 10 EUR (den PIC18F4550 gibt es bspw. bei voti.nl) Literaturempfehlung: http://www.microchip.com, nach "PICDEM USB User Guide" suchen Gruss, Thorsten.

Hallo, am besten die Module schrittweise aufbauen und testen - also erstmal das Core Modul zusammenbasteln, den Bootloader in den PIC brennen (falls das nicht jemand anderes fuer Dich gemacht hat), MIOS aufladen Danach das LCD testen (eine Meldung sollte erscheinen, sobald MIOS aufgeladen ist) Das DIN Modul bauen und bspw. mit der MIDIO128 Applikation testen Das AOUT Modul bauen und mit der MIDIbox CV Applikation testen die restlichen Gate Outs sind an J5 verfuegbar, jedoch per default nicht aktiviert, um zu vermeiden, dass bspw. ein MIDIbox64 User unabsichtlich seinen PIC zuschiesst, falls er mal die MBCV Applikation auflaedt (die Potis wuerden gegen die Ausgaenge an J5 treiben). Deshalb muss diese Option im "main.asm" File extra aktiviert werden (ENABLE_J5 auf 1 setzen) - die Applikation kann nach dieser Anleitung neu assembliert werden: http://www.ucapps.de/howto_tools_mpasm.html Gruss, Thorsten.

Hi Robin, MIOS takes care about the BankStick accesses, normaly the behaviour is identical, you only have to take care for the 16th address bit (when using the MIOS_BANKSTICK_* functions: MIOS_PARAMETER2, 7) On a 32k device this bit won't be taken into account, you will read the same content regardless if this bit is 0 or 1 On a 64k device this bit switches between the lower and upper half of the memory Best Regards, Thorsten.

Hi, it sounds like some data or address lines of the SID are not connected, or if two of them are shortened (connected together) Best Regards, Thorsten.

Thank you! I've added this info to the MBHP_OPL3 page Best Regards, Thorsten.

The PC900 is hard to get here in germany (not sure if this is a discontinued product), therefore I decided to use the 6N138 6N139 works also, I cannot give a statement for other optocouplers Best Regards, Thorsten.