Probiere mal sowas:
for(int i=0;i<2;i++){
for(int j=0;j<32;j++){
YXPaint(j,Reihe-i,YXColor(j, Reihe-2-i));
YXPaint(j, Reihe-2,CRGB::Black);
}}
void YXPaint(uint8_t x,uint8_t y, CRGB Farbe){
...
leds[pix] = Farbe;
}
Wieder ohne Gewähr 
Gleich muss erstmal Löten Die Ausgänge der Matrix noch beschalten damit ich dann was sehe
CRGB ist eine Struktur. Du musst dann schon einen Member der Struktur zurückgeben z.B. leds[pix].red oder statt uint32_t den Typen CRGB als Rückgabewert verwenden.
Ja leider, den kann ich so nicht gebrauchen. Bin auch noch nicht fündig geworden wie ich das anstelle.
Allgemein...
Mit meinem Test ob ich nun 6 mal 256 oder 3 mal 512 Pixel ansteuere bin ich etwas weiter. 3 mal 512 verzögert etwas die Ausgabe
Das wird sichtbar bei dieser for next....
for(int j=0;j<64;j++){
if(j<32){
YXPaint(j, i, 0x060604);YXPaint(j, i-1,0x100910);
LedBlock[block].show();
}else{
YXPaint(j-32, i, 0);YXPaint(j-32, i-1, 0);
LedBlock[block].show();
}
}
Die Darstellung ist dann sichtbar langsamer.
Also 6 mal 256 Pixel.
Werde mal versuchen ein Video so zu sammenzustellen wo es dann erkennbar wird.
Nun ?? woher nehme ich noch einen Ausgabe PIN ?
Hast Du schon 1 * 512 und 4 * 256 probiert?
Was ist eigentlich an "LED Level 1-10" dran?
Nein habe ich nicht. Aber schöner Gedankengang 
Nach der Aufnahme des jetztzustandes Laufzeit unten werde ich mal umstecken.
Oben 512 Pixel der Rest dann auf 256 würde bei dem Teris ja nichts ausnmachen da ja die Fallzeiten nur im (Speedfall) auf 3 mSec gesetzt sind. die anderen Zeiten sind ja Levelabhängig von 850 bis 150
Da dachte ich die Adressierbaren WS2812 RGB LED, PTH, 5mm einzusetzen.
Wie wäre es dann mit 5 * 256 und 1 * 266 Pixeln? Technisch sind die doch gleich.
Ja genau nur im Prog wäre das etwas anders zu behandeln.
Etwas Flexibilität ist halt notwendig 
Hast Du "Managing your own output", siehe #139, probiert oder im Einsatz? Beide Beispiele funktionieren bei mir mit der aktuellen FastLED-Version, auch mit unterschiedlich langen Streifen:
#include "FastLED.h"
#define NUM_LEDS_A 40
#define NUM_LEDS_B 50
#define NUM_STRIPS 2
CRGB leds_A[NUM_LEDS_A];
CRGB leds_B[NUM_LEDS_B];
uint8_t gBrightness = 128;
void setup() {
FastLED.addLeds<WS2812,22>(leds_A, NUM_LEDS_A);
FastLED.addLeds<WS2812,23>(leds_B, NUM_LEDS_B);
delay(3000);
}
void loop() {
// draw led data for the first strand into leds
fill_solid(leds_A, NUM_LEDS_A, CRGB::Red);
FastLED[0].showLeds(gBrightness);
// draw led data for the second strand into leds
fill_solid(leds_B, NUM_LEDS_B, CRGB::Green);
FastLED[1].showLeds(gBrightness);
delay(5000);
// draw led data for the first strand into leds
fill_solid(leds_A, NUM_LEDS_A, CRGB::White);
FastLED[0].showLeds(gBrightness);
// draw led data for the second strand into leds
fill_solid(leds_B, NUM_LEDS_B, CRGB::Blue);
FastLED[1].showLeds(gBrightness);
delay(5000);
}
Das zweite Beispiel sollte einfach zu implementieren sein und die Anzeige beschleunigen.
Ja das habe ich alles angeschaut und probiert. Bei FastLed scheiter ich nur an die Umrechnung CRGB zu uint32_t.
Ich habe zwar in NeoPixel das gefunden bin aber noch nicht zum Testern gekommen.
static uint32_t Color(uint8_t r, uint8_t g, uint8_t b) {
return ((uint32_t)r << 16) | ((uint32_t)g << 8) | b;
}
Da muss ich noch schauen wie ich das umsetze, denn von diesen Sequenzen
YXPaint(j,Reihe-i,YXColor(j, Reihe-2-i));
Habe ich ja einige und das alles wegen Fast Led umbauen 
Da gehen mit etwas die Nackenhare hoch. Ach wenn die Berechnung mit 1536 Pixeln wesentlich einfacher ist als mit den Geteilten. Dann noch 512 Pixel mit Show...Was ist dann erst mit 1536 Pixeln ? @uwefed hat sich ja noch nicht
geäußert.
Dann bleib einfach bei der Adafruit-Bibliothek, ist doch auch ganz gut.
Hier mal der Unterschied zwischen 256 Pixel und 512
1 Video ab Min 1:45 wie der helle Streifen unten trennt.
Dann wie der Lauf jetzt mit 512 Pixeln ist
Habe ich jetzt so angeschlossen Passt sitzt wackelt und hat Luft 
Gleich auf der ersten Matrix. Da ist es ja nicht so sonderlich mit den Pixelaufbauten.
Oh Heute ist der Adapter für die SD Karten gekommen. Jezt kann es an den Sound gehen.
Ich hatte zwar mal sowas liegen aber wozu hat man Kid´s im Haus 
. Da war ich dann gleich zur Metro und... 24 Euronen sollte das dann kosten und für schnell war mir das dann doch zu Heftig im Preis und warten war angesagt. Demnächst also mit Sound.
Dann mal schauen was der DFPlayer so verbraucht. 3Watt Ausgangsleistung müssen ja irgendwo herkommen.
So Sound ist zu Teil drinnen. 
DFPlayer ist merkwürdig. Mit 3,3V nur bis Lautstärke 8 betreibbar. Knattern im Lautsprecher.
3,3V 1A standen zur Verfügung. Auf 5V gewechselt und ab da keine Probleme mehr.
Dann habe ich den Strom gemessen. Wie @uwefed vorhergesagt hat. Das kann ich nicht mit meinem Multimeter messen. 220 mA wäre ja dann ein Perpetuum mobile.
Achtung! ohne Spannung wird über RX / TX bei dem ESP last gezogen.
Ich habe jetzt 1KOhm auf beide Leitungen. Signalübertragung ist auch so noch da.
So bin ich dann auf der sicheren Seite falls mal was am DFPlayer ausfällt.
Dann sind da natürlich auch gleich:
if(SW3){ SW3=!SW3;myDFPlayer.pause();} else { SW3=1;} IN=0;myDFPlayer.start(); break;
hier ja leicht zu erkennen.
Aber wenn man:
if(SW3){SW3=!SW3;Serial.println("Pause");myDFPlayer.pause();}else {Serial.println("Pause aufgehoben");SW3=1;}IN=0;myDFPlayer.start(); break;
so Progt.. Ist es kein Wunder wenn nach Formatierung gefragt wird.
Den kleinen Fehler habe ich auch erst nach dem Formatieren gefunden.
Man wundert sich, dass es keine Pause gibt und schiebt diesen Fehler dem DFPlayer in die Schuhe.
Und dem hier (myDFPlayer) einen anderen Namen zu geben hat irgendwie noch nicht geklappt.
Da fehlen nur noch ein par Jingels um nicht nur Hintergrundmusik und Reihenerkennung zu vertonen.
Das gilt grundsätzlich für alle IOs und kommt von den verbauten Schutzdioden oder einer vergleichbaren Elektronik. Damit kann man wunderbar ICs grillen, habe ich ausprobiert 
Bei mir ist der Compiler glücklich 
#include "Arduino.h"
#include "DFRobotDFPlayerMini.h"
DFRobotDFPlayerMini meineMusikbox;
void printDetail(uint8_t type, int value);
void setup()
{
Serial.begin(115200);
Serial2.begin(9600);
Serial.println(F("DFRobot DFPlayer Mini Demo"));
Serial.println(F("Initializing DFPlayer ... (May take 3~5 seconds)"));
meineMusikbox.setTimeOut(1000); //Set Time Out to 1000ms
if (!meineMusikbox.begin(Serial2)) { //Use softwareSerial to communicate with mp3.
Serial.println(F("Unable to begin:"));
Serial.println(F("1.Please recheck the connection!"));
Serial.println(F("2.Please insert the SD card!"));
}
Serial.println("DFPlayer Mini online.");
meineMusikbox.volume(10); //Set volume value. From 0 to 30
meineMusikbox.play(1); //Play the first mp3
}
void loop()
{
}
Anzeige für ESP32:
Der Sketch verwendet 264309 Bytes (20%) des Programmspeicherplatzes. Das Maximum sind 1310720 Bytes.
Globale Variablen verwenden 21440 Bytes (6%) des dynamischen Speichers, 306240 Bytes für lokale Variablen verbleiben. Das Maximum sind 327680 Bytes.
Verwendest Du den Pin BUSY?
Bis dato lief das ohne.
Bei mir gab die Abfrage über die serielle Schnittstelle hörbare Störungen, weshalb ich auf BUSY umgestiegen bin. Geht vermutlich auch schneller, ist bei Dir ja ein Thema.
Ich habe BUSY auf einen Interrupt gelegt, dann spart man sich die ständige Abfrage. Ob das im Zusammenhang mit Deinem Programm eine gute Idee ist, wäre zu testen.
Habe ich auch....Aber so richtig wird es nicht angezeigt. Kennst Du den Grund?