TK.

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:

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.