30 Jahre MIDI

[tom f]

es ist abhängig
vom system
dem audiointerface
dem midiinterface
der daw
und imho auch von der auslastung...

und auch wenn man da eine erprobte kombination hat, brauchts noch ein bisschen glück und man kommt auf die +/-1 ms bis gar kein jitter.

ja schon - lediglich habe ich seit mehreren jahren eben das gleiche setup - und "jetzt" funktionierts - obwohl ich nichts geändert habe

wobei ich mit dem innerclock teil nicht zufrieden bin - denn grade die 909 reagiert auf das midiclock signal von dem teil falsch - währende sie bei allen anderen midiclock quellen reibungslos funktioniert..
irgendwas an der intensität des signals muss da anders sein - keine ahnung was (ist mir auch egal wenn ich schon nen batzen geld zahle für so ein spezialgerät)

 

[fanwander]

Die MPCs können MMC, sowohl senden als auch empfangen. Zumindest die 2k XL und Neuere.
Am Besten nimmt man MTC, also MIDI Time Code, der arbeitet mit absoluten Positionen. Akai hat da Hilfeseiten dafür:

habe die besseren erfahrungen mit mpc als slave im timecode mit mmc gemacht = ca.2-3ms andersrum waren es immer zwischen 6-8ms maximal.

Es gibt eine eiserne Regel für MIDI-Clock: Der Port, der Clock transportiert, transportiert keine Noten oder Controller-Daten. Punkt.

(Ausnahme: MIDI-over-USB)

 

[kl~ak]

ja schon klar - bei mir gibts sowieso keine controller daten in oder aus dem rechner. das habe ich alles in der mpc. diese soll einfach nur sauber mitlaufen - oder der rechner - was ist mir eigentlich egal. ist die mpc slave sind es immer (egal ob sampel oder angesteurter synth) 2-4ms "swing" bzw genereller versatz = alle events sind verschoben um diesen betrag und dieser ändert sich auch nicht über die aufnahme. wenn ich eine neue aufnahme starte ist der betrag anders. aber von 20 versuchen sitzen höchtens 3 im 1ms bereich. alle anderen sind 2 oder mehr ms voneinander entfernt - max 4ms wenn mpc slave.

lasst uns das vergessen - das ist ein anderer thread ... und ich bin mit dem thema eigentlich durch. alle midievents in der mpc haben und alles in einem ritt recorden. FX usw dann später abdubben _ fertig - mischen im rechner.

 

[Lothar Lammfromm]

Ich denke schon, dass es Zeit für einen neuen Standard ist. Das MIDI-Protokoll an sich hat sich ja im Wesentlichen überaus bewährt (wobei ich mir z.B. exakte Pitch-Informationen pro Note wünschen würde und eine höhere Auflösung an Stelle von nur 128 Schritten - im Prinzip so, wie es die MMA mit dem High Definition MIDI seit 2013 vorschlägt - zusätzlich würde ich mir allerdings noch ein "Akkord-Protokoll" bzw. eine Erweiterung der Protokollsprache für die Übertragung von Akkorden bzw. Notenbündeln wünschen, ergänzend zur Übertragung von Einzelnoten).

Die Datendurchsatzrate von MIDI ist allerdings ein kleines bis größeres Drama, zumal die heutigen Produktionsgewohnheiten deutlich häufiger als in den 80er Jahren auf stark bewegte und vielfache Parameterbewegungen bei den Klangerzeugern setzen. Das funktioniert mit dem traditionellen MIDI, jedenfalls bei musikalisch noch erträglichen Timing, überhaupt nicht gut.

Spiele ich bei MIDI nur (!) drei komplexe Akkorde zugleich, frei von parallel laufenden Controlerbewegungen u.ä., dann habe ich über MIDI bereits 10 bis 20 ms Versatz (und das ist deutlich hörbar), wo eigentlich Gleichzeitigkeit gefragt wäre. Für exakte Grooves ist MIDI ebenfalls ein Problem, sogar dann wenn man MIDI-Daten gezielt filtert - wenn über die gleiche MIDI-Schnittstelle eine Reihe weiterer Klangerzeuger angesprochen wird. Klar, man kann sich ein wenig behelfen, indem man beispielsweise stark timing-kritische MIDI-Ereignisse (z.B. Drums, Bass-Figuren, Arpeggios usw.) auf jeweils eine separate MIDI-Schnittstelle setzt. Aber eigentlich wäre es doch schon ganz prima, wenn Musiker mit "nur" einer MIDI-Schnittstelle und den dort möglichen 16 Kanälen bereits klar kommen könnten, oder? Der andere Ausweg (vielfach beschritten) ist nämlich leider die Vermeidung von MIDI-Übertragungen zu externen Geräten und z.B. eine rein rechnerinterne, extrem latenzarme Arbeit mit Audio bzw. Software-Klangerzeugern.

Das kann aber doch nicht so ganz das Interesse der Instrumentenbauer sein...?!

Ohne übermäßig Ahnung zu haben (sorry), würde ich mir wünschen, dass der künftige Weg auf Thunderbolt basieren wird, inklusive einen erweiterten HD-MIDI-Protokoll und ggf. (keine Ahnung ob nötig) einem separaten MIDI-Funk-Protokoll. Das wird auch nicht teurer als die bisherige MIDI-Schnittstelle, weil die wesentlichen Komponenten ja sowieso als Massenprodukt auf den MAC- und PC-Markt kommen werden!

Ich denke: Es ist jetzt der richtige Zeitpunkt dafür, diesen Schritt zu gehen.

 

[fanwander]

Man könnte sich seeehr sehr viel TImingProbleme sparen, wenn im Protokoll optional ein Zielzeitpunkt des Events übertragen werden würde. Dann kann man irgendwann vorher die Daten rüberjagen, und der Klangerzeuger wartet auf den entsprechenden Clocktick.

 

[micromoog]

Der Standard MIDI selbst muß viel ausbaden woran er eigentlich nicht immer schuld ist (wurde von microbug ja schon angerissen)

Mein MKS-80 hat ca 10ms interne Latenz, dafür kann der MIDI-Standard nichts.

Disziplin ist das A&O. Wer 32 Spuren quantisiert auf der 1.1.1.1 über einen MIDI-Port raushauen will, hat den gleichen Effekt eines Notausgangs einer brasilianischen Discothek.
Durch das Nadelöhr passen nun mal nicht alle gleichzeitig.
Oft klingt es lebendiger und sogar tighter, wenn man Spuren im 1-3ms Bereich um die 1 verteilt. Ebenso bewusst Timing unkritische Elemente weiter nach vorne oder hinten legen.
Wenn man schon weiß, dass ein Klangerzeuger eine interne Latenz hat, kann man diese Spur entsprechend global vorziehen.

Auch Geräte im Multimode sind oft intern zu langsam.

Man sollte seine Pappenheimer einfach gut kennen, dann gibt es auch weniger MIDI-Frust!

 

[mink99]

Ohne übermäßig Ahnung zu haben (sorry), würde ich mir wünschen, dass der künftige Weg auf Thunderbolt basieren wird, inklusive einen erweiterten HD-MIDI-Protokoll und ggf. (keine Ahnung ob nötig) einem separaten MIDI-Funk-Protokoll. Das wird auch nicht teurer als die bisherige MIDI-Schnittstelle, weil die wesentlichen Komponenten ja sowieso als Massenprodukt auf den MAC- und PC-Markt kommen werden!

Thunderbolt ist wieder nur ein Versuch, die Lampen zu verschenken und das Öl teuer zu verkaufen. In jedem Kabel ist ein teurer Adapter eingebaut. D.h bei 5 Kabeln muss man 5 Adapter bezahlen. Man hätte die Adapter auch auf der anderen Seite des Steckers einbauen können, dann hätte man nur einen gebraucht. Es ist mmn gezielt dafür gebaut worden, teuer zu sein. Der Rechner ist dann 5 Franken billiger, aber jedes Kabel 30 Franken teurer.....

Midi hat natürlich als langsames serielles Protokoll ein Problem

Das MIDI-Protokoll ist ein serielles Datenprotokoll, das bedeutet, alle Daten werden hintereinander erzeugt und gelesen. Die Datenrate für MIDI-Leitungsverbindungen ist auf 31250 Baud (Bits/sec) festgelegt, ein Datenwort benötigt also 0,256 ms Übertragungszeit. Das führt zu Problemen, wenn zum Beispiel gleichzeitig viele Tasten angeschlagen werden. Für 6 gleichzeitig angeschlagene Tasten vergehen zwischen dem vollständigen Eintreffen des ersten und des letzten MIDI-Ereignisses 5 Tasten * 3 Datenwörter * 0,256 ms = 3,84 ms.

Durch parallelisieren und entsprechende latenzkompensation lässt sich vieles ausgleichen. Das jitter Problem ist aber kein Problem des Protokolls, sondern der Implementation. Sauberes timestamping im Treiber und Interface sollte die Probleme eigentlich ausreichend minimieren. Das was Florian vorgeschlagen hat, gibt es bereits in einigen Treibern und Interfaces, aber nicht in allen....

 

[mink99]

Nachtrag :

Sowas wäre als Tunneling protokoll vielleicht sinnvoll:

http://de.wikipedia.org/wiki/Synchron-S ... nittstelle


http://www.posital.sg/sg/products/POSIT ... ppNote.pdf

 

[Moogulator]

wer Lust hat, kann den alten Thread MIDI 2 mal lesen, es gibt da auch Einsichten über Möglichkeiten und Träumen und auch das mit der Geschwindigkeiten.
Die Hardware ist lt. Dave ja damals einfach lahm gewesen, und die Optokoppler sind cool gegen Brummschleifen.

 

[kl~ak]

gint es das "midiproblem" eigentlich auch intern - also im rechner zwischen sequencerprogramm mit aufgezeichneten cc und vst´- synths ???

(meine jetzt nicht audiolatenz)


kenne mich da nicht so aus, da ich zu selten damit arbeite ...

 

[mink99]

Jein, intern im Rechner kann man die midi und audiolatenz nicht wirklich voneinander trennen. Da hier aber eine kontrollierte Umgebung vorliegt, kann eine daw das häufig ausgleichen, indem es die midi Informationen je nach Plugin nach vorne zieht.

 

[ps4074iclr]

Man könnte sich seeehr sehr viel TImingProbleme sparen, wenn im Protokoll optional ein Zielzeitpunkt des Events übertragen werden würde. Dann kann man irgendwann vorher die Daten rüberjagen, und der Klangerzeuger wartet auf den entsprechenden Clocktick.

Dann bräuchte aber jeder Klangerzeuger mit MIDI Eingang auch einen internen Sequencer, der die empfangenen Events zum richtigen Zeitpunkt ausführt. Wahrscheinlich bräuchte man auch noch ne Datenrückroute, damit der Klangerzeuger bescheid sagen kann, wenn sein Buffer voll ist, und er die empfangenen MIDI Events verwerfen muss.

Was hats eigentlich mit diesem TurboMIDI von Elektron auf sich? Gibts noch andere Hersteller, die das nutzen?

 

[mink99]

Man könnte sich seeehr sehr viel TImingProbleme sparen, wenn im Protokoll optional ein Zielzeitpunkt des Events übertragen werden würde. Dann kann man irgendwann vorher die Daten rüberjagen, und der Klangerzeuger wartet auf den entsprechenden Clocktick.

Dann bräuchte aber jeder Klangerzeuger mit MIDI Eingang auch einen internen Sequencer, der die empfangenen Events zum richtigen Zeitpunkt ausführt. Wahrscheinlich bräuchte man auch noch ne Datenrückroute, damit der Klangerzeuger bescheid sagen kann, wenn sein Buffer voll ist, und er die empfangenen MIDI Events verwerfen muss.

Ansich braucht es das nicht, solange das Interface und der treiber timestamping unterstützt und die Latenz des Tonerzeugers stabil und gleichbleibend (real time) ist. Dann muss das Interface die Latenz lediglich kennen und entsprechend kompensieren.

 

[TK]

Hat eigentlich schonmal jemand in Erwaegung gezogen, AES bzw. S/PDIF als Interface fuer MIDI Daten zu missbrauchen?

Vorteile:
- etabliertes Interface, superbillige Kabel, Adaption an Mikrocontroller bspw. moeglich ueber einen S/PDIF<->I2S Konverter chip
- optional galvanische Trennung durch Lichtwellenleiter - im Gegensatz zu USB bekommt man die also fast geschenkt
- Transferrate bis zu 375kb/s, somit 120 mal schneller als das "traditionelle" MIDI Interface
- Isochrones Protokoll, somit garantiertes Timing
- auf der PC/Mac Seite koennte man eine Soundkarte aus dem naechstgelegenen Mediamarkt zur Ein/Ausgabe verwenden
- einen passenden Treiber vorrausgesetzt, koennte man in der DAW den MIDI Stream zeitgleich mit den Audio Streams verarbeiten und ausgeben

Hm, vielleicht kommt die Idee auch einfach 20 Jahre zu spaet.
Waere es in den 90er Jahren verfuegbar gewesen, haette man MIDI in digitaler Form noch mit einem DAT Recorder aufnehmen koennen (die gibts glaube ich heutzutage auch nicht mehr )

Gruss, Thorsten.

 

[tom f]

soooo untight und scheisse wie hier teilweise getan wird ist midi auch nicht - immerhin wurden damit (ich nehem mal an) "millionen" songs produziert - von denen sicher zig hunderttausende zu erfolg und geld gedient haben

und seit dem es hd-recording gibt ist so ein versatz auch keine tragik - denn "nudgen" ist doch seit der bandmaschinen-zeit eine "der" tätigkeiten die in studios von wichtigkeit ist - da ist heute so ne zoomfahrt und eine kleines zurechtrücken echt keine thema

mfg

 

[kl~ak]

geht schon los - im moog thread drüber gestolpert und gleich für gut befunden hat mich mal interessiert, ob sich das für ich lohnen würde ...

http://www.musikhaus-korn.de/de/Ableton ... tAodnwUA-w

natürlich keine midibuchse mehr dran .... nur noch usb



können die sich auch vorstellen, dass irgendjemand einfach nur musik machen möchte ohne informatikstudium


-> ich seh es schon vor mir _ interuptbelegung von usb ports zuweisen :kotz:

 

[tom f]

natürlich keine midibuchse mehr dran .... nur noch usb



können die sich auch vorstellen, dass irgendjemand einfach nur musik machen möchte ohne informatikstudium


-> ich seh es schon vor mir _ interuptbelegung von usb ports zuweisen :kotz:

naja - gibti doch scjon einiges was keine midibuchsen mehr hat ... (nicht dass ich das gut fände)
selbst das launchpad hat nur usb

die zeit bleibt eben nicht stehen

 

[kl~ak]

ich pfeif auf die zeit wenn das bedeutet, dass ich n rechner als inspirationskiller hochfahren muss um meinen synthesizer spielen zu können.


die zeit kann mich mach zickzack mit mittenschlingel, wenn das bedeutet, dass man heutzutage mit seinem telefon die bude rockt - da muss ich kotzen


sorry _ _ aber ich find das echt daneben - sich des standarts bedienen - diesen nicht verbessern und dabei noch die kommunikationstellen zu den geräten, die den standart etabliert haben wegrationalisieren = na hauptsache es ist nicht höher als ein macbook


nochmal sorry

 

[Neonlicht]

ich pfeif auf die zeit wenn das bedeutet, dass ich n rechner als inspirationskiller hochfahren muss um meinen synthesizer spielen zu können.


die zeit kann mich mach zickzack mit mittenschlingel, wenn das bedeutet, dass man heutzutage mit seinem telefon die bude rockt - da muss ich kotzen

ZACK! So einfach ist das.

 

[Anonymous]

Möchte hier nur kurz anmerken, bezüglich der 0..127 Velocityrange: Solange die Inputsensoren diesen Bereich nicht ordentlich nutzen können, braucht man auch den Range nicht erweitern. Oft werden von diesen 127 Werten (0 entspricht ja, Lautstärke = 0, da keine Note) nur ein kleinerer Bereich genutzt, in der Praxis. Spielt mal auf Eurem Keyboard und plottet die Velocity als y-Achse auf, x-Achse könnte pitch sein. Nur die Velocity mit einem Skalar multiplizieren oder teilen bringt auch nicht viel, da die Inputrange sich damit nicht ändert. Andererseits solange Synths auch nicht entsprechend dynamisch auf Velocityschwankungen reagieren, ist es auch nicht so schlimm, keinen scheint das zu stören. Deshalb noch die abschließende Frage unten:

Welche Synthesizer reagieren besonders empfindlich auf Velocityschwankungen?

 

[micromoog]

das ist alles überhypt mit der angeblich schlechten Vel.-Auflösung

Meißt schimpfen die User anschlagdynamikloser Monosynths am meißten über die Velocity-Auflösung

 

[Anonymous]

Solange die Inputsensoren diesen Bereich nicht ordentlich nutzen können, braucht man auch den Range nicht erweitern.

Bislang vermute ich ja, die besten Velocitysensoren sind wohl wirklich einfach Mikrofone, die Laufstärke der Berührung aufzeichnen, d.h. bei einem Keyboard mit 61 Tasten, bräuchten wir 61 eingebaute kleine Mikrophone, 1 Mikrophon/Taste. Noch einen Berührungssensor könnte/müsste man parallel dazu schalten, um auch sehr leichte Berührungen erkennen zu können, die Mikrophone würden ja auch die Nebentasten registrieren. Jede Taste würde dann so reagieren:

if (Berührungssensor hat getriggert)
{
    Mikrophoninput messen
    Lautstärke in Velocity umwandeln
}

Unsere natürliche Hörerfahrung würde somit auf Velocity umgesetzt werden. Wäre das zu teuer? Keine Ahnung, vermutlich nicht, da man einfachste kleine Billigstmikrophone nehmen kann, sie sollen ja nichts schön aufnehmen, nur möglichst gut Lautstärkeunterschiede messen können. Dann könnte ein Trommler auch auf den Tasten trommeln, die 127 Velocitywerte würden aber so wirklich voll genutzt werden!

 

[TK]

Bei den gaengigen Tastaturen wird die Velocity durch Zeitmessung ermittelt. Die Genauigkeit haengt im Wesentlichen davon ab, wie schnell die Tasten durchgescannt werden. Mit einem schnellen Microcontroller sind durchaus 10..12 bit machbar. Der kostet dann halt 2..3 $ mehr, doch hier sparen die Hersteller wohl zu gerne.

Gruss, Thorsten.

 

[kl~ak]

das ist alles überhypt mit der angeblich schlechten Vel.-Auflösung

Meißt schimpfen die User anschlagdynamikloser Monosynths am meißten über die Velocity-Auflösung

ich weiß jetzt nicht mehr genau wo im thread die 127tel frage aufgeworfen wurde - aber ich glaube es geht dabei allgemein um die auflösung. vel. ist da eher nebensächlich - das ist schon richtig - aber gerade bei analogen monosynths merkst du deutlich was 127tel bedeuten kann. vor allem wenn die noch sehr eng im swepspot sind. dreh mal bei nem pulse die reso auf und moduliere dei cutoff mit nem wheel -> das gleiche gilt übrigens meiner erinnerung nach auch für die XT = was wiederum bedeutet, dass man das softwaretechnisch dort auch vergessen hat. natürlich gibt es auch geräte intern die das abglätten - aber wenn man mal anfängt analoge technik mit mididaten zu befeuern merkt man sehr schnell, dass man in jedem datenstrom gerne einen slewlimiter hätte ... ist der zb von doepfer ist damit ein glide/pitcheffekt nicht mehr machbar, da der die skale versaut.... (aber die neuen slews sollen das nicht mehr haben!) schnell wünscht man sich dann mehr als 127tel...

sicherlich hören die wenigsten 1/127tel laustärkeschwankung herraus


am ende ist das jammern auf hoher nivea = allein eine gemeinsame weiteretnwicklung von verschiedenen herstellern an einem gemeinsamen abwärtskompatiblen standart wäre in allen bereichen sehr sinnvoll. mich würden zb auch fehlende midibuchsen nicht mehr stören, wenn es kabel gibt die usb-midi sind und man damit zb mit dem oben geposteten "push" ganz normal in einen juno60 gehen kann. ob das sinn macht oder nicht sei doch bitte dem user überlassen.

 

[Anonymous]

Jetzt bräuchten wir nur noch eine Untersuchung der Eigenschaften, Zeitmessung gegen Lautstärkemessung. Lautstärke versteht der Mensch halt sofort, wenn er sehr leise spielt, soll auch das Ergebnis leise sein. Zeit hat erst mal keinen Bezug zur Lautstärke. Da kann man dann viel falsch machen, hätte ich jetzt behauptet. Wenn jemand aber sagt, ich möchte diesen Ton leise haben, wie leise fragt der andere, so leise, und er kann irgendwo draufklopfen, die Lautstärke die man hört, sollte dann input sein. Immer im Verhältnis zur Maximallautstärke an dieser Klopfstelle, ein Holz, oder ein Blech, oder irgendein Material klingt halt insgesamt immer unterschiedlich laut, vor allem soll ja nicht die Lautstärke über die Luft zählen, sondern direkt über den Kontakt zum "internen Mikrophon", das müsste man auch entsprechend berücksichtigen.

Da kann eigentlich jeder selbst schon experimentieren, einfach am Laptop den eingebauten Mikrophon nutzen, am Laptop herumklopfen und schauen wie die Lautstärke variiert. Reaper hat ja z.B. einen nützlichen Audio to Midivelocitywandler schon eingebaut, nennt sich "drumtrigger" js Effekt.

Dann diese Velocityempfindlichkeit mit der eigenen Keyboardvariante vergleichen, nur eine Taste nutzen, versuchen so variabel wie möglich darauf zu klopfen. Ergebnisse messen. Vielleicht irgendwo posten? Ich hätte hier gerade nur als Beispiel vier verschiedene Inputsensoren im Vergleich:

1. Hammermechanik-Digitalpiano
2. Korg nanopad 2 Pads
3. Akai LPD8 Pads
4. Laptopklopfen über das eingebaute Mikro, gewandelt über Reaper, drumtrigger nach Velocity
5. Irgendein Synthesizer mit normalen non-Hammermechanik-Tasten (gerade nicht hier)

Wer hat dann in welchem Maße die Nase vorn, wäre die interessante Fragestellung? Ich würde auf folgendes Ergebnis tippen:

1. Laptopklopfen
2. Hammermechanik-Digitalpiano
3. Korg nanopad 2 Pads
4. Akai LPD8 Pads
5. Irgendein Synthesizer mit normalen non-Hammermechanik-Tasten

QuNexus soll ja anscheinend etwas besser sein in Bezug auf Inputsensoren, ich würde die dann auf Platz 3, über Korg nanopad 2 Pads einschätzen, aber immer noch nach Hammermechanik-Digitalpiano, bin auch gespannt darauf. http://www.keithmcmillen.com/qunexus/overview

Auch die Kostenfrage: Wieviel würde so ein Billigstmikro kosten? Sowas wie in den Laptops vielleicht, wenn das Ergebnis tatsächlich wie oben aufgelistet sein sollte.

 

[TK]

Wie moechtest Du das Uebersprechen zwischen den Mikrofonen verhindern?
Und wie schauts mit externen Stoergerauschen aus (bspw. Monitorlautsprecher direkt neben dem Keyboard)?

Gruss, Thorsten.

 

[Anonymous]

Wie moechtest Du das Uebersprechen zwischen den Mikrofonen verhindern?
Und wie schauts mit externen Stoergerauschen aus (bspw. Monitorlautsprecher direkt neben dem Keyboard)?

Hmm, alles gute Fragen, die Lautstärke über den direkten Kontakt möglichst messen, nicht über die Luft. Irgendwie sollte das möglich sein. Zur Not evtl. ein Minimalgatefeature einbauen. Kann man ja am Laptopmicro testen, wenn Deine Monitore laufen, triggert drumtrigger immer noch bei Reaper?

 

[microbug]

Bei den gaengigen Tastaturen wird die Velocity durch Zeitmessung ermittelt. Die Genauigkeit haengt im Wesentlichen davon ab, wie schnell die Tasten durchgescannt werden. Mit einem schnellen Microcontroller sind durchaus 10..12 bit machbar. Der kostet dann halt 2..3 $ mehr, doch hier sparen die Hersteller wohl zu gerne.

Komm drauf an, ob der Hersteller überhaupt einen eigenen Tastaturprozessor vorsieht oder nicht. Wenn ja, sind's meistens sehr schnelle 8/16bitter, wenns der Hauptprozessor mit erledigt, so ist der heutzutage sowieso fast immer eine 32Bit RISC MCU. Bei den Japanern wird gerne die H8 genommen, während die Amerikaner eher Motorola bzw Freescale bevorzugen, die Europäer eher alles Mögliche. Novation zB hat H8 drin, Waldorf dagegen Freescale, Andere wiederum setzen auf moderne Versionen des 8051, zB bei Moog in den Phattys. Sparen muß man da heute wirklich nicht mehr, bei manchen wundere ich mich nur über die seltsame Wahl der Prozessoren.

Roland ließ sich ein Gatearray für die Tastaturabfrage bauen, bei Doepfer gabs den E510 dafür, bei GEM war's ebenfalls ein ASIC. In den 80ern findet man als Tastaturprozessor sehr oft Maskenprogrammierte 8049, zB Pro One und den analogen Korgs.

Die Art der Matrix hat sich auch inzwischen geändert. Benutzte man in den 80ern noch einen Umschalter zwischen zwei Sammelschienen als Tastenkontakt, so gibt's inzwischen fast überall nur noch 2 zeitversetzte Schließkontakte. Warum? Die kann man nämlich als Gummikohlekontakte billig herstellen, der Umschalter zwischen den Sammelschienen dagegen ist nur rein mechanisch ausführbar. Demnach müßten die aktuellen Yamaha Motifs, deren Tastaturen die gleiche Kontaktmechanik drinhaben wie der DX7II, auch wieder de Matrix mit der Sammelschiene nutzen.

BTW, wo ich Dich gerade lese: gibt's bei MIDIBox ein Projekt mit Tastatursteuerung?

Ensoniq hatte bei einigen Synths eine kapazitiv arbeitende Tastatur drin, da habe ich leider keine Details dazu vorliegen.

 

[TK]

Danke fuer die interessanten Infos!

BTW, wo ich Dich gerade lese: gibt's bei MIDIBox ein Projekt mit Tastatursteuerung?

Ja; und die MIDIbox KB unterstuetzt auch die von Dir genannten Tastaturtypen
http://www.ucapps.de/midibox_kb.html

Gruss, Thorsten.

 

[Frank]

Die Krawatte Aber irgendwie cool leger der Typ