GUI Design eines Players

[charlytango]

Hi

Bevor ich mich in ein Codingabenteuer stürze frage ich mal nach Erfahrungen.

Was ich seit längerem suche ist ein Player für einen bestimmten Zweck, nämlich im Betrieb einer Tanzschule. Musik und Video. (über Formate lässt sich verhandeln).
Player gibt es viele, oft auch welche mit aufwendiger Grafik und hundert Funktionen, aber nicht diejenigen die nötig wären. Nämlich sauschnelle komfortable Suche in einer großen Bibliothek.
UND das bequeme Einstellen der Geschwindigkeit.
Man muss im Kurs schnell reagieren können und das Tempo und die Stücke dynamisch an die Schüler anpassen.

Meist gibt es das eine ODER das andere -- nie beides gemeinsam.

Nach immer wieder begleitenden Recherchen und Testen einiger Player die mit Lazarus oder Delphi gebaut wurden hab ich die wichtigsten Puzzlesteine zusammen (Musik und Video spielen, Tags lesen und schreiben etc)
Trotzdem wird das seeeehr viel Arbeit bis das klappt.

Deswegen mal auch eine Designfrage.
Ähnlich wie diese Auswahl hier...
Link zu einem Beispielfoto wie würdet ihr so etwas angehen?
Genauer mit welchen Komponenten -- TDBGrid oder GridView oder Virtualgrid ?

Die Bibliothek/Sammlung würde ich aus einem Verzeichnis auslesen und in einer SQL-DB führen

Nette Plauderei darüber wäre nett und Erkenntnisse besser

THX

[Winni]

Hi!

Also ich höre hier gerade Musik mit meiner (ewigen) BASS Baustelle.
BASS kann irre viel hat aber eine steile Lernkurve.

Bass kann auch - wie Du wünscht :

BASS_ATTRIB_TEMPO The tempo of a channel, [-95%...0...+5000%] percents.

Ein gutes Beispiel liefert Gausi mit seinem Nemp (Noch ein MP3 Player).
Ist zwar alles für Delphi gedacht, aber er liefert die Sourcen mit.
Und ich hab schon anderes BASS Zeugs von ihm auf Lazarus/Linux zum Laufen gebracht.

Hier : https://www.gausi.de/home.html

Früher war auf der Seite noch ein Kurs, wie man sich in 16 (?) Schritten einen MP3-Player baut, aber den kann ich jetzt nicht mehr finden.

Keep on rockin'

Winni

PS.: Gefunden! Grundkurs mp3-Player mit BASS.dll: https://www.gausi.de/memp-1.html
Gibt's immer noch, hat aber anscheinend keinen direkten Link mehr.

[charlytango]

Ein gutes Beispiel liefert Gausi mit seinem Nemp (Noch ein MP3 Player).
Ist zwar alles für Delphi gedacht, aber er liefert die Sourcen mit.

Danke für die erneute Info, ich lese bei dir seit Jahren mit und hab mir auch die Sachen von Gausi (und auch andere, zb. OvoPlayer) angesehen. Gausis Nemp wäre schon eine ganz gute Vorlage. Unter Lazarus konnte ich ihn noch nicht kompilieren, scheinbar reicht mein Wissen da nicht.

Als Muster-Player hab ich mir auch JRiver Media Center angesehen und war vom Handling sehr beeindruckt. Leider ist auch dort die Geschwindigkeitsregelung vernachlässigt und damit für einen Kursbetrieb nicht toll - da kann man gleich bei iTunes bleiben. Die Automatismen zum Zusammenstellen von Playlists sind allerdings genial.

Im Moment möchte ich klären ob ich einer möglichen Oberfläche gewachsen bin weil Grids und Trees immer meine Angstgegner waren. Und ohne ausgefeilte Grids (mehrfach sortierbare Spalten, Spalten verschieben und auswählen/einstellen etc etc) wird es nicht gehen. Das ist mehr als eine Menge Arbeit -- aber was solls, andere stricken im Lockdown

Aktuell steht die Frage zur Diskussion welcher Grid für eine Liste ( Genre, Interpreten und Album, aus der DB befüllt, sortierbar, Mehrfachauswahl, inkrementelles Suchen durch Tastendruck ) am besten geignet ist.
Und die Designfrage Frames (da hab ich gar keine Erfahrung) vs Forms steht auch an.

THX

[theo]

@charlytango: Habe neulich auch selber einen "Player" geschrieben.
Eigentlich ist es mehr ein Datenbank-Suchtool mit Abspielmöglichkeit.
Die Files werden vorgängig "gescannt" und die ID3 Daten in eine Datenbank eingetragen.
Danach sucht man halt im Player mit allen möglichen Filtern.

Ich habe dazu gewöhnliche StringGrid genommen und wüsste nicht, was dagegen spricht.
Ich editiere die Tags allerdings nicht in dem Player, dafür gibt es ja gute Tools, z.B. Kid3 auf Linux.
Damit es auch auf kleineren Bildschirmen zu bedienen ist, habe ich drei Tabs gemacht.
1: Suchresultate (Abspielen, zur Playliste hinzufügen)
2: Playliste (Speichern, öffnen. Einträge abspielen, sortieren oder löschen).
3: Info (ID3 Bild, Jahr, Dauer, Bitrate etc. etc.)

Was den eigentlichen Player angeht, kann man nur abspielen, stoppen und im Stück an eine Stelle springen mit einem Trackbar, der auch gleichzeitig als Progressbar dient.
Sehr einfach alles, aber tut's für mich.
Die Suche ist sehr effizient, das war das Ziel (Ganzer String, Substring oder Soundex in Album, Titel, Artist. Dazu ein kombinierbarer "Genres" filter).

Der Player kann MP3 und FLAC. Andere Quellen habe ich nicht.
An eine Veröffentlichung habe ich eigentlich nie gedacht.
Ich betreibe den Player an einem Raspi 4 (Strom sparen ) welcher über USB (LPCM) an einem Panasonic Receiver angeschlossen ist.
Klingt astrein.

[af0815]

Mach einmal einen Dummy für den Frontend und schau wo es Probleme macht. Wenn Das Projekt sinnvollerweise in Frontend und Backend getrennt wird, so kann man sich mal um den Frontend und die Schnittstellen kümmern und mal mit Dummydaten arbeiten.

Was dir bei den verwendeten Komponenten abgeht, das kann man dann besser sehen. Und vor allen Dingen, halte es mal einfach, so das man es ohne exotische Komponenten bzw. Abhängigkeiten kompilieren kann. Dann kann man sich das mal runterladen, kompilieren und sein gefährliches Halbwissen (SCNR) an der Problemstellung testen. Oder auch einen besseren Vorschlag machen.

[charlytango]

Die Files werden vorgängig "gescannt" und die ID3 Daten in eine Datenbank eingetragen.
Danach sucht man halt im Player mit allen möglichen Filtern.

Das ist auch die eigentlicher Herausforderung - blitzschnelle benutzerfreundliche Suche (für Tasten und Mausanwender)

[theo]

Das ist auch die eigentlicher Herausforderung - blitzschnelle benutzerfreundliche Suche (für Tasten und Mausanwender)

Das müsste durch die Datenbank ja gegeben sein.
Du musst halt definieren, wonach gesucht werden kann.
Für meinen Player habe ich nur die gebräuchlichsten Kriterien genommen.
Wenn nach Spieldauer, Veröffentlichungsjahr, Bitrate etc. auch gesucht werden sollen, muss man das natürlich entsprechend vorbereiten.

[pluto]

Ich habe ein "Player" als Server/Client Anwendung geschrieben, der echt stabil läuft. Ist zwar noch nicht alles Perfekt, aber es klappt.
Seit Monaten gab es kein Ausfall. Er läuft bei mir einfach auf ein PI4. im Screen.

In der ersten Version, hatte ich auch alle meine Musik Stücke in einer JSON Datei importiert, aber das habe ich wieder aus genommen. Gefällt mir einfach besser.
Bei mir war es wichtig, ich wollte mehrere Playlisten Gleichzeitig geöffnet haben. So das ich z.b. Nachmittags diese Playlist nutze, Abend, jene und soweiter.

Für den Musik Browser, nutzte ich eine TreeView und für die Playlisten eine ListView, die auf einem PageControl sind. Also Pro Tab eine Playlist.
Dann gibt es Automatisch, Weiter, Zurück, Zufall oder Endlos. Eine weitere Besonderheit, die ich noch nirgends gesehen habe:
Wenn Dateien, bei einer leeren PlayList hinzugefügt werden und gerade keine Musik Gespielt wird, wird Automatisch mit dem ersten Eintrag der Playlist Angefangen.

Zur Zeit gibt es zwei Clients: Ein Grafischen(GTK2) und einen Kommandozeilen Client.

Ich nutzte hier die libVLC Lib. Bin mir gerade nicht sicher ob man hier auch die Abspiel Geschwindigkeit einstellen kann.
Lustig ist es auch, wenn man mehr als ein Stück "gleichzeitig" abspielt. Jede PlayList hat ihre eigene LibVLC Instants. Ist etwas übertrieben.

[charlytango]

Hallo!
Freut mich dass es doch einiges an Resonanz gibt.
Um euch eine Idee zu geben was ich mir so vorstelle (Gedanken sind ja noch frei, auch wenn sie schräg sind) hab ich eine kleine Spec zusammengeklopft:

**************Basis
Für den Anfang wäre ein Funktionsumfang wie iTunes (der Teil zum Abspielen von Musik) mal ganz gut.

Schnelle Suche nach Genres (=Tanz) Interpreten, ggfs auch Album.

Ergebnisliste mit definierbaren Spalten wobei BPM (Beats per Minute) bzw „Bars per Minute“ wichtig sind. Auch exotischer Tags sollten in der Ergebnislisten anzeigbar sein.

Wird ein Stück aus der Liste gespielt soll der Player automatisch die nächste spielen.

Leicht zugängliche Temporegelung ohne Verzerrung (+- 20% wird reichen)

Playlisten, hierarchisch organisiert. Ausgefeiltes Management und auch exportierbar in Dateien (.m3u)

*************Erweitert
Bis dahin wars Tagesgeschäft – alles andere hilft bei Organisation und Verwaltung.

Idealerweise lauffähig auf Windows, Apple, Linux, Raspberry

Datenhaltung (also ausgelesene Tags, Playlisten, Einstellungen etc etc.) wahlweise in lokaler SQL-DB oder einem ausgewachsenen SQL Server (unterschiedliche Server unterstützen)
Daten in JSON XML und Konsorten finde ich zu proprietär. In der DB kann ich jederzeit mit anderen Werkzeugen Felder hinzufügen oder Mengenoperationen machen.

Playlisten, Bewertungen, Markierungen etc abhängig vom Benutzer bzw Standort.

Tagspeicherung wahlweise in der DB oder auch zusätzlich direkt in den Dateien (Sicherungsmechanismus der Schule gegenüber unlauteren Mitarbeitern, denn der wahre Arbeitsaufwand steckt im Taggen und Auszählen der Musikstücke).

Große leicht erreichbare Buttons für den Player, Schriftgrößen einstellbar wegen leichter Lesbarkeit, ggf auch Skinning.

Zwei Playerinstanzen gleichzeitig, Vorhören

Trickreiche automatische Erstellung von Playlisten (das ist ein ganz eigener Bereich und hat viel mit Gewichtung, Suche und anderen Parametern zu tun) denn die Erstellung von Playlisten für Übungsabende oder Thementanzabende ist ungeliebt und aufwendig.

Fernbedienung (Zb von Rezeption oder Barbereich) wäre fein. Vielleicht auch Webserver wo Kunden weiterschalten aussuchen oder bewerten können.

Der Player sollte auch Videos (zumindest mp4) abspielen können – auch mit Temporegelung. In die Videos würde ich auch Schrittbeschreibungen hinein taggen.

*****NEMP Player
Das was der NEMP Player https://www.gausi.de/home.html unter der Haube hat ist schon ein beeindruckendes Teil. Das Teil um eine Temporegelung erweitert und es wäre ein guter Knadidat -- nicht perfekt aber gut.

Da steckt eine Menge Arbeit drin. Dieses Blättern in Covern ist sicher aufwendig und sehr hübsch – aber für meine Zwecke unnötig Wir reden von 20.000+ Tracks und 2500 Alben – da ist diese Methode unbrauchbar.

Elegant fand ich die Umschaltmöglichkeit zwischen verschiedenen Suchstrategien (Albumbrowsing, Genre-Interpret, Album-Interpret etc etc). Die Playlistenverwaltung hat noch Luft nach oben.

Ich habe versucht den NEMP nach Lazarus zu portieren, bin aber bei einer Menükomponente gescheitert.

JRiver Media Center ist etwas besser strukturiert, kann aber auch keine Temporegelung.

Die Zitate hab ich nur reingestellt damit die geneigten Helfer informiert werden

Ich habe ein "Player" als Server/Client Anwendung geschrieben, der echt stabil läuft. Ist zwar noch nicht alles Perfekt, aber es klappt.
Seit Monaten gab es kein Ausfall. Er läuft bei mir einfach auf ein PI4. im Screen.

Für meinen Player habe ich nur die gebräuchlichsten Kriterien genommen.
Wenn nach Spieldauer, Veröffentlichungsjahr, Bitrate etc. auch gesucht werden sollen, muss man das natürlich entsprechend vorbereiten.

Mach einmal einen Dummy für den Frontend und schau wo es Probleme macht.

PS.: Gefunden! Grundkurs mp3-Player mit BASS.dll: https://www.gausi.de/memp-1.html
Gibt's immer noch, hat aber anscheinend keinen direkten Link mehr.

[Winni]

Hallo!

Ich wil mich kritisch zur SQL-DB äußern.
Das ist doch mit Kanonen auf Spatzen geschossen.

Falls das Single-User sein soll (Und nur dann!) gebe ich mal Werte zur Suche über ein String-Grid an:

Ich habe hier ein Projekt mit:
20 Colums, davon ist in einer ein Memo-Feld gespeichert, also längerer Text.
Leicht über 60.000 Rows.

Suche über alle Colums und alle Rows, dabei case-sensitive disabled - also jedesmal auch noch ein UTF8upper gefolgt von einem Pos (such, Feld) wird bei einer sinnlosen Suche - also alle 20 * 60.000 Zellen abklappern - in 185 - 195 Millisekunden erledigt. StringGrids sind sauschnell.

Gespeichert ist das Ganze als CSV, Sortieren nach verschiedenen Colums geht auch aasig schnell dank internem Quicksort.

Wie gesagt: Single User.

Winni

[pluto]

Suche über alle Colums und alle Rows, dabei case-sensitive disabled - also jedesmal auch noch ein UTF8upper gefolgt von einem Pos (such, Feld) wird bei einer sinnlosen Suche - also alle 20 * 60.000 Zellen abklappern - in 185 - 195 Millisekunden erledigt. StringGrids sind sauschnell.

Habe ich es richtig verstanden? Du lädst mehr als 60.000 in StringGrids und lässt dann eine Such Anfrage drauf los?
und hast dann braucht das ganze "nur" 185 - 195 Millisekunden?
Sind alle Zeilen nur mit ein paar Buchstaben gefüllt?

[Winni]

Hi!

Jo. Auf Deinen Wunsch noch mal zählen lassen:

20 Columns
60306 Rows
6.368.972 Byte
Pro Row im Durchschnitt: 106 Byte (als UTF8chars)

Ich sag ja: TStringGrid ist irre schnell.

Winni

PS: Anzeige ist natürlich während des Suchens disabled.

[pluto]

Jo. Auf Deinen Wunsch noch mal zählen lassen:

Danke, ich glaube wir schweifen hier vom Thema ab, auch wenn ich noch eine Anmerkung habe:
Was mich bei sowas stört, ist das alles in den Speicher geladen werden muss.

Ich hatte eine "Datenbank" als Json File, dachte mir, die Idee ist gut, aber der Nachteil ist natürlich, die ganze JSON Datei muss in den Speicher, sobald sie bearbeitet werden soll.
Vielleicht mache ich da noch mal ein extra Thread zu auf. Zum Thema, was sind viele Daten? Datenhaltung im Programm oder so ähnlich.

Im Moment nutzte ich SQL-Lite intensiv bei einem Projekt. Hierbei weiß ich natürlich nicht, wie das SQL-Lite intern macht im Unterschied zu einer MariaDB Server Anwendung.
Z.B. wenn ein "Select" abgesetzt wird. Bei

Ich sag ja: TStringGrid ist irre schnell.

Ich nutzte bisher immer bei GTK2 Projekten, die ListView/TreeView und die ist alles andere als "schnell".

[Winni]

[
Was mich bei sowas stört, ist das alles in den Speicher geladen werden muss.
....
Ich nutzte bisher immer bei GTK2 Projekten, die ListView/TreeView und die ist alles andere als "schnell".

a) Das sind bei etwa 6 MB wie bei mir auch nur 0.2% des RAM bei 32 GB

b) ListView/TreeView sind für größere Datenmengen nicht praktikabel.
Deshalb war ich ja seinerzeit so positiv überrascht über TStringGrid.

Soviel nochmal zum Abschweifen

Winni

[af0815]

Eine IO Operation gehört auf DB Systemen zu den teuersten Operationen. Jeder Zugriff hat einen Preis, der in den Caches ist auch billiger als der Zugriff auf den langsamen Hauptspeicher. Grundlegend Cache vor Hauptspeicher und dann kommt lange nichts, dann erst das IO Subsystem, egal wie schnell das ist.