Experimenteller microcontrollergesteuerter Midi Controller

[goara]

Danke erst mal für die Antworten.
@wkrug habe mal bei Wiki den plan angeschaut, im prinzip brauche ich erst mal nur den out (in und thru vielleicht später wobei thru eigentlich sinnlos ist ?? )
Wozu brauche ich denn den 4049 kann ich das nicht einfach so machen:
Bild hier  
??
Wegen der Rechenpower wollte ich das auf 2 chips verteilen, einen der in echtzeit die Daten sendet, und einer der den Rest erledigt. (mit UART oder I2C verbunden, was eigent sich dafür besser? )
@malthy : danke die Seite ist echt fein, werde da mal ein wenig rumlesen, wo hast du da Schaltüläne gefunden? bin glaub ein Blindfisch
@johns:
Motorfader und Encoder mit statusanzeige wären natürlich fein, das überstiegt aber gerade mein Budget, später viellecht
Wegen der Idee mit dem RS232 hatte ich auch schon überlegt, aber will doch lieber ein "echtes" Midi SIgnal erzeugen, dann ist das auch mit meinen anderen Geräten kompatibel.

[wkrug]

Wegen der Rechenpower wollte ich das auf 2 chips verteilen, einen der in echtzeit die Daten sendet, und einer der den Rest erledigt. (mit UART oder I2C verbunden, was eigent sich dafür besser? )

Wenn der Controller genügend Ausgangsstrom zur Verfügung stellt kann man das natürlich so wie in Deinem Schaltplan machen.
Da man aber für die THRU Buchse ohnehin einen Treiber mit Schmitt Trigger braucht spart man auch nicht wirklich was.
Als Verbindung zwischen den Controllern würde ich SPI verwenden.
Das geht schnell und ist von Atmel auch gut Dokumentiert.
Bei der USART Lösung bräuchtest Du einen Controller der 2 USART's hat, weil Du die MiDi ja vermulich auch über USART laufen lassen willst.
Ich schieb bei den ATMEL AVR Controllern so viele Aufgaben wie möglich und sinnvoll in die Hardware, weil dadurch nur wenig Rechenpower verloren geht.

...in und thru vielleicht später wobei thru eigentlich sinnlos ist ??

Das würd ich so nicht stehen lassen.
Für Deinen speziellen Anwendungsfall könnte das eventuell zutreffen.
Auf dem THRU liegt ein unverzögertes Midi in Signal an.
Beispiel:
Wenn man mehrere MiDi fähige Geräte hat, kann das Erste die MiDi Kanäle 1...8 verarbeiten ( Synthesizer ?! ). Dann geht man aus der THRU Buchse raus in das nächste MiDi fähige Gerät, das dann die Kanäle 9...10 verarbeitet ( Drum Computer ?! ) usw. . So kriegen alle Geräte in der MiDi Kette ihre Befehle zur gleichen Zeit.
Würde man so was über MiDi in / MiDi out lösen, könnte es bei mehreren Geräten hintereinander zu Laufzeitverzögerungen kommen, weil das MiDi in Signal ja erst vom Gerätecontroller verarbeitet werden muß, bevor es wieder auf der MiDi Out Buchse gesendet wird.
Ausserdem kommen aus dem MiDi Out ja auch die Daten raus, die das Gerät selber produziert.

Nur zur Info!:
Will man die Daten von mehreren Geräten wieder zurück auf einen Master bringen, kann man das über einen sogenannten MiDi Merger machen.
Das ist dann wieder ein Kästchen mit einem Controller und mehreren MiDi in Buchsen drin.

[goara]

so.. bin mal wieder dazugekommen ein wenig weiterzumachen... der Plan ist jetzt folgender.. 8 x Atmega16 mit je Display, 2 Joysticks, 4 Pots und 4 Tastern
das ganze wird verbunden über SPI....
aussehen tut es so:
Bild hier  
die einzelnen Platinen lesen die werte ein berechnen das ganze Zeugs und senden es dann an eine weitere Platine, die das Midisignal erzeugt.....
Wird jetzt ein wenig groß das ganze, da die 8 Displays nebeneinandr schon 70cm breit sind, aber das macht ja nichts, neben den plattenspielern is noch Platz