[Nils H.]

Moin,

zum Thema EEPROM/Presets sichern: Ich hab mich ein wenig in die Themen SysEx und Bulk Dump/Load eingelesen, ich denke, ich werde das so machen. Die Routinen hierfür dürften überschaubar sein, Softwareseitig geht das ganz gut z.B. mit MIDI-OX. Allerdings müsste ich fürs zurück sichern doch noch einen MIDI-Input einbauen. Kein großes Problem, auf dem µC-Board ist die Beschaltung bereits vorgesehen. Müsste nur noch mal 'n Lock für die Buchse bohren.

Von fertig bin ich allerdings doch noch ein Stück weg, ich hab doch noch einiges an Baustellen gefunden. Wenn die Presetbearbeitung und -speicherung fertig ist, ist der Controller aber auf jeden Fall schon mal produktiv nutzbar.


Ansonsten hab ich beim erneuten Überfliegen des Marktes noch ein paar Inspirationen gefunden und ein paar andere Ideen entwickelt.

Eine davon ist: Es gibt eigentlich kein Midiboard, welches eine MIDI Beat Clock senden kann; warum eigentlich nicht? Protokollseitig ist das, wenn ich das richtig verstanden habe, relativ simpel: 24 mal pro Beat das Statusbyte F8 senden, fertig. Der Empfänger (in meinem Fall mein Delay) leitet dann aus dem zeitlichen Abstand der ankommenden Statusbytes das Songtempo ab.

Ich spiele 90% aller Songs in meiner Band mit dem gleichen Preset in meinem TC G-Sharp, nämlich ein Hall und ein Delay. Das einzige was sich von Song zu Song unterscheidet ist das Delay Tempo (falls das Delay denn benutzt wird). Normalerweise passe ich das Delay per Tap Tempo an, kein Problem. Aber lustig wäre es doch, wenn ich in den Presets eine BPM Angabe hinterlegen könnte. Der Controller sendet dann die passende MIDI Clock, und das Delaytempo (oder andere Parameter) wird automatisch angepasst.

Ein netter Nebeneffekt wäre, dass ich das auch gleich auf eine LED umlegen könnte und dann so eine Art Metronom im Board hätte. Wäre ganz praktisch z.B. zum einzählen.

Ich frage mich, warum das nie so umgesetzt wird. Wenn man mit einem µC ohne großen Aufwand eine Uhr bauen kann, wird's für eine MIDI Clock und eine Tempo LED doch wohl reichen. Das ganze könnte dann mit einem "Song Mode" kombiniert werden, wie ihn einige Controller bieten, was ja wohl nicht vielmehr als eine Preset-Map ist. Hier könnte ich dann auch die BPM hinterlegen.

Eine weitere Idee ist, vor dem Hintergrund, den Looper relativ dumm halten zu wollen und auf Display und Taster verzichten zu wollen, die Möglichkeit der Remote-Konfiguration des Loopers. Also vom Controller aus per SysEx z.B. den MIDI-Kanal des Loopers einstellen oder sowas.

Also, Ideen gibt's vermutlich noch genug. Am Wochenende werde ich wohl mal die Platinen für den Looper zusammenlöten.

Gruß, Nils

[kugelblitz]

Hi Nils,

Ein netter Nebeneffekt wäre, dass ich das auch gleich auf eine LED umlegen könnte und dann so eine Art Metronom im Board hätte. Wäre ganz praktisch z.B. zum einzählen.

Die midiclock Idee gefällt mir. Eigentlich schlimm auf wie viele Ideen man kommt wenn man sich so etwas selbst macht.

BTW  vielleicht hast Du es schon geschrieben, aber wie hinterlegst Du den Status der Effekte im Board (Annahme: Gmaj oder Gmaj als Gegenstück). Ich speichere sie ATM nicht und damit kann es sein daß das erstemal schalten nach Presetwechsel 127 statt 0 sendet und erst beim zweiten mal findet der Wechsel statt? Speicherst Du alles in Deinen Presets im fußcontroller oder hast Du eine Möglichkeit gefunden den Status beim Gmaj(2) zu erfragen?

Gruß,
Sepp

Gruß,
Sepp

[Nils H.]

BTW  vielleicht hast Du es schon geschrieben, aber wie hinterlegst Du den Status der Effekte im Board (Annahme: Gmaj oder Gmaj als Gegenstück). Ich speichere sie ATM nicht und damit kann es sein daß das erstemal schalten nach Presetwechsel 127 statt 0 sendet und erst beim zweiten mal findet der Wechsel statt? Speicherst Du alles in Deinen Presets im fußcontroller oder hast Du eine Möglichkeit gefunden den Status beim Gmaj(2) zu erfragen?

Der Controller ist der Master für alle Presets. Im Presetsatz finden sich die Program Changes für alle Geräte (1 Byte pro Gerät = 8 Byte, MSB als "deaktiviert"-Flag). Außerdem wird der Status der 32 CC-Taster in 4 Byte abgespeichert, für jeden ein Bit. Die CC-Taster sind global konfiguriert, wenn sie als "Senden mit Preset" markiert sind, werden sie beim Presetwechsel mitgesendet.

Das Erstellen von Presets mit z.B. einem G-Major, liefe dann so:

1. Im Controller Program Change festlegen
2. Im Effektgerät Preset aufrufen
3. per CC-Taster die gewünschten Effektblöcke ein- und ausschalten
4. Preset im Controller speichern.


Rufe ich jetzt ein Preset ab, passiert folgendes:

1. Der Controller überprüft den PC-Befehl. Wenn er gleich dem letzten gesendeten Befehl ist, ignoriert er ihn. Ansonsten sendet er den PC ans Effektgerät, das Effektgerät reagiert auf den PC und lädt das Preset.

2. Der Controller sendet alle als "Senden mit Preset" konfigurierten CCs raus. Wenn im G-Major-Preset Chorus, Delay und Hall aktiv sind und die entsprechenden CCs im Controllerpreset als 1 gespeichert sind, passiert nichts. Ist z.B. das Delay im Controller als 0 gespeichert, wird es über den CC-Befehl im G-Major ausgeschaltet.

Statt also zwei Presets im Effektgerät vorzuhalten, die bis auf das Delay identisch sind, brauche ich nur eines, und die Umschaltpause zwischen den Presets fällt weg. Auf diese Weise brauche ich den Status des G-Major nicht zu kennen, weil der Controller den empfangenden Geräten immer seinen Stand "aufzwingt".

Ich hab kein G-Major, aber ein G-Sharp. Ich liebe es, aber es hat Preset-Umschaltzeiten jenseits von gut und böse. Noch dazu speichert es den Status der beiden Effektblöcke nicht mit ab; wenn ich per CC die FX-Engine ausschalte und das Preset speichere, ist das Delay nach dem Laden des Presets wieder aktiv  . Noch ein Grund, um den Controller alles steuern zu lassen.

Das war jetzt lang. War's auch verständlich  ?

[kugelblitz]

Danke für die Ausführlichkeit, also Du speicherst mit und ja das war mehr als verständlich. Eigentlich hätte ich ja nur mit denken müssen, Du empfängst ja nichts *grml*

Gruß,
Sepp

[Nils H.]

Danke für die Ausführlichkeit, also Du speicherst mit und ja das war mehr als verständlich. Eigentlich hätte ich ja nur mit denken müssen, Du empfängst ja nichts *grml*

Kein Problem. Ist meiner Meinung nach die einzige sinnige Lösung. Außerdem Stand der Technik  .

[kugelblitz]

Kein Problem. Ist meiner Meinung nach die einzige sinnige Lösung. Außerdem Stand der Technik  .

Schade ein undokumentiertes Feature im Protokol wäre ja cool gewesen

[Nils H.]

Moin,

gestern Abend hab ich so eine Art Meilenstein erreicht - der Controller ist jetzt mit seinen Grundfunktionen produktiv nutzbar. Heißt: Ich kann jetzt endlich auch Presets bearbeiten.

Nächstes wichtiges Feature ist das kopieren und verschieben/tauschen von Presets, im Moment kann ein Preset nur "in place" bearbeitet werden.

Ich musste im Verlauf feststellen, dass meine keine-Ahnung-einfach-losprogrammieren-Strategie schon seine ersten Opfer fordert: Als erstes drohte mir, der SRAM auszugehen  . Stellte sich raus: Alle statischen Strings im Arbeitsspeicher abzulegen ist doof  . Diese sowie den Zeichensatz fürs LCD habe ich jetzt ins PROGMEM verlagert, das hat den SRAM-Bedarf wieder auf die Hälfte reduziert. Eienr der kleineren ATMEGA hätte es trotzdem nicht sein dürfen, der Flash-Bedarf liegt derzeit bei 15k.

Darüber hinaus habe ich noch ein paar unerklärliche Abstürze in den Menüs, wenn man verschiedene Tasten zu schnell drückt. Ich vermute, dass der I²C-Bus dann hängt, weil sich Tastendrücke, LCD-Ausgaben und EEPROM lesen in die Quere kommen - vermutlich muss ich in den Menüs einiges noch atomisieren. Zusätzlich werde ich wohl den Watchdog aktivieren, damit er in so einem Fall den Controller automatisch neu startet. Die Abstürze muss ich natürlich trotzdem finden.

Bevor ich weitere Features in den Controller programmiere, kümmere ich mich jetzt erst mal um die Schaltung und die Software für den Looper. Das sollte allerdings deutlich unaufwendiger werden.

Parallel zeichne ich noch vernünftige Pläne, die ich dann zusammen mit den Layouts und der Software beizeiten veröffentliche.

Gruß, Nils

[carlitz]

Nils, halte durch .....

[Nils H.]

Nils, halte durch .....

  . Kein Problem (mehr)... nach mehreren Jahren und diversen Neuanläufen ist die Zielflagge in Sicht. Der Controller ist ja so gut wie durch, was jetzt noch kommt, sind Komfortfunktionen und "nice to have"-Kram.

Die Mikrocontrollerfizierung meines Rackloopers halte ich nur noch für Kinderkram... 

Das ist wie der Bau meines ersten eigenen Amps.... voll geil, wenn man sich zusammen stricken kann, was man braucht und haben will, und das funktioniert dann auch noch... .

[kugelblitz]

Hallo Nils,

Das ist wie der Bau meines ersten eigenen Amps.... voll geil, wenn man sich zusammen stricken kann, was man braucht und haben will, und das funktioniert dann auch noch... .

schön zu hören, daß Du zu einem erfolgreichen Ende kommst und das ganz auch noch dokumentieren willst. Hätte ich bei meine Ausgeburten nur dokumentiert, bei meinen hab ich wirklich keine Ahnung mehr was ich verbaut hab lediglich die Ideen dahinter ist aber OT

Hier noch ein paar Ideen zu Deinen Bugs, vielleicht hilft ja etwas:
Vielleicht könnte man konsequentes Queueing einführen und nicht auf jede Eingabe sofort reagieren. Je nach Modus dürften hier aber verschiede Regeln zur Bewertung der Queues nötig sein. (Pedal mode: sofort reagieren, Batch mode: Bank (optional) + sinnvolle Kanalangabe...)...

Viel Erfolg,
Sepp

[SvR]

Salü,

Ich vermute, dass der I²C-Bus dann hängt, weil sich Tastendrücke, LCD-Ausgaben und EEPROM lesen in die Quere kommen - vermutlich muss ich in den Menüs einiges noch atomisieren.

Läuft das über Interrupts? Sperrst du alle anderen Interrupts, wenn du ein Ereignis bearbeitest? Evtl. gibt es auch die Möglichkeit Prioritäten für die Interrupts zu vergeben? Kenn mich da bei AVRs nicht so aus.
mfg Sven

[Nils H.]

Salü,Läuft das über Interrupts? Sperrst du alle anderen Interrupts, wenn du ein Ereignis bearbeitest? Evtl. gibt es auch die Möglichkeit Prioritäten für die Interrupts zu vergeben? Kenn mich da bei AVRs nicht so aus.
mfg Sven

Die I²C-Kommunikation läuft insofern nicht mit Interrupts, als dass die INT-Leitung des Busses nicht ausgewertet wird. Die Taster am Bus werden über eine Timer-ISR aber regelmäßig (alle 8 ms) abgefragt. Außerdem läuft noch eine ISR für den 16-Bit-Timer.

Grunsätzlich sollte es so sein, dass ich vor jedem Buszugriff die Interrupts sperre und hinterher wieder freigebe. Ich muss mal überprüfen, ob das konsequent immer so ist oder ob ich das irgendwo in einer Routine vergessen habe.

Gruß, Nils

[Nils H.]

hmm, bisher sind keine Crashes mehr aufgetreten.... komisch das.

Ich habe gerade die ersten "Komfortfunktionen" implementiert, nämlich das kopieren und tauschen von Presets, außerdem Shortcuts zum editieren und speichern von Presets.  War erstaunlich leicht, hat keine halbe Stunde gedauert. So schlecht scheint mein Programmierunterbau doch nicht zu sein, musste nur ein paar Variablen umspeichern und ein paar bereits fertige Funktionen aufrufen... ich bin stolz auf mich  .


Der Weg zum editieren eines beliebigen Presets ist Menü > Edit Preset > Preset auswählen, loseditieren.  Anschließend kehrt der Controller zum vorher geladenen Preset zurück. Das gerade aktive Preset kann jetzt über langes Drücken des Edit-Tasters direkt editiert werden. Außerdem lässt sich im Direct-Mode die gerade gedrückte Tasteranordnung ebenfalls über langes Drücken von Edit abspeichern. So langsam bekommt auch die Bedienung Struktur.

Ich habe überlegt, jedem CC-Taster mehr als eine CC-Zuordnung zu spendieren. Platz im EEPROM für die Daten ist genug, ich denke, das könnte ganz praktisch sein. Mögliches Szenario: Im Direktmodus bei einem Tastendruck im Looper mehrere Loops gleichzeitig aktivieren, oder z.B. beim Umschalten des Amps auf den High Gain Kanal automatisch im Multieffekt das Noise Gate aktivieren - und eben ohne lästige Presetwechsel.

Ich mus nur aufpassen, dass ich nicht die Featuritis bekomme... wobei: Da geht noch was. Mein neues Vorbild: http://www.youtube.com/watch?v=bLKo8cQcxcc .

Gruß, Nils

[Nils H.]

Moin,

BTW  vielleicht hast Du es schon geschrieben, aber wie hinterlegst Du den Status der Effekte im Board (Annahme: Gmaj oder Gmaj als Gegenstück). Ich speichere sie ATM nicht und damit kann es sein daß das erstemal schalten nach Presetwechsel 127 statt 0 sendet und erst beim zweiten mal findet der Wechsel statt? Speicherst Du alles in Deinen Presets im fußcontroller oder hast Du eine Möglichkeit gefunden den Status beim Gmaj(2) zu erfragen?

was ich rausgefunden habe: Das G-Major 2 sendet die entsprechenden CCs beim Presetwechsel über MIDI-Out raus. Wennn Der Controller das also kann, bekommt er vom G-Major den aktuellen Status mitgeteilt.

Gruß, Nils

[kugelblitz]

Merci Nils,

wenn ich einmal Zeit finde, werde ich mitsniffen was da so raus kommt. Leider ists ATM sehr eng. Aber Danke für den Hinweis.

Gruß,
Sepp