Re: Akai MPC Renaissance
Mal was Technisches zu den geschilderten Problemen:
Eine Hardware-MPC ist eine Kombi aus mindestens 3 Prozessoren: DSP, Haupt-CPU und Bedienfeld-CPU. So jedenfalls isses bei der 2kXL, aber auch den Älteren. Herz ist neben einem Custom-DSP eine CPU NEC V53A. Dabei handelt es sich um eine MCU-Version des V20, der eine reverse-engineering-Version des 8086 darstellte, kompatibel zum 80186 war und einen 8080-Modus enthielt. Auf dem Desktop eher kaum verbreitet, dafür im Embedded-Bereich durchaus häufiger zu finden.
In den aktuellen MPCs steckt, wie auch bei Yamaha und anderen Japanern, eine MCU aus der SuperH-Serie (SH7727), also 32Bit RISC mit DSP drin, 160MHz. USB ist schon drin, beides, aber nur 1.1, Displayport, Speicher komplett extern. Dieses Ding macht alles: DSP, Display, Timer, Ports, Bedienfeld abfragen, Speichermanagement. Das Ganze ist ebenfalls parallel angebunden, weil meist auch intern. Ladezeiten sind da übrigens keine Sache der Rechenleistung, sondern liegen am Design des Speicherinterfaces und der Implementerung von DMA-Mechanismen, die die MCU ja von Haus aus mitbringt. Bissl multitasking im OS hilft da schon, machen ja selbst die einfachsten Digiknipsen heutzutage. Wie gut, daß Yamaha ... äh, lassen wir das.
Kurz: das Ganze ist eine hochoptimierte Hardware-Firmware-Kombination.
Nehmen wir nun die Renaissance. Auch da steckt eine MCU drin, wird was Kleines sein. Hängt per Nabelschnur USB am Rechner, auf dem eine dafür passende Software läuft. Hier fängts schon an: USB ist das Nadelöhr, da muß dann Audio und MIDI drüber, ebenso die Daten, welche Knöppe oder Regler betätigt wurden, und natürlich das Feedback dazu. Auf dem Rechner laufen zig Dienste, USB-Verwaltung ist nur einer davon und hat keine Priorität, nicht zu vergessen die Treiber als Extrainstanz. Das wird dann je nach Auslastung schnell eng und führt zu genau den beschriebenen Effekten. Mit Firewire wäre man da besser gefahren, nur ist das schon wieder auf dem absteigenden Ast und Thunderbolt noch nicht wirklich verbreitet, welches genau für sowas ideal wäre, oder wenigstens USB3.
Firmen wie RME oder MOTU haben für solche zweiteiligen Lösungen mit hohem Datenaufkommen eine direkte Busanbindung mit eigener Schnittstelle gebaut, um nicht in solche Probleme reinzurennen. Eine solche Lösung ist mit der heißen Nadel gestrickt und die geschilderten Probleme wundern mich nicht im Geringsten, das kann so einfach nicht sinnvoll funktionieren, weils keine Reserven hat bzw an der Leistungsgrenze operiert.
Das ist einfach nur was Halbes, was Ganzes wäre eine wirklich dicke MPC, aber wieder mit verteilten Prozessoren für die einzelnen Aufgaben, die sie dann besser und unabhäging voneinander erledigen können. Sicher, heute sind MCUs wirklich sehr leistungsfähig, um auch so ein Ding alleine zu wuppen, aber es gibt viele Gründe für eine Verteilung der Aufgaben, aber offenbar haben hier wieder die Schlipse regiert ...
Daß die MCU auch das Display mit ansteuert (und nicht nur bedient), ist ja auch so eine Sparmaßnahme. Andererseits macht sowas erst eine Displayaufrüstung wie oben beschrieben möglich.
). Da denk doch jeder (der nicht im Bilde ist) gleich das Gerät muss die Krone der MPC-Schöpfung sein. Die heimliche Änderung der Bedeutung der Abkürzung MPC ist ja wohl eindeutig. Das ist für mich Ettikettenschwindel par excelance.
war wohl nichts 
