[Brainstorming] Erweiterter Regelbereich von (midi-) Controllern

Pyro

50% of wicked-Armageddon
Dabei seit
13 Jan 2005
Beiträge
16.440
Reaktionen
190
Ort
H
Tacho

Nachdem im cdj-400 Thread das Thema aufkam dacht ich mir diesbezüglich doch noch mal was eigenständiges aufzumachen.
Überlegung soll sein was es theoretisch für Möglichkeiten gäbe z.B den Pitchbereich feiner aufzulösen oder anderweitig "verfeinerte" Controllerdaten senden zu können.
Ich denke des könnte ne ganz interessante Diskussion werden. ;)

Eine schlaue Zwischenlösung wäre den Pitch Fader in + und - Bereich als getrenntes Signal zu teilen --> doppelte Auflösung. Aber das müsste wahrscheinlich Hardware/Firmware mäßig gemacht werden... oder?

Gemäß der von daiko gemachten Annahme das die Pitchauflösung momentan mittels eines Kontrollkommandos, ("Kennung" + "Wert"), übertragen wird ergibt sich aus +/-8 (16) / 128 = 0,125.
Bei der von FloJ angesprochenen Variante wären es schon 0,0625 in jede Richtung + ein absolutes Kommando für die "0"
Das Spiel könnte man noch weiter treiben in dem man jew. zwei Controlledaten pro "Seite sendet, das wären dann 0,03125.
Frage ist warum das bis jetzt anscheinend noch niemand versucht hat umzusetzen!?

Weitere interessante Möglichkeiten lassen sich auch in wiki finden, inwieweit diese korrekt sind bleibt allerdings noch mal durch weitere Quellen zu prüfen.

Abschließend noch eine Frage:
Davon ausgehend das das Signal von (Schiebe-) Potentiometern "breiter" ist als der midi-Wertebereich gibt es sozusagen "Klassen" (von-bis) die das Signal interpretieren und dann den entsprechenden Controllerwert senden.
Heißt das also schlussendlich es gibt Totpunkte auf dem Faderweg bei dem einfach nichts passiert?!
Ich hab bei der Programmierung bis jetzt nur mit Tastern/Schaltern und Encodern gearbeitet, da sind die Signale eindeutig getrennt...
 
Habe noch eine viel Elegantere/Präzisere und vor allem Abwärtskompatible Methode:

Zusätzlich zu dem Normalen Pitch-Signal mit seinen weiterhin 128 Stufen wird ein weiteres Signal gesendet, was den Zwischenbereich zwischen den Einzelnen Stufen auflöst. Dadurch ergibt sich ein Wertebereich von 128*128 = 16.384 Also bei einem Pitch von +/- 16% ergibt sich damit immernoch eine Auflösung von etwa 0,002!

Und alle "alte" HW/SW verwendet einfach das normale Signal und neue HW/SW kann dann noch die präzisionswerte hinzunehmen...
 
Zuletzt bearbeitet:
Ok folgendes: habe im Netz mal das gefunden: www.midiox.com
Damit kann man Midi Signale auslesen. Ich hab gleich mal ein bisschen rumgespielt und die Midi-Signale meines Vestax VCI-100 ausgelesen. Bei bewegen des Pitch reglers von - bis + ergibt sich folgendes:

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT

00057706 1 -- B0 0E 01 1 --- Control Change
0005776D 1 -- B0 0E 02 1 --- Control Change
00057890 1 -- B0 0E 03 1 --- Control Change
0005793F 1 -- B0 0E 04 1 --- Control Change
00057AF5 1 -- B0 0E 05 1 --- Control Change
00057BC1 1 -- B0 0E 06 1 --- Control Change
00057DA3 1 -- B0 0E 07 1 --- Control Change
000583CA 1 -- B0 0E 08 1 --- Control Change
000586C0 1 -- B0 0E 09 1 --- Control Change
00058726 1 -- B0 0E 0A 1 --- Control Change
00058B4F 1 -- B0 0E 0B 1 --- Control Change
00058D6A 1 -- B0 0E 0C 1 --- Control Change
00059019 1 -- B0 0E 0D 1 --- Control Change
000591DD 1 -- B0 0E 0E 1 --- Control Change
00059499 1 -- B0 0E 0F 1 --- Control Change
0005951C 1 -- B0 0E 10 1 --- Control Change
0005970C 1 -- B0 0E 11 1 --- Control Change
000597E7 1 -- B0 0E 12 1 --- Control Change
00059A20 1 -- B0 0E 13 1 --- Control Change
00059BD5 1 -- B0 0E 14 1 --- Control Change
00059D7C 1 -- B0 0E 15 1 --- Control Change
0005A1C2 1 -- B0 0E 16 1 --- Control Change
0005A3C1 1 -- B0 0E 17 1 --- Control Change
0005A594 1 -- B0 0E 18 1 --- Control Change
0005A6D4 1 -- B0 0E 19 1 --- Control Change
0005A85E 1 -- B0 0E 1A 1 --- Control Change
0005A9E7 1 -- B0 0E 1B 1 --- Control Change
0005AB1A 1 -- B0 0E 1C 1 --- Control Change
0005ACFB 1 -- B0 0E 1D 1 --- Control Change
0005C1B9 1 -- B0 0E 1E 1 --- Control Change
0005C2B1 1 -- B0 0E 1F 1 --- Control Change
0005C524 1 -- B0 0E 20 1 --- Control Change
0005C6AE 1 -- B0 0E 21 1 --- Control Change
0005C89E 1 -- B0 0E 22 1 --- Control Change
0005CA27 1 -- B0 0E 23 1 --- Control Change
0005D0B5 1 -- B0 0E 24 1 --- Control Change
0005D18F 1 -- B0 0E 25 1 --- Control Change
0005D30A 1 -- B0 0E 26 1 --- Control Change
0005D41F 1 -- B0 0E 27 1 --- Control Change
0005D527 1 -- B0 0E 28 1 --- Control Change
0005DB4E 1 -- B0 0E 29 1 --- Control Change
0005DC62 1 -- B0 0E 2A 1 --- Control Change
0005DD5A 1 -- B0 0E 2B 1 --- Control Change
0005DE7E 1 -- B0 0E 2C 1 --- Control Change
0005DFEB 1 -- B0 0E 2D 1 --- Control Change
0005E12B 1 -- B0 0E 2E 1 --- Control Change
0005E2FE 1 -- B0 0E 2F 1 --- Control Change
0005E488 1 -- B0 0E 30 1 --- Control Change
0005E5F5 1 -- B0 0E 31 1 --- Control Change
0005EC39 1 -- B0 0E 32 1 --- Control Change
0005ED5D 1 -- B0 0E 33 1 --- Control Change
0005EEBB 1 -- B0 0E 34 1 --- Control Change
0005EFFC 1 -- B0 0E 35 1 --- Control Change
0005F120 1 -- B0 0E 36 1 --- Control Change
0005F226 1 -- B0 0E 37 1 --- Control Change
0005F822 1 -- B0 0E 38 1 --- Control Change
0005FAFB 1 -- B0 0E 39 1 --- Control Change
0005FBAA 1 -- B0 0E 3A 1 --- Control Change
0005FC68 1 -- B0 0E 3B 1 --- Control Change
0005FD7D 1 -- B0 0E 3C 1 --- Control Change
0005FE3B 1 -- B0 0E 3D 1 --- Control Change
0005FF07 1 -- B0 0E 3E 1 --- Control Change
0005FFE2 1 -- B0 0E 3F 1 --- Control Change
00060065 1 -- 90 0C 7F 1 C 0 Note On
00060E3E 1 -- 90 0C 00 1 C 0 Note Off
00060E3E 1 -- B0 0E 40 1 --- Control Change
00060F70 1 -- B0 0E 41 1 --- Control Change
00061059 1 -- B0 0E 42 1 --- Control Change
0006122C 1 -- B0 0E 43 1 --- Control Change
00061341 1 -- B0 0E 44 1 --- Control Change
0006140D 1 -- B0 0E 45 1 --- Control Change
00061C8A 1 -- B0 0E 46 1 --- Control Change
00061D82 1 -- B0 0E 47 1 --- Control Change
00061EEF 1 -- B0 0E 48 1 --- Control Change
00061F9E 1 -- B0 0E 49 1 --- Control Change
0006206A 1 -- B0 0E 4A 1 --- Control Change
00062145 1 -- B0 0E 4B 1 --- Control Change
0006221F 1 -- B0 0E 4C 1 --- Control Change
000622EC 1 -- B0 0E 4D 1 --- Control Change
00062360 1 -- B0 0E 4E 1 --- Control Change
00062401 1 -- B0 0E 4F 1 --- Control Change
00062A62 1 -- B0 0E 50 1 --- Control Change
00062B03 1 -- B0 0E 51 1 --- Control Change
00062BB2 1 -- B0 0E 52 1 --- Control Change
00062C52 1 -- B0 0E 53 1 --- Control Change
00062CC7 1 -- B0 0E 54 1 --- Control Change
00062DA2 1 -- B0 0E 55 1 --- Control Change
00062E42 1 -- B0 0E 56 1 --- Control Change
00062F00 1 -- B0 0E 57 1 --- Control Change
000631BC 1 -- B0 0E 58 1 --- Control Change
000635B9 1 -- B0 0E 59 1 --- Control Change
00063685 1 -- B0 0E 5A 1 --- Control Change
000636EC 1 -- B0 0E 5B 1 --- Control Change
000637A9 1 -- B0 0E 5C 1 --- Control Change
00063858 1 -- B0 0E 5D 1 --- Control Change
000638F9 1 -- B0 0E 5E 1 --- Control Change
00063A1C 1 -- B0 0E 5F 1 --- Control Change
000642E3 1 -- B0 0E 60 1 --- Control Change
00064498 1 -- B0 0E 61 1 --- Control Change
00064547 1 -- B0 0E 62 1 --- Control Change
0006465D 1 -- B0 0E 63 1 --- Control Change
00064772 1 -- B0 0E 64 1 --- Control Change
00064887 1 -- B0 0E 65 1 --- Control Change
000649C8 1 -- B0 0E 66 1 --- Control Change
00065047 1 -- B0 0E 67 1 --- Control Change
0006513F 1 -- B0 0E 68 1 --- Control Change
000652AB 1 -- B0 0E 69 1 --- Control Change
00065386 1 -- B0 0E 6A 1 --- Control Change
00065435 1 -- B0 0E 6B 1 --- Control Change
000654E4 1 -- B0 0E 6C 1 --- Control Change
000655B0 1 -- B0 0E 6D 1 --- Control Change
0006568B 1 -- B0 0E 6E 1 --- Control Change
00065792 1 -- B0 0E 6F 1 --- Control Change
0006587B 1 -- B0 0E 70 1 --- Control Change
000658E1 1 -- B0 0E 71 1 --- Control Change
00065973 1 -- B0 0E 72 1 --- Control Change
000659F6 1 -- B0 0E 73 1 --- Control Change
000663B5 1 -- B0 0E 74 1 --- Control Change
000663EF 1 -- B0 0E 75 1 --- Control Change
00066531 1 -- B0 0E 76 1 --- Control Change
000665A5 1 -- B0 0E 77 1 --- Control Change
000666BA 1 -- B0 0E 78 1 --- Control Change
000666F4 1 -- B0 0E 79 1 --- Control Change
000667A3 1 -- B0 0E 7A 1 --- Control Change
000667EC 1 -- B0 0E 7B 1 --- Control Change
000668AA 1 -- B0 0E 7C 1 --- Control Change
00066910 1 -- B0 0E 7D 1 --- Control Change
00066A08 1 -- B0 0E 7E 1 --- Control Change
00066AA8 1 -- B0 0E 7F 1 --- Control Change

Laut zählung in Excel ergibt das gesamt 129 Kommando-Zeilen, weniger der Tone-On und Off Kommandos, die bei 0% Pitch gesendet werden ergibt das tatsächlich 127! Den Wert des Kommandos kann man als Data 2 ablesen (überschriften bissl verschoben). Es geht jeweils von x1 bis x9, worauf ncoh xA bis xF angehängt werden.

Der Pitch Fader ist also tatsächlich als 1 Tone mit Control Change 0-127 gemappt.

Zitat Wiki:
0xBn cc vv Controller, Wert Control Change Ändert den Zustand eines Controllers (siehe nächster Abschnitt) (cc = Controller)

Bei Schaltern wird nur 0 bzw. 7F, also 0 und 127 gesendet. Laut Wiki werden bei Schaltern alle Werte von 1-64 und alle von 65 - 127 zusammengefasst und als an/aus interpretiert.


Da der Pitch Fader als 1 Tone/Schalter/Geber sendet seh ich jetz mal die Chance gering, den softwaremäßig auf zwei aufzuteilen, oder? Es scheint bei der Eingabe tatsächlich "Totpunkte" zu geben, zumindest was das Midisignal betrifft. Außerdem sendet es nur bei betätigung, also keine ständige Abfrage. Soll heißen: di höhere Auflösung des Reglers abzufragen dürfte sich schwierig gestalten, wenn der Regler zwischen den Werten nichts sendet!

Hoffentlich kommt noch wer auf die erleuchtende Idee! Kenne mich mit der Materie leider nicht aus...

Edit:

@ Toby: senden alle Controller diese Zwischenauflösung, oder ist das eine mögliche, aber nicht verwendete Technik?

Edit 2: Vl noch interessant ist, dass der Controller bei schneller Bewegung auch Signale überspringt!
 
Zuletzt bearbeitet:
midiox ist bekannt und wird auch genutzt, nur hatte ich keinen Controller "von der Stange" verfügbar um das zu testen, (bzw. wär grad mal gar nicht auf die Idee gekommen dies hiermit zu überprüfen), so hat sich der Thread also schon mal ausgezahlt. :)

Das bei der Abfrage Werte einfach übersprungen werden stellt kein Problem dar. Sobald nen "neuer Wert" vorliegt wird dieser ja übermittelt und anschließend umgesetzt.
Das geht so schnell, da sollte es eigentlich zu keiner spürbaren Latenz kommen.
Bleibt das verschieben in Stufen, aber falls diese halt nur klein genug sind ist das ja nicht weiter tragisch.

Wenn man weiter bei "midi" in der uns bekannten Form bleiben würde müsste man also nach unserer ersten These folgende Dinge ändern:

-HW muss die vom Pitchfader empfangenen Daten, (-> Messungen, Impulse) in 3 (oder mehr) Controllerdatenbereiche aufsplitten (+/-/0)
-senden dieser Werte an Interface (funktioniert bereits)
-SW muss einkommende Interfacedaten interpretieren und umsetzen
(funktioniert in der vorhandenen Weise ebenfalls).

...Also das klingt doch alles nicht schwierig, wieso wurde des bis jetzt noch nicht so umgesetzt. :confused:


@Toby:
Den Ansatz kann ich nicht ganz nachvollziehen, wo sollen diese Zwischenstufen denn her kommen!?
 
Also die These von Toby kann man glaub ich auch aus dem Wiki entnehmen, allerdings steht da, dass diese Möglichkeit der weiteren Signaldaten nicht oft genutzt wird, also nicht von jedem Midi-Controller gesendet wird! Wenn man jetzt eine Lösung für das Pitch "Problem" für gängige Controller finden will, is diese Variante also hinfällig.

@ Pyrolastic: Die Idee mit der Unterteilung ist schon klar, nur wird der Picth Fader ja offenbar als ein Geber gesehen. Wenn der Hardwaremäßig nicht anders geschaltet ist, kann man das mit einer Softwarelösung natürlich nicht ändern! Und da kommen auch die "Toten Punkte" ins Spiel. Wenn zwischen den einzelnen Midi Befehlen nichts ausgegeben wird, welches Signal soll man dann umsetzen?

Lg
 
Du selbst kannst das bei vorhandener Software sowieso nicht ändern, da müssten die Hersteller schon ihren Quellcode offen legen und das wird logischerweise nicht gemacht.

Das ganze der Hardware beizubringen ist kein Problem, bei "Messung" von "x"-Ohm wird einfach jeweils der entsprechende Wert ausgegeben, genau so funzt das jetzt ja auch.
Lässt sich als Endanwender natürlich wieder nicht ändern, aber während der Produktion wär dies kein Problem.
 
Darf ich eine Frage in die Runde werfen?
Ich bin relativ ahnunglos was dieses Thema betrifft, versuche es aber trotzdem:

Wäre es nicht möglich, wenn die betreffende Software / Treiber bei

00060065 1 -- 90 0C 7F 1 C 0 Note On
00060E3E 1 -- 90 0C 00 1 C 0 Note Off

nicht im selben Protokoll weiteragiert, sondern in einem seperatem Protokoll für "+" und "-". Soll heißen: Wird der Fader Richtung "+" oder "-" bewegt, wird lediglich Rechner-intern ein Protokoll gewechselt. Dementsprechend wäre es Möglich, 127 Schreitte für "+" und für "-" zu reservieren.

Mit ein bisschen Überlegung könnte man die Abfrage, nach dem Wechsel der Protokolle, sogar nach Faderverhalten steuern. Bewegt sich der Fader schneller, wird das Protokoll mit den invertierten Pitch-Daten vorgespeichert.
Ist der Fader dann bei Note-On/Off angekommen, wird das Protokoll gewechselt.

Man könnte aber auch jew. den ersten Befehl des Protkolles, als Interpreter für den Protokollwechsel einsetzten. Gleiches gilt für ev. Umschaltung des Protokolles durch einen Midi-Befehl.

Sollte die Idee wertlos sein, bitte verwerfen.

beste Grüße
 
Also ich weiß ned genau wie das Signal jetzt eigentlich am PC ankommt, aber angenommen man schaltet ein Programm dazwischen, das eine höhere Abtastung des Faders erkennt und in sagen wir 2 Midi Befehle mit je 127 Zeilen umwandelt, die entweder bei + oder - aktiviert werden, und man dann auf den Pitch im Traktor eben diese 2 Midi Befehle (also Doppelbelegung) mappt, könnte man so vl schon ein besseres Ergebnis erzielen. Ist eben fraglich ob
1.vom Controller mehr ausgegeben wird und
2. Ein derartiges mapping in normalen DJ Programmen mit Midi Erkennung möglich ist.

--> Ein findiger Mensch entwickelte PPJoy um Steuerbefehle eines 3,5mm Klinken-Mono/Stereo Anschlusses über die Soundkarte aufzunehmen und wieder Umzuwandeln! Nichts ist unmöglich ;)

@ root: hört sich kool an, is mir aber zu hoch :p
nein scherz ohne, das mit 2 Midi befehlen entspricht etwa deinem Ansatz, oder?
 
Soweit ich weiß, ist das Bend-Rad eines Synthies in +-64 Stufen aufgelöst, inkl. 0-Stellung. Jede Stellung hat zudem noch einmal ein Feinauflösung von 128 Steps (ob jetzt über das Rad oder mit einer zweiten Controllernummer, das weiß ich nicht). Damit wären wir bei 128x128 Steps. Das ergibt bei einer +-8% eine Schrittweite von 0,001%. Und das ist mehr als genau.

Der CDJ1000 hat 0,02%, wobei ich aber meistens nur die 0,05% nutze.
 
@ root: hört sich kool an, is mir aber zu hoch :p
nein scherz ohne, das mit 2 Midi befehlen entspricht etwa deinem Ansatz, oder?

Öhm, nein :D
Ich rede von zwei Midi-Protokollen, die je nach belangen Abgerufen werden. Sprich: Für "+" und "-" 128 Schritte. Dem Programm, welches diese interpretiert, wird lediglich "vorgegaukelt", dass es sich nur um 128 Schritte handelt, wobei es in Wirklichkeit 256 sind.

liebe Grüße
 
Ja also wird dem Programm gesagt z.B. bei -100 bis -1% tone 1, bei 0 tone 2 und bei 1-100% tone 3, mit je 127 Befehlen.. oder? :D

vl reden wir aneinander vorbei, vl bin ich auch zu blöd :p
... Oder zu müde, also nacht!
 

Neue Themen


Zurück
Oben