der fehler muss etwas mit dem einlesen ins Array zutun haben.
habe es mal ohne Progmem programmiert und da kommen die selben Fehler bei rum - kratz kopf 
In dem Teil des Sketches, den Du uns nicht zeigst.
Wenn Du Hilfe bekommen willst dann müssen wir alles wissen. Ansonsten. wir können nicht hellsehen.
Grüße Uwe
der fehler muss etwas mit dem einlesen ins Array zutun haben.
Welches einlesen, in welches Array?
PS:
Ich warte immer noch auf ein testbares Minimalbeispiel, welches den Fehler zeigt.
Hi Combi,
alles Blödsinn was ich gestern gemacht habe, sorry.
Das ganze Ding kam durch mein altes Midi Interface, dem ich vertraut hatte.
Heute Vormittag habe ich die Ausgabe auf das Display und auf Midi gemacht. Das Interface kam mit der Menge der Daten nicht klar einfach Pause rein machen geht aber auch nicht (hatte ich getestet) das Interpretiert das Ding dann als Fehler und geht auch nicht. Ich werde es dem nächst mit in den Elektroschrott geben.
Habe es jetzt mal so gemacht wie unten beschrieben und im Display die Einzelnen Nummern durch gesteppt. Es läuft bestens - einwandfrei Daten prima - freu 
int RomPrgTo_Midi_(byte num_) // sounds block nach midi out ...
{
/*
#define dspl_v_ 0 // n Zeile 0-19
#define dspl_h_ 20 // n Zeile 20-39
#define line_1_ 0 // 1.Zeile ...
#define line_2_ 1 // 2.Zeile ..
*/
offset_ = num_*77;
lcd.setCursor(dspl_v_,line_1_);// das erste Zeichen in der ersten Zeile.
lcd.print(num_);
lcd.print("<-N ");
lcd.print(offset_);
lcd.print("<-Ofs ");
iZ_=0;
while (iZ_ < 7)
{
outByte_ = pgm_read_byte(&SoundDaten_JV1010[offset_+iZ_]);
midi_dout_(outByte_); // direkt byte out ...
lcd.print(outByte_);
lcd.print(" ");
offset_ = num_*77;
iZ_ += 1;
}
offset_ = num_*77;
lcd.setCursor(dspl_v_,line_2_);// das erste Zeichen in der ersten Zeile.
lcd.print(num_);
lcd.print("<-N ");
lcd.print(offset_);
lcd.print("<-Ofs ");
iZ_=0;
while (iZ_ < 7)
{
outByte_ = pgm_read_byte(&SoundDaten_XV2020[offset_+iZ_]);
midi_dout_(outByte_); // direkt byte out ...
lcd.print(outByte_);
lcd.print(" ");
offset_ = num_*77;
iZ_ += 1;
}
return offset_;
}
Das ganze Ding kam durch mein altes Midi Interface, dem ich vertraut hatte.
Darum baut man Minimalbeispiele!
Ohne alles LCD Midi und sonstiges Beiwerk, damit man den Fehler besser eingrenzen kann.
Hier PROGMEM testen
Das hätte dir offensichtlich einen Tag unnützes Rumeiern eingespart.
Leider habe ich die ganze Woche damit verbracht. Aber bei solchen Daten Mengen geht das meines Erachtens nur mit Prints. Der Gedanke war die Daten vom Gerät auf den
PC zuschicken und dann in meinem Rekorder Prog Formatieren und dann an den Windows eigenen Editor zu übergeben und zu starten.
Zunächst hatte ich es im Display versucht aber nicht das richtige gesehen, weil da wahrscheinlich schon ein Bug drin war.
Früher gab es die Soundkarten und die haben solche Probleme nie verursacht. Das funktionierte so gut, das ich sogar meine Maschine damit gesteuert hatte. Mit diesen heutigen Interfacen geht das nicht mehr. Deshalb bin ich auf USB umgestiegen. Nur für meine Expander und den Eingabe-Controler benötige ich noch Midi. Das läuft dann ohne PC.
lg Roland
Leider habe ich die ganze Woche damit verbracht.
Umso wichtiger ist ein methodisches Vorgehen!
Das glaube ich Dir nicht. Die Ausgabe kommt zustande, wenn Du nicht die Referenz sondern einen Direktzugriff versuchst.
Das ist die ausschlaggebende Zeile:
Im Übrigen:
Da sollten doch eigentlich 77 stehen.
Das ist die ausschlaggebende Zeile:
Die Zeile ist ok!
Ausnahme: Beim Zugriff auf das far Memory
Aber das gibs beim Nano nicht.
Ja jetzt.
Vorher war sie falsch. Und darum hat er da nicht das bekommen, was er wollte.
Verstehe ich nicht....
Macht auch nix.
Er hat es nicht hin bekommen, weil er sich an einer falschen Annahme festgefressen hat.
Und diese nicht überprüfen wollte/konnte.
Hi my_xy_projekt,
die 7 habe ich deshalb dahin geschrieben, weil ich jetzt nur den ersten Buffer in der ersten Displayzeile und den zweiten in der zweiten durch steppe. Zusätzlich habe ich
noch die Ausgabe über Midi.
Die Daten die mir im Display angezeigt werden sind ok,
egal bei welcher Blocknummer, alles richtig ausgegeben.
Ich habe es jetzt noch weiter verfeinert und habe einen
extra Zähler dazu gepackt der auf den Offset gerechnet wird.
Mit dem Digipoti kann ich so durch das ganze Array steppen.
Das ganze Ding wurde verursacht, weil ich vergessen hatte, das mein MidiInterface mit größeren Daten Mengen nicht klar kommt. Anscheinet haben die da einen viel zu kleinen Buffer als FiFo k.A.
Jeden falls komme ich jetzt weiter mit dem Projekt. Es funktioniert einwandfrei mit dem PROGMEM, bin sehr zu frieden damit.
Der ganze Aufwand ist nur deswegen, weil die Daten die an meine beiden Expander geschickt werden, exakt die sein müssen die ihnen zukommen lassen will. Sonst wenn irgend etwas mal nicht gehen sollte, weiß ich das dies aber nicht das Problem ist. Ich werde die Print Ausgabe einfach nur zumachen und nicht löschen, dann kann jeder Zeit nochmal
Prüfen wenn ich mal etwas an den Daten geändert habe etc.
lg Roland
Hi Combi.
das festgefressen hatte, hat es verhindert - der Wille war vorhanden.
lg Roland
der Wille war vorhanden.
Ich habe keinen Versuch gesehen ein Minimalbeispiel zu bauen.
Keine echte Modularisierung, denn einzelne Module kann man auch einzeln testen.
Siehe dazu "MVC Design Pattern".
Trifft nicht genau dein Problem, zeigt aber das Konzept.
Hallo,
mein Kommentar.
Ein testbares Minimalbeispiel zu verlangen ist okay.
Der Rest ist für einen Newbie für den Anfang zu viel verlangt. Der muss erstmal wissen was generell "vorn und hinten" ist.
Der Kollege ist seit 40 Jahren dabei!
Vielleicht Neu bei Arduino.... aber sonst?
Hallo,
na wenn das so ist, kann man schon ein Mindestmaß des Mitwirkens verlangen bzw. voraussetzen.