Projekt(idee): Octakontrol

markboombastik schrieb:
"markboombastik hat geschrieben:
es wird langsam realistisch...
Naja, mit deiner Grundaussage hast du wahrscheinlich recht - wobei ich realistisch an "Zeit" und "Aufrechterhaltung der Motivation" knüpfen würde. U know?

mfG Bruce"


war nur halbspass....

;-)
Zum Vergrößern anklicken....

da es wohl eh einschläft:

von der optik erinnert mich der controller doch sehr stark, an die rechte seite meines AKAI MPK 49 :mrgreen: :floet:
 
Gibt doch schon genug Controller, die Du nehmen kannst und die ähnlich Deiner Specs. sind. Sehen halt nur nicht so aus wie das OT:
Behringer BCF 2000
Novation Remote Zero SL
CME Bitstream 3X
Icon iControlls Mixing Controller
Korg nanocontroll
Dazu noch diverse Geräte, welche nur noch gebraucht erhältlich sind.

Notfalls betreibt ihr die o.a. Teile mit einem Kenton USB Host am OT. Ich würde da an eurer Stelle keine weitere Energie für solch ein Projekt aufwenden.
 
Mr. Roboto schrieb:
Gibt doch schon genug Controller, die Du nehmen kannst und die ähnlich Deiner Specs. sind. Sehen halt nur nicht so aus wie das OT:
Behringer BCF 2000
Novation Remote Zero SL
CME Bitstream 3X
Icon iControlls Mixing Controller
Korg nanocontroll
Dazu noch diverse Geräte, welche nur noch gebraucht erhältlich sind.

Notfalls betreibt ihr die o.a. Teile mit einem Kenton USB Host am OT. Ich würde da an eurer Stelle keine weitere Energie für solch ein Projekt aufwenden.
Zum Vergrößern anklicken....


:floet: :school:
 
Deswegen auch mein Vorschlag mit Midibox, da ist technisch eigentlich alles schon fertig, man braucht sich nurnoch um das Design und mechanisches zu kümmern.
 
Jo, danke nochmal/schonmal für den ganzen Input.

@microbug: Das Buch ist inzwischen angekommen. Reinlesen war super, aber ich glaube insgesamt ist das dann doch alles etwas oldscool (sicher die Standards haben ihre Gültigkeit nicht verloren, aber ...). Egal, gucke da trotzdem nebenbei noch etwas durch.

@fertige Midi-Controller: Gute, konkrete Hinweise und bspw. der Behringer BCF ist ja auch unschlagbar günstig ...

... ABER: Ich überlege noch! Arbeite mich jetzt gerade etwas in die Midibox rein und um noch etwas mehr "Zeit zu verschwenden" habe ich bereits ein Projekt in Eagle angefangen (hilft mir auch einige Dinge nachzuvollziehen).

UND: Ich bin immer noch der Meinung: Wenn jemand den "perfekten" Midi-Controller für den Octatrack baut, wird er - auch wenn es bereits 10000000 Midicontroler gibt - Abnehmer finden. Ideen gab es dazu ja hier schon einige ...

mfG Bruce
 
EIn paar generelle Kommentare (von einem, der sich nen Midibox64-Controller für Ableton Live gebaut hat, siehe dieser Thread):

Die "Logik" hinter dem ganzen ist relativ simpel mit Dopfer, Midibox oder Arduino zu machen. Kein Hexenwerk (solange es nur um CC geht).
Der Elektronik-Teil/Löten ist bei der Anzahl an Elementen auch einfach.
Nicht zu unterschätzen ist der ganze mechanische Bereich, sprich: stabiles Gehäuse/Frontplatte, Elemente montieren, Platinen haltern und Schnittstellen nach aussen. Also gleich von Anfang an daran denken.

Encoder: kann ein Problem werden, da das nicht über MIDI CC geht, weil der Encoder ja den aktuellen Wert als Referenz braucht.

"der perfekte Controller": leider gibts den nicht für alle, jeder hat seine Präferenzen, seinen Workflow etc., daher sind auch die "kommerziellen" Controller reine Kompromiss-Design.
Aber nicht entmutigen lassen!
Sich den persönlich passenden Controller bauen ist Gold wert - kosten eben nur Arbeit.
 
... kenne deinen thread (natürlich) - auf jeden Fall auch sehr informativ. Hab mich bspw. bzgl. der Fader schon inspirieren lassen - allgemein auch ein guter Tip von dir, wenn man nicht das richtige Bauelement findet, ein "höherwertiges", abwärtskompatibles zu nehmen und da etwas unbeschaltet zu lassen (also wie bei dir Stereo-Fader, wenn man eigentlich nur Mono braucht) (so lange es preislich passt).

@"Logik": Habe das (mindestens grob) bei der Midibox auch schon geschnallt, bei dem Doepfer-teil sehe ich 0-Probleme, Arduino vermute ich, da müsste ich selbst noch etwas Programmierarbeit (=mehr Einarbeitung für mich) leisten (gibt da ja einiges für Midi - aber nicht so fertig).

@Mechanik: Ja, das habe ich im Hinterkopf (und bin da auch schon etwas bewandert) - deswegen möchte ich bspw. nicht die Standard-Midibox-Einzelplatinen und Bedienelemente mit fliegender Verdrahtung. Ich möchte zwei Platinen und Bedienelemente PCB-mounted. So etwas mache ich gerade schon (nebenbei so wie ich Zeit&Lust habe) in Eagle - also nich Core-Platine usw. kaufen, sondern selbst (nach)bauen&layouten. Würde (nach aktueller Vorstellung) nur den PIC18F452 mit Bootloader bei Mikes Midishop bestellen und den Rest selbst machen.

@Encoder: Interessant, hatte ich nicht bedacht ... aber: Du meinst, das Programm "braucht den aktuellen Wert", nicht der Encoder (der ist ja nur ein Schalter), oder? Wie dem auch sei - das Eagle Projekt ist eh erstmal abgespeckt (nach dem Vorbild Low-Cost Midibox64, also 8Fader, 8Potis, 8Schalter).

mfG Bruce
 
Bruce schrieb:
@Mechanik: ... zwei Platinen und Bedienelemente PCB-mounted.
Zum Vergrößern anklicken....
Das ist für mich aber eher "Elektronik". 8)
Mit Mechanik meine ich die reine Hartware, sprich Gehäuse, Bohrungen für Drehachsen und Taster, Platinenbefestigung etc.
Wenn du alles auf ein PCB packst, solltest du vorher unbedingt die Höhen der Bedienelemente prüfen, damit nachher alles auf eine gleiche Höhe (über der Frontplatte ö.ä.) kommt. Oft sind dann die Poti/Encoder-Drehachsen mit passendem Knopf drauf zu kurz oder lang, die Taster sind zu weit versenkt etc., solche Überraschungen halt.
Kurz gesagt: Platinen designen :supi: aber nicht das große Ganze vergessen. Speziell DIY-Gehäuse ist alles andere als trivial (wenns gut werden soll).

Bruce schrieb:
@Encoder: Interessant, hatte ich nicht bedacht ... aber: Du meinst, das Programm "braucht den aktuellen Wert", nicht der Encoder (der ist ja nur ein Schalter), oder?
Zum Vergrößern anklicken....
Ok, besser formuliert: die Controller-Logik braucht den aktuellen Werte, wenn du über CC arbeiten willst.

Der Encoder ist ja "nur" ein zweifacher Schalter. Er kann der Logik nur "Plus 1" oder "Minus 1" melden. Über MIDI CC kannst du dem OT aber nur absolute Werte melden.
Frage ist nun: von wo fange ich an +/- zu zählen ? Wenn ich den Referenzwert aus dem OT habe (also z.B. Pitch von Track 1 steht bei "50"), kann der Contorller bei "Plus 1" den CC entsprechend als "51" melden usw.
Alternativ kannst du natürlich auch immer bei einem festen Wert anfangen (z.B. in der Mitte bei 64), aber dann ist der ganze Vorteil der Encoder weg und du kannst gleich normale Potis nehmen.

Evtl. kann die die Doku zur Midicommand von Ruin&Wesen weiterhelfen, der hat ja auch Encoder und steuert damit die MD. Weiss aber nicht, ob das über CCs geht oder was anderes.
 
und? projekt schon eingeschlafen oder kommt da noch was?

ich will ja nicht drängeln, hab ja auch garkeinen OT. finde aber das trotzdem sehr interessant... vorallem wenn das echt so ein communityding wird...
 
Ick sag mal so: Projekt ist nicht tot, ruht aber derzeit. Hab noch das ein oder andere weitere Projekt usw. ... :)

Hatte zwischenzeitlich schon in Eagle begonnen, bin da aber noch nicht sehr weit. Wie schon gesagt, ich hab mich dann für eine eher simple & günstige Variante entschieden (nach dem LowCost-Vorbild).

Ich bleibe da aber dran.

Als wirkliches "Community Ding" sehe ich das ganze aber nicht, da ich hier zwar wirklich viele gute Anregungen/Hilfe bekommen habe, letztlich aber niemand an einer richtigen Mitarbeit interessiert war/ist (so hab ich das jetzt mal verstanden). Muss ja auch nicht und so mach ick das jetzt nur so, wie ich will, für mich. Werde aber natürlich teilhaben lassen, wenn es was gibt. :)

mfG Bruce
 
Kurzer Zwischenbericht mal von mir (falls es jemanden interessiert ;-) ):

Hatte am Wochenende einen Gig mit dem Octa + UC33. Grundsätzlich schon gut, vom Handling her gefällt mir die "Uzi" aber noch nicht 100% und meine Idee bleibt.

Bin allerdings doch erstmal wieder etwas von der Midibox abgerückt und habe soeben ein Arduino Uno + etwas Gedöhns zum testen und spielen bestellt. Finde Arduino für dieses Projekt dann doch cooler ... mal gucken wie weit ich komme ...

Geplante Features sind jetzt erstmal:
  • - 8 Fader (Track Level / frei zuweisbar)
  • - 8 Potis (Amp Level / frei zuweisbar)
  • - 8 Taster (oder 16? / Mute/Solo / frei zuweisbar)
  • - Midi I/O/Thru (Midi-merge ... mal gucken, ob und wie ich das hinbekomme - geht für mich aber auch erstmal ohne Midi-In)
  • - Midi In per USB (heeres Ziel! Davon bin ich wohl noch sehr weit entfernt - geht definitiv auch erstmal ohne ...)

mfG Bruce
 
Also, soweit funktioniert das mit Arduino schon ganz gut. D.h. lernen und meine ersten Tests läuft bisher (soweit bin ich ja noch nicht) ganz gut.

Aber: Vielleicht kann mir ja schon jemand (fachkundig in Arduino oder generell Mikrocontroller-Zeugs helfen:

Code: 
#include <MIDI.h>

int poti = 0;
int last = 0;

void setup() {
  MIDI.begin();  
}

void loop() {

   poti=analogRead(0)/8;
   if(poti!=last){
   MIDI.sendControlChange(101,poti,1); //Controller#, Wert, Kanal
   last = poti;
   }
}

Damit sende ich mittels Poti (10k linear) Werte für Controllernummer 110 an die MBase (mein "Testgerät", weil der mir die Werte gut anzeigt). Die If-Abfrage und die Variable "last" dient dem Zweck den Wert nur zu senden, wenn der Poti betätigt wird.

Nun habe ich manchmal etwas Jitter (wenn das der richtige Begriff dafür ist), d.h. der Wert in der Mbase springt bei nicht betätigtem Poti ab und zu zwischen zwei Werten. Es hält sich in Grenzen, aber Frage: Kann ich davon ausgehen, dass das verschwindet, wenn ich meinen Testaufbau (fliegende Verkabelung) verlasse und alles hübsch auf dem PCB habe oder macht man da für gewöhnlich
a) per elektrotechnischer Maßnahme
oder
b) softwaretechnisch (Mittelwertbildung würde mir da einfallen)
etwas dagegen?
oder c) bringt es ein hochwertigerer Poti? (wobei das jetzt auch nicht das allerbilligste ist / Omeg - der macht jedenfalls nen ganz vernünftigen Eindruck)

ps. Für die Arduino-Kenner: Ich benutze derzeit die Midi-Library von Franky, die ich bisher ganz praktisch finde. Gegenstimmen? ;-)

mfG Bruce
 
Springen zwischen zwei Werten bekommt man durch Hard- oder Software Mittelwertbildung nur reduziert, aber nie ganz weg.
Denn das Poti kann immer genau auf der Stellung zwischen zwei Werten stehen, und dann reicht kleinstes Rauschen aus, um es immer mal wieder wechseln zu lassen.

Wenn es stört, dann brauchst du eine Hyterese. D.h. der Wert muss sich um mehr als "1" ändern, bevor die Änderung weitergeben wird. Diese Hysterese kann man vor der Skalierung auf Midi (bei dir das /8) machen, dann verlierst du dabei nichts. Wenn du sowieso durch 8 teilst, kannst du den "Totbereich" auch etwas größer machen, dass ist dann störunempfindlicher. (Die 10 Bit vom Wandler sind ja schon etwas optimistisch, so direkt in der Nähe des mit 20MHz rackernden Digitalteils... 10Bit sind 60dB Störabtstand, die hat kein je Kassettenrekorder geschafft... )
 
Danke!

Dadurch, dass ich vor der IF-Abfrage durch 8 teile muss sich der Wert am Eingang doch schon um mehr als 1 ändern, also MidiCC-Wert 127 entspricht 1016 bis 1024 - so meine Vorstellung. Mein Test bestätigt das auch: Wenn ich erst nach der IF-Abfrage dividiere, dann wird das "zappeln" jedenfalls deutlich stärker.

Wie gesagt, das zappeln hält sich in Grenzen, aber ich will das gar nicht haben und werde auf jeden Fall da noch etwas rumprobieren:
a) Hysterese (wenn ich das richtige darunter verstehe)
b) Tiefpass (elektrisch)
c) Tiefpass / Mittelwert (Software)
d) IF-Abfrage ändern / statt ungleich z.B. die Differenz muss größer als 16 statt 8 (bzw. auf Midi skaliert 2 statt 1) sein
e) Software (Arduino): die Funktionen "map" und "constrain" (geht vielleicht in die Richtung "Totbereich" [?])

mfG Bruce
 
Bruce schrieb:
Danke!

Dadurch, dass ich vor der IF-Abfrage durch 8 teile muss sich der Wert am Eingang doch schon um mehr als 1 ändern, also MidiCC-Wert 127 entspricht 1016 bis 1024 - so meine Vorstellung. Mein Test bestätigt das auch: Wenn ich erst nach der IF-Abfrage dividiere, dann wird das "zappeln" jedenfalls deutlich stärker.

Wie gesagt, das zappeln hält sich in Grenzen, aber ich will das gar nicht haben und werde auf jeden Fall da noch etwas rumprobieren:
a) Hysterese (wenn ich das richtige darunter verstehe)
b) Tiefpass (elektrisch)
c) Tiefpass / Mittelwert (Software)
d) IF-Abfrage ändern / statt ungleich z.B. die Differenz muss größer als 16 statt 8 (bzw. auf Midi skaliert 2 statt 1) sein
e) Software (Arduino): die Funktionen "map" und "constrain" (geht vielleicht in die Richtung "Totbereich" [?])

mfG Bruce
Zum Vergrößern anklicken....

Ich nutz das hier mal weiter auch als offenes Notizbuch ... bin dabei für Hinweise immer dankbar.

a) / d) haben es nicht gebracht, möglicherweise habe ich das mit der Hysteres auch noch nicht richtig verstanden.

Der elektrische Tiefpass (b) funktioniert schon, zieht aber definitiv ein spürbares Nachlaufen (Latenz) mit sich - nun könnte man evtl. noch mit der richtigen Grenzfrequenz experimentieren, aber ich habe mich schon quasi dagegen entschieden, schätze das jetzt so ein, dss ein wirksames Bekämpfen des Rauschens immer mit spürbarer Latenz einhergehen wird. Außerdem ist es unflexibler als das per Software zu machen.

Mittelwertbildung (c) funktioniert für mich bisher am Besten. Ich kann nur noch nicht einschätzen, wie weit ich da gehen kann. Mit einem Mittwelwert aus 1000 Potiabfragen kann ich bisher (bei nur einem Poti) keine Latenz und auch kein Jitter mehr sehen, glaube aber dass das unrealistisch ist ...

e) Mit Map kann man zwar skalieren, es bringt bzgl Jitter aber keine Vorteile. Der Code wird auch nicht kleiner, also uninteressant dafür.

f) Totbereich: Finde ich sehr interessant den Gedanken, wie ich ihn mir gerade mache: Warum nicht aus den 5V per Spannungsteiler 1,25V machen ... spart auf jeden Fall schonmal die Skalierung auf Midi per Software - dafür habe ich allerdings auch wieder zwei Bauteile mehr auf der Platine. (Anmerkung: belasteter Spannungsteiler - ich gehe mal von hochohmig [>1MOhm] bei den analogen Eingängen aus (?))

Edit: Spannungsteiler (oder auch Vorwiderstand), Hardware-Tiefpass ... alles Quatsch. Nur als Software macht die Bekämpfung des Zappelns hier Sinn - glaube ich gerade rausgefunden / verstanden zu haben ... :)

Edit2: Okay, es sieht so aus, als würde d) also Änderung größer 2 in der IF-Abfrage und danach erst Division durch 8 (bzw Bitshift um 3) reichen ... cool, weil easy, weniger Code und sicher auch nicht so rechenintensiv wie 1000 Mittelwerte :)

mfG Bruce
 
Sooo, die Midi-Schnittstelle:



... muss man ja auch nix neues erfinden, nur auswählen. Konzept dafür ist dann also: Klassisches Midi-Trio + eine Buchse umschaltbar zweiter Thru / zweiter Out + Midi-Out LED.

mfG Bruce
 

Anhänge

  • Midi.jpg
    Midi.jpg
    112,8 KB · Aufrufe: 35
Code: 
delta = 1;                                          // kannst ja hier später anpassen
void loop() {
   poti=analogRead(0)/8;
   if( poti!=last && (poti - last) > delta ){
        MIDI.sendControlChange(101,poti,1);        // Controller#, Wert, Kanal
        last = poti;
   }
}
Was ist Deine Lösung bislang?
 
Ähnlich. Bei mir sieht es jetzt so aus:

Code: 
void loop() {

   poti=analogRead(0);
   if(abs(poti-last)>2){
   MIDI.sendControlChange(101,poti >>3,1); //Controller#, Wert, Kanal //Poti - ">> 3" = Bitshift um 3 Bits = das selbe wie Division durch 8: Skalierung auf Midi (Bitshift spart Code)
   last = poti;
   }

}

Differenz größer 2 scheint auszureichen, sogar wenn man erst nach der IF durch 8 dividiert (bzw. Bitshift macht, was ein paar Byte im Code spart). Werde aber dann im fertigen Gerät mal gucken, ob ich das doch noch anpassen muss - von daher ist das gar nicht so ein schlechte Idee von dir da eine Variable (delta) zu nehmen.

So sah das bei mir übrigens mit Mittelwert (bspw. mit 100 Werten) aus, scheint mir jetzt aber nicht notwendig:
Code: 
void loop() {

  potiM=0;
  for(int n=0; n<100; n++){
  poti=analogRead(0)/8; //Division durch 8 - Skalierung auf Midi & verringert gleichzeitig ebenfalls Jitter (Vermutung), da 1024 Werte nur noch 128 Werte entsprechen (Bsp.: 0,1,2,3,4,5,6,7 entsprechen alle = 0)
  potiM+=poti;
  }
  potiM=potiM/100; //Mittelwert
  
  if(potiM!=last){
  MIDI.sendControlChange(101,poti/8,1); //Controller#, Wert, Kanal
  //delay(1);
  last = potiM;
  }

}
btw. sah ich in anderen Codes, dass die für die Mittelwertbildung ein Array brauchten ... da die EInzelelwerte aber nicht interessieren, braucht man den nach meiner Methode nicht (oder hab ich einen Denkfehler?)

UND: Momentan habe ich noch ein Problem mit der Midi-Library (denke es liegt daran). Habe ich aber im Arduino-Forum beschrieben (ging davon aus dort dafür mehr Ansprechpartner zu finden). Vielleicht weiß hier ja doch jemand was dazu?

mfG Bruce
 
So, zur eigenen Motivation bzw. Zielsetzung. Hier mal ein optisch etwas ausgearbeiteter Entwurf der Oberfläche:


Unten Potis (vielleicht etwas ungewöhnlich, aber da der Controller direkt vor den Octatrack kommen soll, und die Bedienoberfläche dort ja auch noch gebraucht wird, fände ich sie oben störend). Mittig Fader. Rechts und oben Taster.
Die Taster rechts weisen den obigen Tastern Funktionen je Kanal (1-8) zu: Solo, Mute, Rec Arm, Track Arm, Note Trigger, ... bin da bzgl der letzten drei Tasten noch unschlüssig (weglassen macht aber keinen Sinn, da der Multiplexer an dem die hängen ja eh 8 Eingänge hat). Die 2x 7-Segment-Anzeige stellt die aktuelle Zuweisung dar, wäre im Bild jetzt also Solo.

mfG Bruce
 

Anhänge

  • Octakontrol_preview.jpg
    Octakontrol_preview.jpg
    38,9 KB · Aufrufe: 199
Nur so als kleiner Tip: Wichtig sind nicht die Anzahl der Fader, Tasten, Crossfader, Joysticks, XY-Pads, Ribbon-Controller, sondern, was passiert wo, wenn man wo, wann, wie drückt oder dreht. Wie gut oder schlecht ist die Gesamtlogik und die vorhandene Funktionalität?

Zu Deinem Beispiel: Anstatt der 8 Tasten rechts, könntest Du genauso nur 1 Taste nehmen, ihr eine "SHIFT" Bedeutung geben, für andere schon vorhandene Tasten, also die oberen 8 Tasten. Du könntest also rechts 8 * SHIFT haben, somit zwischen 8 * 8 = 64 Funktionen auswählen, anstatt nur zwischen 1 * 8 = 8, wie in Deinem Beispiel.

Erlaubt man auch zwei Tasten gleichzeitig zu drücken, erhöhen sich die Möglichkeiten nochmal.

Noch eine Unterscheidungsvariation für die Tasten rechts:
1. Rechte Taste drücken, gedrückt halten, obere Taste drücken --> Funktionalität A auf den oberen Tasten
2. Rechte Taste drücken, loslassen, obere Taste drücken --> Funktionalität B auf den oberen Tasten
3. Rechte Tasten, zwei Tasten gleichzeitig drücken, gedrückt halten, obere Taste drücken --> Funktionalität C auf den oberen Tasten
4. Rechte Tasten, zwei Tasten gleichzeitig drücken, loslassen obere Taste drücken --> Funktionalität D auf den oberen Tasten

Fazit: Mit wenigen Tasten kann man auch viel mehr Funktionalität in die Kiste einbauen. Hängt nur von der Idee und vom zugehörigen Code ab.
 
Danke für den / die Hinweis/e!

Grundsätzlich hatte ich an so etwas schon gedacht, aber es ist auch so ein Kompromiss zwischen Funktionsumfang & direktem Zugriff. Wohin das nämlich führt mit Mehrfachbelegungen / "Shift", dafür ist gerade der Octatrack ein gutes Beispiel. Genau das ist ja ein Punkt, warum ich einen Midi-Controlelr dafür bauen möchte.

Dennoch: Ich werde nach deiner Anregung da nochmal drüber nachdenken.

mfG Bruce
 
denke an das ursprüngliche ziel. denk an liveact funktionen. shift tasten sind kacke für sowas. es muss schnell gehen und man muss direkten zugriff haben im idealfall. :D
 
Ich würde die seitlichen Tasten auch eher symmetrisch gestalten: 8 Tasten rechts, dann auch 8 Tasten links. Oder geteilt in zwei Hälften mit je 4 Tasten. Das Gruppieren in linke-Hand, rechte-Hand finde ich praktisch. 4 Tasten nebeneinander kann man auch einfacher als Akkorde greifen.

Ich würde da aber sowieso anders vorgehen, eher sowas wie zwei nano-control kaufen, eins für die linke Hand, eins für die rechte Hand. Die sollten halt normales Midi-Out haben, aber Arduino versteht bestimmt auch Midi-Über-USB, also wäre es dann egal. Jetzt wichtig: Die intelligente-Arduino-Kiste soll nur noch die beiden nano-Controls mit Energie versorgen, auch sich selbst, sowie deren Signale in neue Ausgangssignale umwandeln, die dann in den Octatrack gehen.

Vorteile:
1. Billig
2. Weniger Fader/Regler usw. Lötarbeit
3. Kannst Dich auf wesentliche Funktionen des Systems konzentrieren.

Muss nicht nano-control sein, könntest auch irgendwelche zwei Faderfoxes nehmen. Ja, zwei Faderfoxes wären schöner, da gibt es ja mehrere Varianten.

2 * Faderfox + 1 * Arduino-Custom-Programming = Octakontrol oder XYZ-Kontrol
 
einfach und bedienbar halten..

gut wäre wenn man die tasten rechts nicht gedrückt halten muss sondern im jeweiligen modus wieder beide hände frei hat...

lg
 
markboombastik schrieb:
gut wäre wenn man die tasten rechts nicht gedrückt halten muss sondern im jeweiligen modus wieder beide hände frei hat...
Zum Vergrößern anklicken....
Ja, so ist es auch geplant. Rechts eine von den 8 Tastern drücken wechselt die Belegung der Tasten oben.

@TonE: Also da andere Fertighardware zu kaufen (außer das Arduino-Board - wobei selbst da überlege ich nur von Sparkfun ein USB-to-Serial zu nehmen und den Rest selbst zu machen), ist für mich definitiv uninteressant. Trotzdem auch keine schlechte Idee - auch das mit den Tasten links/rechts ... über letzteres denke ich nochmal nach*.

@s-tek: Recht haste. Das meinte ich ja auch (Kompromiss ...)

mfG Bruce

*Nachdenken bietet sich immer ganz gut beim radln zur Arbeit an ... hoffen wir mal, dass das Wetter noch ne Weile hält ;-) ...
 
TonE schrieb:
3. Kannst Dich auf wesentliche Funktionen des Systems konzentrieren.
... + 1 * Arduino-Custom-Programming
Zum Vergrößern anklicken....
Eigentlich wollte ich irgendwie betonen, dass die Endfunktionen am wichtigsten sind. Sagen wir mal 100 Funktionen, die Du schreibst. Wie die dann über die Tasten oder irgendwelche Kombis gewählt und getriggert werden ist wieder eine andere Sache. Schreibe erst die 100 Funktionen. Danach kannst Du ja mit den Zuweisungsmethoden herumspielen, auch mehrere Kombinationen erlauben, die immer zum gleichen Ziel führen. Es gibt dann eben mehrere Wege nach Rom. User A mag lieber den Weg A, User B lieber den Weg B, oder eine andere Abkürzung C oder den Quersprung über D oder einen Jumboflug über E.

Dein System sollte so aufgebaut sein, dass für ein und dieselbe Funktion mehrere Tastenzuweisungsmethoden möglich sind. Dann kannst Du immer schnell und einfach damit herumspielen, bis Du Deine Megaflow-Zuweisung gefunden hast. Hätte Spectralis Ihr System so aufgebaut, hätten Sie die Tasten, Reglerkombis usw. schnell ändern, anpassen, vereinfachen oder mehrere Wege anbieten können. Wenn alles nur auf eine Art möglich ist, was auch nur einem selbst logisch erscheint, dann gute Nacht dem Flow. :)
 
Inzwischen sind einige Teile zum Testen gekommen, lernen geht weiter ... heutige Hausaufgabe: Debounce für Taster (an einer 7-Segment-Anzeige): Funktioniert & verstanden!

Code: 
// Taster (debounced / 5ms) schaltet zwischen zwei LEDs (an Pin 2 und 13) um
int led = 13;
int led2 = 2;
int sw=3;
int a=0;
int status1=0;
int status2=0;
unsigned long t1=0;
unsigned long t2=0;

void setup() {                
  pinMode(led, OUTPUT);
  pinMode(led2, OUTPUT);
  pinMode(sw,INPUT);  
}

void loop() {

  status1=digitalRead(sw);
  t1=millis();

  if(status1!=status2 && t1-t2>5){
    status2=status1;
    t2=millis();
  
    if(status2==HIGH){
      a=~a;
    }

  }
  
  digitalWrite(led, a);
  digitalWrite(led2, ~a);

}

Nächste Aufgabe: 7-Segment-Anzeige an Schieberegister (74HC5959).

Und: Btw. @ Tone: Hab mich entschieden, ich bleibe bei den 8 Tastern rechts. Ich plane sie aber (wie von dir vorgeschlagen) auch flexibler zu nutzen (Richtung 8x8 Zuweisungen).

mfG Bruce
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Similar threads

phat
[GruftBox] - Forum/Website/Software - Projektdiskussion
2
Antworten
39
Aufrufe
7K
Anonymous
A


Neueste Beiträge

News

Zurück
Oben