Bitte poste mal den Schaltplan, wie Du die LEDs angeschlossen hast. Dazu kommt, das der Arduino (ich vermute mal ein Mega) auch nur einen maximalen Strom liefern kann. Wie groß sind denn die Widerstände die Du vor den LEDs hast? Der maximale Strom pro Port (A,B,CD..) ist auch begrenzt. Zusätzlich auch noch der Strom der gesamt über GND fliessen darf. Wenn keine LED mehr richtig leuchtet klingt das ein wenig so, als würde die gelieferte Spannung zusammenbrechen.

Bezüglich Vixen und Arduino findet sich eine Menge nützliches im Netz.
Z.B. http://doityourselfchristmas.com/forums/showthread.php?12757-Vixen-Generic-Serial-Output-controls-the-Arduino!&p=129693#post129693
Vermutlich ist das schon die Lösung für Dein Problem :-)
btw. das war der erste Treffer in  Google bei der Suche nach "Arduino + Vixen", odrt gab es einen entsprechenden Link.

Wenn ich das richtig verstehe, willst Du eigentlich mit Deinem PC die 10 LEDs steuern. Der Ardiuino ist nur "Mittel zum Zweck", weil da die LEDs angeklemmt werden können und Du sie über einen Sketch einzeln steuern kannst.
Wenn das so ist, sollte es doch nicht sonderlich schwer sein.
Auf der einen Seite hast Du den PC, der über USB mit dem Arduino verbunden ist. Das Programm "Vixen" (ich vermute mal das hier: http://www.vixenlights.com/downloads.html) liefrt über das "Generic serial" output plugin die Daten an den Arduino. Der liest einfach was da kommt und schaltet entsprechend die LEDs. 6 Davon kannt Du sogar per PWM dimmen, ansonsten kann Du bis zu 18 LEDs direkt ansteuern. PIN 0  und 1 sind durch die serielle Verbindung belegt, der Rest kann komplett verwendet werden, inkl. der 6 analog-Pins.

Die größte Schwierigkeit ist vermutlich, das Daten-Protokoll Deines Steuerprogramms zu bekommen, dmait Du weisst was da über die serielle Schnittstelle geschickt wird.
Mario.

Es wäre gut, wenn Du erstmal beschreibst, was genau Du machen willst. LEDs mit einer Musik zu synchronisieren kann ja bedeuten, das Du anhand der Töne bestimmte LEDs schalten willst. Es kann aber auch bedeuten, das Du die LEDs zu festgelegten Zeiten schalten willst.
Letzteres ist sicher deutlich einfacher.

Was genau hat den mit dem Code aus dem Forums-Post nicht so funktioniert? Oder, genauer ... Was hat der Code gemacht und was hast Du erwartet.
In einem früheren Post hast Du mal geschrieben, das Du einen Arduino Mega 2560 hast. Konntest Du den nicht zum Testen nehmen, bevor Dein neues Board angekommen ist?
Mario.

Kurze Frage, soll der Arduino nur für den Controller herhalten, oder soll das ganze Spiel darauf laufen?
Wenn das Spiel z.B. auf einem Rechner in Processing gemacht wird, und der Arduino nur zur Steuerung dient, kannst Du noch einen Bluethooth-Adapter verwenden um die Controllerdaten drahtlos zu übertragen.

Hast Du schon mal ein anderes Beispiel versucht? Z.B. Die Arduino SD-Lib? http://arduino.cc/en/Reference/SD
Zu Deinem Sketch:

1) Dort steht was von

Code:

// define the pin that powers up the SD card
#define MEM_PW 8

Laut Datenblatt verwendet Dein Shield aber nur die Pin 10-13.

2) Dein Sketch wartet erstmal auf eine Eingabe über die serielle Schnittstelle, ehe er etwas tut. Hast Du denn mal die Zeichen "W" oder "T" über die serielle Verbindung an den Arduino geschickt, wenn das Programm läuft?

Das denke ich auch, da Du ja wie es scheint auch jede LED einzeln ansteuern willst. Dazu reichen die 12 TLCs ja genau aus.
Nur noch eine Frage, willst Du die LED Matrix selsbt bauen? Die zu kaufenden LED-Matrizen sind ja im normalerweise für Multiplexing ausgelegt und haben nicht für jede LED einzelne Anschlüsse.

Die einzelnen Lampen werden parallel an die Spannungsquelle angeschlossen. Die Anodenseite der LED-Lampen an +12V des Netzteils, die Kathodenseite der LEDs jeweils an den Collector-Anschluss des TIP120. Der Emitter-Anschluss des TIP120 geht an Masse und über einen 1kOhm Widerstand wird der Basis-Anschluss des TIP120 an den Ausgang des Arduino angeschlossen. Wenn Du den Arduino über die gleiche Spannungsquelle wie die Lampen betreibst, wars das schon, hat der Arduino eine eigene Spannungsversorgung, mußt Du noch die beiden Massen verbinden, sonst funktioniet das Ganze nicht.
Hier nochmal ein Beispiel für den TIP120:
http://ctheds.files.wordpress.com/2007/10/tip120.jpg

Gar kein so schlechtes Angebot für eine Einsteiger-Set. Auch wenn nochmal 19% Einfuhrsteuer drauf kommen sind es knapp 35 Euro.

Zur Programmierung findest Du hier eine gute Einführung:
http://www.freeduino.de/books/arduino-programmier-handbuch
Als PDF auch hier: http://www.netzmafia.de/skripten/hardware/Arduino/Arduino_Programmierhandbuch.pdf
Ansonsten bietet http://arduino.cc/playground/ schon jede Menge Tutorials und Hinweise zur Programmierung und zum Verwenden jeder Art von Hardware am Arduino.

Gibt's auch zum drehen:
http://www.reichelt.de/6mm-Potis-stereo/RK27112MC-LIN10K/index.html?;ACTION=3;LA=444;GROUP=B254;GROUPID=3136;ARTICLE=73907;START=0;SORT=artnr;OFFSET=500

Wie wäre es mit sowas:
http://www.reichelt.de/Schiebepotis/RSA0N11M9-LIN10K/index.html?;ACTION=3;LA=444;GROUP=B28;GROUPID=3713;ARTICLE=73884;START=0;SORT=artnr;OFFSET=500
Ist halt zum schieben, nicht zum drehen. Aber zumindest motorisiert.

Ok, die Gefahr besteht doch nicht. Leider ist das aus der Beschreibung unter http://arduino.cc/en/Reference/PulseIn nicht wirklich ersichtlich.
Im Code selbst sieht man das aber:

Code:

        // convert the timeout from microseconds to a number of times through
        // the initial loop; it takes 16 clock cycles per iteration.
        unsigned long numloops = 0;
        unsigned long maxloops = microsecondsToClockCycles(timeout) / 16;

        // wait for any previous pulse to end
        while ((*portInputRegister(port) & bit) == stateMask)
                if (numloops++ == maxloops)
                        return 0;

        // wait for the pulse to start
        while ((*portInputRegister(port) & bit) != stateMask)
                if (numloops++ == maxloops)
                        return 0;

        // wait for the pulse to stop
        while ((*portInputRegister(port) & bit) == stateMask) {
                if (numloops++ == maxloops)
                        return 0;
                width++;
        }

        // convert the reading to microseconds. The loop has been determined
        // to be 20 clock cycles long and have about 16 clocks between the edge
        // and the start of the loop. There will be some error introduced by
        // the interrupt handlers.
        return clockCyclesToMicroseconds(width * 21 + 16);

Es wird also erst gewartet, bis ein gerade laufender Puls beendet ist, um dann den nächsten vollständigen zu messen.
Spannend ist auch, das die Funktion nicht mit Zeiten arbeitet, sonder anhand der verbrauchten Taktzyklen die Zeit berechnet. Damit ist die Funktion sehr genau.
Offensichtlich kann man die Genauigkeit noch ein wenig steigern, wenn man vor dem Aufruf noch die Interrupts verbietet. Damit sollte man aber vorsichtig sein, da damit diverse Sachen wie z.b. Timer nicht weitergezählt werden. Jenachdem wie lang die gemessenen Pulse sind, kann man sich hier die nächsten Fallen bauen :-)

Besteht bei pulseIn() nicht die Schwierigkeit, erstmal den "Gegenteiligen" Zustand am Pin zu treffen?
Also wenn ich z.b. die Dauer eines HIGH-Impulses messen will, sollte ich pulseIn() aufrufen, wenn gerade LOW am Pin anliegt, damit die Funktion den Anfang des HIGH-Impulses nicht verpasst.
Rufe ich pulseIn() einfach ohne Prüfung auf, kann es ja sein, das mein Pin gerade HIGH ist (irgendwie klingt das komisch, wenn ein Pin HIGH ist  ) und es wird ein zu kurzer Impuls gemessen.

Also die time-Lib macht auch nichts anderes als intern die Sekunden zu zählen. Dabei wird bei jedem Aufruf von "time_t now()" der aktuelle millis()-Wert verwendet, um die seit dem letzten Aufruf vergangenen Sekunden zu zählen und die Zeit zu aktualisieren. Da hier immer auf glatte 1000er geprüft wird, kannst Du schon an dieser Stelle mit einem Fehler von einer Sekunde (genauer 0,999 Sekunden) rechnen. Dieser Fehler ist aber konstant und summiert sich nicht auf.
Sowohl die time-Lib als auch Dein Code verwendet recht häufig die Funktion millis(), was im Prinzip auch nicht schlimm ist. Das hat aber auch Auswirkungen, denn die Werte die von millis() und micros() zurückgeliefert werden, werden intern über timer-interrupts gezählt.
Die Funktion millis() sieht aber vom Code wiefolgt aus:

Code:

unsigned long millis()
{
        unsigned long m;
        uint8_t oldSREG = SREG;

        // disable interrupts while we read timer0_millis or we might get an
        // inconsistent value (e.g. in the middle of a write to timer0_millis)
        cli();
        m = timer0_millis;
        SREG = oldSREG;

        return m;
}

Man sieht, das vor dem Kopieren des Wertes von timer0_millis die Interrupts abgeschaltet werden und danach wieder angeschaltet. Während dieser, zugegeben, recht kurzen Zeitspanne werden keine Interrupts mehr verarbeitet. Es kann also durchaus vorkommen, das ein "Zählimpuls" des Timers verpasst wird. Je häufiger millis() verwendet wird, desto größer ist die Wahrscheinlichkeit, das sowas passiert.
"delay()" verwendet intern übrigens aus micros() zum "zählen", es hilft also auch nix, mit einem großen delay() die Zahl der millis() aufrufe "pro Tag" zu reduzieren.
Um das Ganze zu testen, wäre es z.B. möglich, einfach nur "dumme", geschachtelte Zählschleifen zu Verzögerung zu verwenden, die die keinen Einfluss auf die timer-Interrupts haben.
Also
1) Zeit syncen und einmal ausgeben (millis() Wert merken)
2) Zählschleifen, die 10 Stunden o.ä. beschäftigt sind laufen lassen
3) millis() Wert erneut merken und ausgeben
4) gemessenen millis() Wert mit aktueller Zeit vergleichen.
Ist die Abweichung geringer, dann hast Du Deine Fehlerquelle.