ich versuche gerade mit einem Teensy 3.2 per USB Mididaten zu versenden.
Im Gerätemanager wird der Teensy auch als Teensy Midi angezeigt.
Kompilieren und hochladen des original Beispiel Sketch "USBMidi AnalogControlChange" funktioniert fehlerfrei.
Stomversorgung des Teensy läuft über USB.
Der teensy Loader ist in Version 1.45 installiert.
Die IDE (1.86, WIN 10) ist eingestellt auf:
Teensy 3.1/3.2
USB Type = Midi
Keyboard Layout = Deutsch
CPU Speed = 72 MHz
Optimize = Faster
Port = "hid#vid_16c0&pid_0485 (Teensy 3.2) Midi"
Leider kommt im angeschlossenen VST Instrument nix an (auch dann nicht wenn zB loopBe aktiviert wird).
Angeschlossen sind am Teensy die Schleifer von 4 Potis an A0 bis A3.
Das andere Ende der Potis liegt jeweils auf AGND.
Ich bin mir aber nicht sicher an welchen PIN ich mit dem + Anschluß der Potis am Teensy dran muss ?
Es gibt einen 3,3 Volt PIN mit max 250mA (auf der rechten Seite gibts den 3,3 Volt PIN nochmal), dann gibts einen VIn und einen VBat.
Ich habe das USB MIDI AnalogControlChange Example verwendet. Dort die Controller Nummern angepasst, Serial.print zugefügt und die Variablen const int mit eigenen Namen versehen.
Funktioniert soweit auch alles - Aber:
Ich sehe am angeschlossenen Vst Instrument Midiaktivitäten auch wenn kein Poti verstellt wird - wodurch unbeabsichtigte Midievents ausgelöst werden können.
Im Seriellen Monitor ist ein "Zittern" der Potiwerte gut zu sehen.
Die Potischleifer sind derzeit zur "Entprellung" alle zusätzlich mit je 10nF gegen GND gelegt.
Potigehäuse sind miteinder verbunden und liegen direkt auf GND.
Welche Entsörungsmaßnahmen würden helfen ?
Der Sketch fragt die Potis 50 x pro Sekunde ab - für meinen Fall wahrscheinlich viel zu viel.
void loop() {
// only check the analog inputs 50 times per second,
// to prevent a flood of MIDI messages
if (msec >= 20) {
msec = 0;
stingray05:
Welche Entsörungsmaßnahmen würden helfen ?
Dein Problem ist mir bekannt. Wenn ich Dich richtig verstehe, möchtest Du, dass das Poti erst ein bisschen gedreht werden muss, um eine Änderung des Wertes zu bewirken. Also im Grunde einen Algorithmus, der die „ganze Skala“ in Stufen (z. B. 0-127) teilt, die jeweils durch eine Hysterese voneinander „getrennt“ sind.
So etwas wollte ich mir mal programmieren, bin dann aber nicht auf den richtigen Ansatz für eine Lösung gekommen. Wer sich hier also ein Fleißbildchen verdienen möchte ...
Sollte das nicht per map Funktion erschlagen sein? Oder halt auch Bitshifterei, dann sind die kleinen Zucker doch weggebügelt.
Bei meinen Versuchen wars auch wurscht, wenn nicht jeder einzelne Wert gesendet wurde, also Lücken in den 127 Werten drin waren. Hängt aber ggfls auch vom Controller bzw dem VSTi ab ob das stört.
Klaus_ww:
Sollte das nicht per map Funktion erschlagen sein?
Nein, leider nicht. Die map()-Funktion erzeugt halt nur „harte“ Grenzen. Die Grenzen müssen aber an unterschiedlichen Stellen liegen, je nachdem, ob die Änderung des Ausgangswerts von „oben nach unten“ erfolgte oder umgekehrt.
Klaus_ww:
Oder halt auch Bitshifterei, dann sind die kleinen Zucker doch weggebügelt.
Bei meinen Versuchen ...
Oh, Bitshifterei fiel mir bislang nicht als möglicher Ansatz ein. Kannst Du Deinen Versuch posten?
gregorss:
Oh, Bitshifterei fiel mir bislang nicht als möglicher Ansatz ein. Kannst Du Deinen Versuch posten?
int n0 = analogRead(A0) / 8;
...
int n0 = analogRead(A0) >> 3;
Diese beiden Zeilen führen zum selben Ergebnis. Möglicherweise wird der Compiler sogar identischen Code erzeugen.
stingray05:
Im Seriellen Monitor ist ein "Zittern" der Potiwerte gut zu sehen.
Das kann ich nicht reproduzieren, bei mir schwankt der gelesene Wert um ein Bit. Durch die Division durch 8 kann ich die Werte zwischen 0 und 127 exakt einstellen.
Testprogramm (Teensy 3.2):
void setup() {
Serial.begin(9600);
while (!Serial);
Serial.println("Anfang");
}
// store previously sent values, to detect changes
int previousA0 = -1;
elapsedMillis msec = 0;
void loop() {
// only check the analog inputs 50 times per second,
// to prevent a flood of MIDI messages
if (msec >= 20) {
msec = 0;
int n0 = analogRead(A0) / 8;
// only transmit MIDI messages if analog input changed
if (n0 != previousA0) {
Serial.println(n0);
previousA0 = n0;
}
}
}
Diese beiden Zeilen führen zum selben Ergebnis. Möglicherweise wird der Compiler sogar identischen Code erzeugen.
Darauf, dass der Compiler identischen Maschinencode erzeugt, würde ich meinen Hintern verwetten.
Das Blöde ist aber, dass dabei harte Grenzen entstehen, bei denen nicht unterschieden wird, von welcher „Seite“ sie überschritten werden. Wenn das Bit, um das der Eingangswert schwankt, dann kippt, wenn das Poti genau auf einer Grenze steht, dann zappelt auch der Ausgangswert.
Wäre blöd, wenn es so einfach wäre.
Gruß
Gregor
PS: Mir ist eingefallen, wie das Problem gelöst werden kann: Vor dem Mappen muss unterschieden werden, in welcher Richtung die Änderung stattgefunden hat - erst dann wird wird gemappt. Die „Skala“ beim Mappen zu verschieben ist trivial.
Ich stimme Dir zu, weshalb ich in #3 auch einen anderen Vorschlag gemacht habe.
Allerdings haben wir jetzt zwei Themen, denn das Zittern, das der TO beschreibt, kann ich nicht reproduzieren, außer auf den harten Grenzen. Nur gelegentliches Zittern wäre damit zu erklären.
gregorss:
Wäre blöd, wenn es so einfach wäre.
Nicht ganz, ich mache mal eine Vorschlag:
void loop() {
// only check the analog inputs 50 times per second,
// to prevent a flood of MIDI messages
if (msec >= 20) {
msec = 0;
int n0 = analogRead(A0);
// only transmit MIDI messages if analog input changed
int diff = n0 - previousA0;
if (abs(diff) > 4 && (n0 / 8 != previousA0 / 8)) {
Serial.print(n0); Serial.print('\t'); Serial.println(n0 / 8);
previousA0 = n0;
}
}
}
agmue:
Allerdings haben wir jetzt zwei Themen, denn das Zittern, das der TO beschreibt, kann ich nicht reproduzieren, außer auf den harten Grenzen.
Ob sich ein zusätzliches Thema ergeben hat, müsste der OP sagen. Evtl. habe ich ihn aflcsh interpretiert.
agmue:
void loop() {
// only check the analog inputs 50 times per second,
// to prevent a flood of MIDI messages
if (msec >= 20) {
msec = 0;
int n0 = analogRead(A0);
// only transmit MIDI messages if analog input changed
int diff = n0 - previousA0;
if (abs(diff) > 4 && (n0 / 8 != previousA0 / 8)) {
Serial.print(n0); Serial.print('\t'); Serial.println(n0 / 8);
previousA0 = n0;
}
}
}
Was hältst Du davon?
Das ist schon mal bessergenauso gutschon mal besser genauso gut. Du berücksichtigst dabei nicht, aus welcher Richtung die Änderung kommt. Es sollte die Symptomatik aber schon mal verbessern.
Mal so am Rande: selbst wenn ein Wert zappelt, wen stört das im Klanggeschehen bei einem Controlerwert? Wer partout daran verzweifelt, sollte vielleicht Encoder statt Potis nehmen.
Klaus_ww:
Mal so am Rande: selbst wenn ein Wert zappelt, wen stört das im Klanggeschehen bei einem Controlerwert? Wer partout daran verzweifelt, sollte vielleicht Encoder statt Potis nehmen.
Es gibt Controllerwerte, wo sich eine Änderung um nur einen Wert sehr störend auswirken kann. Ob man eine Triangel oder eine Pauke zu hören bekommt, fällt auf, glaube ich
Bei mir zappelt der Wert um ein Bit, was für einen AD-Wandler vollkommen normal ist. Wenn es aber wie vom TO beschrieben, auch noch nach einer Division durch acht zappelt, liegt ein Fehler vor. Diesen Fehler gilt es zu finden. Das ist aus meiner Sicht das derzeitige Thema des TOs.
Wenn das geklärt ist, kann man sich mit der von Gregor angeschnittenen Problematik auseinandersetzen. Ob es für dieses Thema relevant ist, kann ich nicht einschätzen, da ich mich mit den angeschlossenen MIDI-Programmen nicht auskenne.
@Gregor: ich gehe von CC Messages aus, da stört ein Flattern um einen Wert nicht. Oder wo hat Du solche Effekte?
Anders natürlich bei ProgChange oder ähnlichem, glaube aber nicht, dass es hier darum geht.
Klaus_ww: @Gregor: ich gehe von CC Messages aus, da stört ein Flattern um einen Wert nicht. Oder wo hat Du solche Effekte?
Anders natürlich bei ProgChange oder ähnlichem, glaube aber nicht, dass es hier darum geht.
Worum es genau geht und ob ich das Problem überhaupt richtig verstanden habe, dazu sollte sich mal der OP äußern. Musiker können (wie alle Künstler, und ganz besonders „Künstler“) ziemlich pingelig sein, wenn es um vollkommen unwichtige Dinge geht. Selbst wenn es total unwichtig wäre, hätte er mein volles Verständnis.
Wenn es das ist, was ich bislang vermute, finde ich, dass man die map()-Funktion um einen passenden Parameter erweitern sollte. Dann wäre diese Funktion wenigstens etwas „wert“. Bislang wird dadurch doch nur ein wirklich popliges Dreisatz-Problem gelöst, das nach meiner Erinnerung unterste Unterstufe ist.
und ja, es geht um CC Werte die hier zappeln. Teilweise um mehr als +/- 5 Punkte.
Das Problem kommt offenbar aus den Anlaog Eingängen, - ist im Seriellen Monitor zu sehen.
Für sich genommen sind die Werte nicht das Problem. Allerdings laufen die PlugIns zusammen mit ettlichen anderen in ner DAW.
Da mach ich mir bei ungewollter Midiaktivität schon so meine Gedanken => Stichwort "Midihänger".
Ich werde die Potis mal einzeln testen, möglicherweise ist da schon ein fauler dabei...
Wenn das keinen Befund ergibt kommt das ganze auf Lochraster.
Zur Zeit hängen die Potischleifer über je 10nF zusätzlich an GND. Die Potigehäuse sind miteinander verbunden und mit einer Verbindung ebenfalls auf GND gelegt.
Welche Hardwareseitigen Entstörungen wären noch sinnvoll ?
Machen Externe Pulldowns an den verwendeten Analog Eingängen Sinn - welchen Wert sollten die
haben ?
Im Netz finden sich auch immer wieder Infos unbelegte Analog Eingänge grundsätzlich direkt auf GND zu
legen... Was ist davon zu halten ?
Wie siehts denn beim Teensy 3.2 mit internen Pullup / Pulldown Widerständen aus,- hat der sowas ?
Konnte da bisher keine genauen Infos finden.
