Der Simpson-Generator ist ja cool! Den kannte ich noch nicht.
Die Erweiterung des DEV-Codes um auch einen VON-BIS-Hörbuchmodus zu unterstützen, ist gar nicht so kompliziert. Ich habe mir mal kurz die nötigen Änderungen angesehen (Vorsicht: ungetestet einfach so runtergeschrieben!):
Code-Änderungen (Anklicken zum Ausklappen)
Zeilen 566-581 ersetzen durch:
if (myFolder->mode == 5 || myFolder->mode == 10) {
if (currentTrack < numTracksInFolder - firstTrack + 1) {
currentTrack = currentTrack + 1;
Serial.print(F("Hörbuch Modus ist aktiv -> nächster Track und "
"Fortschritt speichern"));
Serial.println(currentTrack);
mp3.playFolderTrack(myFolder->folder, currentTrack);
// Fortschritt im EEPROM abspeichern
EEPROM.update(myFolder->folder, currentTrack);
} else {
// mp3.sleep(); // Je nach Modul kommt es nicht mehr zurück aus dem Sleep!
// Fortschritt zurück setzen
EEPROM.update(myFolder->folder, firstTrack);
setstandbyTimer();
}
}
Zeilen 615-624 ersetzen durch:
if (myFolder->mode == 5 || myFolder->mode == 10) {
Serial.println(F("Hörbuch Modus ist aktiv -> vorheriger Track und "
"Fortschritt speichern"));
if (currentTrack > firstTrack) {
currentTrack = currentTrack - 1;
}
mp3.playFolderTrack(myFolder->folder, currentTrack);
// Fortschritt im EEPROM abspeichern
EEPROM.update(myFolder->folder, currentTrack);
}
Hinter Zeile 930 einfügen:
// Spezialmodus Von-Bis: Hörbuch: kompletten Ordner spielen und Fortschritt merken (nur für ein Hörbuch zur Zeit je Ordner)
if (myFolder->mode == 10) {
Serial.println(
F("Spezialmodus Von-Bis: Hörbuch -> kompletten Ordner spielen und Fortschritt merken (nur für ein Hörbuch zur Zeit je Ordner)"));
firstTrack = myFolder->special;
numTracksInFolder = myFolder->special2;
currentTrack = EEPROM.read(myFolder->folder);
if(currentTrack < firstTrack || currentTrack > firstTrack + numTracksInFolder) {
currentTrack=firstTrack;
Serial.println(F("Der gespeicherte Fortschritt stammt nicht von diesem Hörbuch. Starte am Anfang."));
}
mp3.playFolderTrack(myFolder->folder, currentTrack);
}
Zeile 999 ersetzen durch:
if (myFolder->mode == 8 || myFolder->mode == 9 || myFolder->mode == 10) {
Zeile 1473 ersetzen durch:
theFolder->mode = voiceMenu(10, 310, 310, false, 0, 0, true);
Zeile 1490 ersetzen durch:
if (theFolder->mode == 7 || theFolder->mode == 8 || theFolder->mode == 9 || theFolder->mode == 10) {
Und nicht vergessen: Neue MP3-Datei für Folder.Menü erstellen und ablegen.
1 „Gefällt mir“
Und wenn man den Modus implementiert und gleichzeitig im EEPROM zusätzlich einen Kartenspeicher anlegt? Dann könnte man im neuen Modus zuerst mit ner if Schleife nachschauen ob da was liegt und wenn nicht, dann erst im Ordner Speicher? K.A. wieviel Stände in den 1KB Speicher passen…? Und vielleicht könnte man dann irgendwann auf den Ordernspeicher verzichten. Wäre ja erstmal save im DEV Bereich zu testen.
Oh da haben wir zeitgleich gepostet.
Du codest, ich teste voller Dankbarkeit und Zufriedenheit heute abend! 
Mode == 10 —> I Like
Hätte ich garantiert. Einfach nur ne 310.mp3? Läuft das dann nicht oder geht nur die Programmierung nicht?
Re:SimpsonGen:
You made my day!
Naja, wenn Du die Karte programmierst, willst Du auch hören wenn Du den Modus ausgewählt hast. Ohne wird es schwierig.
Aber ich bemerke gerade ein kleines Problem. Die MP3-Datei für den Menüpunkt müsste Nummer 0320 haben (310+10), aber den Track gibt es schon…
Eine Möglichkeit wäre, den Fortschritt auf die Karte zu schreiben. Hörspiel oder Hörbuch läuft solange wie die Karte aufgelegt ist, Karte wird bei jedem neuen gespielten „track“ des Ordners mit dem aktuellen track beschrieben und stoppt wenn die Karte weg ist. Karte/Figur ist magnetisch fest, damit sie nicht einfach so runter fällt.
Das wäre dann in etwa das Verhalten wie bei der Toniebox. Da funktioniert das gut, weil es eben nicht potenziell Dutzende von Hörspielen auf einer Figur gibt. Beim TonUINO würde das aber in den meisten Fällen dafür sorgen, dass die Box ständig vor sich hin dudelt, auch wenn schon lange keiner mehr zuhört (eingeschlafen, in ein anderes Zimmer gegangen …).
Mit den bekannten Einschränkungen des DFPlayers (kein Spulen, begrenzte Datei–/ Ordneranzahl) sind die vorhandenen Modi meiner Meinung nach gut durchdacht und funktionieren wunderbar. Ein leicht abgänderter Hörspielmodus (Tracks der Reihe nach spielen, nach jedem Track stoppen und Fortschritt speichern, Vor– und Zurückspringen der Titel erlauben) würde hier sicher auch einige dankbare Nutzer finden. Vorteil wäre, dass man auch gezielt Folgen auswählen kann. Nachteil wäre aber, dass man sich das Speichern des Fortschritts dann auch schenken kann, weil ein Springen in den Titeln das Ganze quasi aushebeln würde.
Es gibt da einfach so viele Varianten, dass man es mit an Sicherheit grenzender Wahrscheinlichkeit nicht jedem zu 100% Recht machen kann. Allein mit den paar in diesem Post genannten Funktionen lassen sich mehrere Dutzend verschiedene Varianten eines Hörspielmodus konstruieren. Toll wäre natürlich, wenn man es codeseitig so hinbekommen könnte, dass man sich seinen eigenen Modus durch Wählen bestimmter Features zusammenbauen kann (z.B. Karte weg=Pause, der Reihe nach spielen, nach jedem Track stoppen, Fortschritt speichern, Vor/Zurück erlaubt usw.), aber ich vermute mal, dass das zu komplex wird.
Wow, Danke für das viele Feedback und umfangreiche Diskussion
@Dave as denkt man im ersten Moment, aber der Trick sind die Defines und Kartenparameter. Damit erstellt man keine fixen Varianten vorab, sondern der User kann sie sich selber zusammenstellen. Ändert er nix, bleibt alles Default. Will er was Anders, ändert er ggf. ein einziges Define um.
Und das funktioniert mega gut:
Ich habe vor Jahren ganz erfolgreich Multiwii Platinen (für ferngesteuerte Selbstbau Multicopter mit Arduino Nano als Zentralrechner) angewendet (d.h. nicht selber den Code geschrieben, sondern „nur“ die Hardware zusammengelötet/gesteckt und entsprechend den Code konfiguriert.
Das sieht so aus: MultiWii config.h Das sind 1200 Zeilen reine Konfiguration mit viel Kommentaren und Erklärungen, bevor die Hauptschleife überhaupt mal anfängt.
Ich komme drauf, weil das alles auch auf dem gleichen popeligen Arduino Nano gelaufen ist.
Im MultiWii Universium gibt es dutzende verschiedende Hardwareplatinen / Implementierungen (gerade nachgezählt 70!!! verschiedene Basisplatinen mit versch. Sensoren) und verschiedenste zusätzliche Sensoren (26 unterschiedliche mehrachsige Beschleunigungs/Bewegungssensoren definiert), die z.T. ganz unterschiedliche E/As benutzen. Alles in einer Konfig mit Defines!
Dazu kommt, dass jeder Pilot das Verhalten der Drohne sowohl auf die benutzte Hardware, als auch auf die unterschiedlichen Massen=Trägheitsmomente der jeweiligen Drohne, sowie das gewünschte Flugverhalten einstellen (Arcobatic, ruhiges Filmen,…) will nein er muss! Am Ende ist keine Drohne wie die andere und das obwohl alle den selben Config.h Code benutzt haben.
Das tolle daran ist, dass man über die verschiedenen Defines sich seine Drohne Hardwaremäßig wie auch Verhaltensmäßig mit wenigen Defines selber zusammenkonfiguriert hat. Und ehrlich gesagt kann ich mir das auch ganz gut bei TonUINO vorstellen. Damit macht man es nicht allen zu 100% recht, sondern die Leute machen es sich selber zurecht. Und die Drohnen sind nicht wegen des ArduinoCodes abgestürzt.
Schon die TonuINO Buttons und Lautstärke Möglichkeiten klingen schwer nach
//Define 3 Buttons (Default kann ggf. weggelassen werden)
//Define 5 Buttons (Volume auf Extra Buttons auf Standard Pin x,y wer andere Pins nutzen will muss weiter im Code die Pins abändern)
//Define Rotary (Volume als Drehgeber, Standard Pin x,y)
//Define Poti (Volume als Poti, Standard Pin x,y)
Das tolle ist ja das obige Beispiele z.T bereits umgesetzt/getestet sind und die Hardware deterministisch festgelegt ist.
Eigentlich alles was Hardware ist wäre vielleicht super als Option zu integrieren
// Define LED Ring
// Define NEO Pixel
// Define Battery Status LED
whatever you want.
Aufgrund der begrenzten Anzahl an Pins kann man natürlich nicht alles gleichzeitig integrieren bzw. muss aufpassen, dass die Pins richtig gesetzt sind. Aber aus eigener Erfahrung mit den MultiWii Platinen und Code kann ich sagen, dass das echt einfach ist, im Gegensatz zu neuen Code schreiben.
Noch geiler ist eigentlich TonUINO mit den RFID Karten, weil man ohne PC sowohl Abspiel Modi als auch Admin Konfiguration im nachhinein durch Parameter und Taster ändern kann. Legt man dann die AbspielVariablen nicht als fixe Varianten an, sondern als zu übergebende Kartenparameter könnte ich mir vorstellen, dass der Code eher kürzer wird, weil man eben nicht zig Modi (10?) nacheinander definiert. Aber die Abspielmodi i.V.m. Kartenparametern ist eigentlich ein ganz anderes Thema als die Hardware Defines.
Ich möchte aber auch sagen, dass ich den Main Code für Multiwii nie angefasst habe, es hier also nur theoretisch vorschlagen kann. Mit den Defines für Hardware in der Config.h und VerhaltensModes aber sehr gut zurecht gekommen bin.
Bitte schreibt jetzt nicht, ja dann mach doch alleine, Forke es und codier dir die Welt. Genau das ist leider nicht mein Metier. Ich finde es sehr schade, hier zu lesen, dass die Leute so geile Sachen wie den Drehgeber oder Poti bereits implementiert haben und ich das aktuell nicht einfach mit einer Wegnahme einer Auskommentierung übernehmen kann, obwohl es schon existiert. Ich muss das ja gar nicht mehr erfinden, trotzdem kann ich es nicht nutzen und komplex ist es eigentlich auch nicht. Klar hat der eine oder andere einen der aktuell 138 Forks für seine Experimente genutzt, aber das nutzt den weniger Begabten nix, wenn es nicht in den Master zurückfließt. Soll ich jetzt die geforkte Uraltversion nehmen, weil sie EINE neue Funktion hat, ich dafür aber auf die anderen 30 Funktionen der DEV verzichten muss? Ich bin ganz sicher nicht alleine mit meinen Bastelskills und Begeisterung aber rudimentären Codingskills, die eben nicht dafür reichen Codefetzen zielführend zusammenzuflicken.
2 „Gefällt mir“
So habe ich getestet und es funktioniert wie von dir wohl erwartet. Programmiert habe ich zuerst mit dem TonUINO. Da hatte ich allerdings noch die MP3s von der MasterVersion drauf, obwohl ich gestern schon auf die DEV umgestiegen war. Das war Ansagentechnisch nicht ganz korrekt bzw. Quark, hat aber irgendwie geklappt und ich konnte mir die Datenstruktur auf der Karte mal anschauen.
Die Testumprogrammierungen habe ich dann in der Android App gemacht. Beim „Bis-Track“ muss ich irgendwie +2 +3 rechnen. Also Track 10 ist der Wert 0C (12) und nicht 0A. Ganz habe ich das noch nicht verstanden.
Für einen Quick Fix funktioniert das schon. Allerdings ist die Kombination von einer Hörbuchkarte durchlaufend und einer Von-Bis beim Wechsel natürlich erwartet nicht ganz richtig, soll heißen.
Wenn ich zuerst die Von-Bis Karte nehme und lasse sie bis zu Ihrem Ende laufen und wechsel danach auf die Hörbuchkarte, dann startet die dort wo Von-Bis anfängt. Es wird also auch beim Durchlaufen der Von-Bis Karte am Ende ins EEPROM der Von/Starttrack reingeschrieben. Das ist eigentlich unnötig falsch. Nehme ich zwei unterschiedliche Von-Bis Karten, dann spielt er beim ersten Wechsel der Karte einmalig den alten Stand (nur einen Track) und dann wechselt er auf den richtigen Anfrangstrack der anderen Karte. Da könnte man vielleicht noch nen Check machen ob der EEPROM Track innerhalb der Range liegt. Aber ansonsten, perfekt in den gegebenen Rahmenbedingungen. Vielen Dank!
Zu MultiWii:
Das MultiWii-Projekt ist ja um einiges größer und älter. Grundsätzlich kann ich Deine Anregung nachvollziehen. Nur: es müsste sich erstmal jemand finden, der das in die Hand nimmt, umsetzt und dann auch laufend pflegt (also weitere Änderungsideen einbaut). Und danach würde sich zeigen, ob die Community das annimmt…
Wenn Du eine normale Hörbuchkarte (z.B. für Reihe von Hörbüchern) mit einer von-bis-Hörbuchkarte kombinieren willst, ist die Frage, was beim Ende des Abspielens der von-bis-Karte passieren soll. Derzeit wird auf den Anfang dieser Karte zurückgestellt. Genauso ist aber möglich, auf den Gesamtanfang oder - wohl die beste Altetnative - auf den Anfang des nächsten Einzelhörbuchs zu setzen. Mal sehen, wann ich dazu komme, mir den Code nochmal dafür anzusehen…
Edit:
Jetzt kam ich dazu. Es gab noch ein paar Bugs. Nun sollte es passen.
Das Verhalten sollte nun so sein:
Wenn eine von-bis-Hörbuchkarte vollständig abgespielt wird, stoppt das Abspielen. Nochmaliges Drücken von Next ist dann ohne Funktion. Bei Auflegen einer normalen Hörbuchkarte für denselben Ordner fährt der TonUINO am nächsten noch nicht abgespielten Track fort.
Das Ganze kann man also z.B. für eine Hörbuchreihe nutzen, die man entweder von vorne bis hinten durchhören kann oder eben einzelne Hörbücher mit entsprechenden Karten direkt auswählt, oder aber man nutzt das z.B., um einzelne Kapitel eines Hörbuches anzuspringen, wobei jedes Kapitel eben aus mehreren Tracks bestehen kann und somit auch innerhalb eines Kapitels der Fortschritt gespeichert wird. Jedes Kapitel bekommt dann eine eigene von-bis-Hörbuch-Karte.
Dies sind die korrigierten Code-Änderungen:
Code-Änderungen (Anklicken zum Ausklappen)
Zeilen 566-581 ersetzen durch:
if (myFolder->mode == 5 || myFolder->mode == 10) {
if (currentTrack + 1 < firstTrack + numTracksInFolder) {
currentTrack = currentTrack + 1;
Serial.print(F("Hörbuch Modus ist aktiv -> nächster Track und "
"Fortschritt speichern"));
Serial.println(currentTrack);
mp3.playFolderTrack(myFolder->folder, currentTrack);
// Fortschritt im EEPROM abspeichern
EEPROM.update(myFolder->folder, currentTrack);
} else {
// mp3.sleep(); // Je nach Modul kommt es nicht mehr zurück aus dem Sleep!
// Fortschritt zurücksetzen (wenn vorhanden: auf das nächste Hörspiel im Ordner. sonst: ganz auf den Anfang)
if(currentTrack < mp3.getFolderTrackCount(myFolder->folder)) {
EEPROM.update(myFolder->folder, firstTrack + numTracksInFolder);
} else {
EEPROM.update(myFolder->folder, 1);
}
setstandbyTimer();
}
}
Zeilen 615-624 ersetzen durch:
if (myFolder->mode == 5 || myFolder->mode == 10) {
Serial.println(F("Hörbuch Modus ist aktiv -> vorheriger Track und Fortschritt speichern"));
if (currentTrack > firstTrack) {
currentTrack = currentTrack - 1;
}
mp3.playFolderTrack(myFolder->folder, currentTrack);
// Fortschritt im EEPROM abspeichern
EEPROM.update(myFolder->folder, currentTrack);
}
Hinter Zeile 930 einfügen:
// Spezialmodus Von-Bis: Hörbuch: kompletten Ordner spielen und Fortschritt merken (nur für ein Hörbuch zur Zeit je Ordner)
if (myFolder->mode == 10) {
Serial.println(
F("Spezialmodus Von-Bis: Hörbuch -> kompletten Ordner spielen und Fortschritt merken (nur für ein Hörbuch zur Zeit je Ordner)"));
firstTrack = myFolder->special;
numTracksInFolder = myFolder->special2;
currentTrack = EEPROM.read(myFolder->folder);
if(currentTrack < firstTrack || currentTrack >= firstTrack + numTracksInFolder) {
currentTrack = firstTrack;
Serial.println(F("Der gespeicherte Fortschritt stammt nicht von diesem Hörbuch. Starte am Anfang."));
}
mp3.playFolderTrack(myFolder->folder, currentTrack);
}
Zeile 999 ersetzen durch:
if (myFolder->mode == 8 || myFolder->mode == 9 || myFolder->mode == 10) {
Zeile 1473 ersetzen durch:
theFolder->mode = voiceMenu(10, 310, 310, false, 0, 0, true);
Zeile 1490 ersetzen durch:
if (theFolder->mode == 7 || theFolder->mode == 8 || theFolder->mode == 9 || theFolder->mode == 10) {
Und nicht vergessen: Neue MP3-Datei für Folder.Menü erstellen und ablegen.
Wenn man auch die Möglichkeit haben möchte, mehrere Positionen (quasi Lesezeichen) innerhalb eines einzigen Ordners zu speichern, würde ich das auf eine andere Weise machen: Man könnte eine Modifier-Funktion für ein Lesezeichen programmieren, die sich so verhält: Wenn man eine solche Lesezeichenkarte auflegt während der TonUINO gerade etwas abspielt, wird die aktuelle Konfiguration von myCard inklusive der aktuellen Trackposition auf der Lesezeichenkarte gespeichert. Wenn gerade nichts abgespielt wird (weil noch keine Karte auflag oder weil das Abspielen gerade pausiert), wird die Konfiguration der Lesezeichenkarte übernommen und abgespielt. Das funktioniert dann auch gleich für alle Modi, nicht nur für den Hörbuchmodus. So kann man auch z.B. bei Albumkarten eine aktuelle Position (Track) speichern und später wieder dort fortsetzen. Das Lesezeichen ist dann eben eine physische Karte und es können so beliebig viele Lesezeichenkarten gleichzeitig angelegt werden.
6 „Gefällt mir“
Oha. Das geht dann ja weit über Anfängerfragen hinaus 
Danke für die ausführliche Erläuterung, das klingt einleuchtend und sehr interessant. Mir war gar nicht klar, was so alles möglich ist. Als längerfristiges Ziel wäre so eine softwareseitig komplett modulare Plattform sicher ganz im Sinne der Community.
2 „Gefällt mir“
Ich fände es toll, wenn es diese Funktion auch direkt in die offizielle Firmware schafft 
Ich muss wirklich mal C-Programmieren lernen… 
@Peer Echt toll was du da mal so schnell programmiert hast !!!
Hmm, bin leider kein Coder und ich frage mich wie andere Projekte die Community zum gemeinsamen mitmachen animieren und dies ohne viel Aufwand jonglieren, damit am Ende viele etwas beitragen können und nicht alles auf 1-2 Personen lastet. Hier wird soviel Tolles angepasst, aber nicht alles scheint zurück in die DEV/Master zu fließen.
Ich habe mir heute mal @stephan 's fork angeschaut und er abeitet ja ganz kräftig mit define. Ziemlich cool
Nur stellt sich mir die Frage, wird das mal zusammengeführt oder muss ich mich dauerhaft entscheiden, ob ich den DEV haben will mit seinen Features, oder Stephans code mit anderen Features. Ich finde dieses Auseinander driften irgendwie schade.
Merge es dir einfach selber so zusammen mit dem was Du haben willst.
Die Funktionen die du nutzen willst baust du mit ein, den Rest wirfst du raus oder nutzt du einfach nicht wenn du mit defines arbeitest.
Fertig ist die Laube.
Du kannst zum Beispiel recht schnell lernen welcher Code zusammen gehört wenn du dir die jeweiligen #ifdef anschaust.
Die Art Antwort kann nur von einem erfahrenen Entwickler kommen 
Sorry, den Kommentar konnte ich mir nicht verkneifen (ist aber nicht böse gemeint)
Ich vermute mal stark, dass über 90% der Nutzer das nicht „einfach mal so zusammen mergen“ können. Natürlich kann man viele dafür notwendige Fähigkeiten erlernen, aber auch das ist nicht jedermanns/fraus Sache. Den vorhandenen Code dann noch so zu verstehen, dass man auch eigene Wünsche einbauen kann erfordert immens viel Zeit und Geduld die nunmal nicht jeder hat. Jeder der sich mal durch fremden Code gekämpft hat, wird wissen wie langwierig das sein kann. Und für jemanden der bisher gar nicht programmieren kann ist das kaum zeitnah zu leisten, grade wenn man bedenkt, dass es wohl meist Eltern sind, die ihren Kindern einen TonUINO bauen wollen. Wie es mit der freien Zeit da bestellt ist, muss denke ich nicht weiter erläutert werden.
4 „Gefällt mir“
Darin liegt dann wohl auch einer der Schlüssel - Wenn überwiegend Eltern statt Kauf einer TonieBox einen Tonuino aus dem DIY-for-Dummies-Regal ziehen wollen - Wer soll dann contributen…? Mal abgesehen davon, dass das ganze hier nicht international, sondern überwiegend im deutschen Sprachraum verteilt ist. Wenn alle nur sagen „jemand müsste mal, aber ich sicher nicht“ - Wer soll dann dieser jemand sein…?
Ich denke, dass das Projekt hier manchmal etwas missverstanden wird: Wenn jemand sich einen Tonuini erdenkt, Code, Baupläne und eine Community stiftet, die eigene Platine auch teilt, dann heißt das nicht automatisch, dass man sein Freizeitleben auch fortan dem Aufbau und Management einer Kommerz-Konkurrenz-fähigen Plattform widmen muss. „Jetzt sagt nicht wieder, ich soll selber forken - Ihr sollt das gefälligst für mich leisten!“ - Puh, da würd ich lieber nichts teilen, oder meine contributions aus dem Netz nehmen, damit ich nicht diese Erwartungshaltung wecke…
Fakt ist: Hier wurde etwas Tolles in einer kleinen Community aus wenigen Hobby-Devs mit vielen Profiteuren geteilt, und immer wieder gibt es tolle Menschen, die ihre Freizeit in eigenem Ermessen der Hilfe für andere und für neuen Features opfern (allein in diesem Thread die geduldigen Testsvon @Peer).
Darunter war aber trotz frei verfügbaren Grundlagen bisher niemand, der sich als unbezahlter Projektleiter von unbezahlten Devs sieht, die das Alle als Mission verstehen. Und das zu fordern, ist weltfremd: Solche Dinge wie Linux, GNU, oder Dein Drohnenprojekt „passieren“, sie lassen sich nicht herbeifordern.
Ich für meinen Teil bin lieber dankbar für den Mehrwert, der da ist (und das ist viel) - als mich über das Delta zu ärgern, was noch da sein könnte, wenn alle Beteiligten (außer mir) endlich ihre Freizeit der Sache wie einem bezahlten Vollzeit-Job widmen würden (und da kenne ich genug weniger engagierte Beispiele für kommerzielle Projekte als den Tonuino).
10 „Gefällt mir“
Es sind im übrigen (überwiegend) auch Eltern die das alles hier - in der gleichen knappen Freizeit - geschaffen haben, am laufen halten und auch hinter den Kulissen weiter intensiv daran arbeiten, dass es für mehr Eltern (noch) einfacher wird einen TonUINO zu bauen. Rom wurde aber halt auch nicht an einem Tag erbaut. Von daher „Tee warten und abtrinken“ oder irgendwie so 
.
8 „Gefällt mir“
@Stephan, @Thorsten: Meint ihr, man könnte den Spezialmodus Hörbuch von-bis noch in die offizielle Software mit aufnehmen oder wollt ihr das eigentlich nicht?
Möchte hier auch keinen Druck oder sonst was machen, würde es nur gerne wissen ob ich das Feature irgendwann mal nutzen kann.
Ich werde auf jeden Fall bei der offiziellen Software von Thorsten bleiben und keine Modifikationen vornehmen! Bin einfach zu wenig im Thema Programmierung drin und wenn es mal wieder ein Update gibt muss ich abwägen, ob mir meine Modifikation oder die neuen Features wichtiger sind (weil ich es wahrscheinlich nicht schaffe, die Modifikationen in eine neue FW zu bringen…).
Edit:
Und sorry, falls ihr euch auf den Schlipps getreten fühlt oder ich euch mit der Anfrage nerven sollte… Ihr bekommt ja wahrscheinlich ständig solche Anfragen…
2 „Gefällt mir“