Filter für BPM größer als / kleiner als

Dann nutze die verlinkten zusätzlichen Suchparameter im Filter oder arbeite mit gut gepflegten virtuellen Ordnern.

Ich dachte, es ginge um deine persönliche Sendungszusammenstellung.
Wenn du jedoch als “Musikredaktion” deines Senders anfragst: Ich ahne, was ihr vorhabt (ich beobachte das ja schon eine Weile bei euch), rate euch aber aus jahrelanger Erfahrung heraus zu einer anderen Strategie.

Auch ich habe in der Vergangenheit einige Ideen gehabt, die sich letztlich als falsch herausgestellt haben. Kann man prima hier im Forum nachlesen (#1 ist ein prima Beleg dafür :wink:).

Gut und schön. Nutze ich ja auch.
Aber wozu virtuelle Ordner, wenn ich deren Inhalte auch mit Wertebereichen zur Laufzeit abfragen kann?

Deshalb bitte

als Feature-Request für Hand- und Schedulerbetrieb “einloggen”.
(Falls nicht schon geschehen)

Danke für die Aufmerksamkeit
Martin

Martin, ich habe schon gestern Abend und heute Vormittag nach entsprechenden Beiträgen von Torben im Forum gesucht, bislang noch erfolglos: Irgendwo in meinem Hinterkopf geistert ein statement von ihm herum, dass das eben nicht so einfach ist.

Wenn ich mich richtig erinnere, müsste er dazu zwei bis vier verschiedene SQL-Abfragen auslösen, die Ergebnisse in eine temporäre Tabelle eintragen und diese Tabelle dann erneut abfragen.
Oder er schreibt gleich eine eigene Abfragesprache. Oder er muss einen hauseigenen MusicMaster programmieren, aber auch das hat er schon mal negativ beschieden.

Vor ein paar Jahren gab es auch schon mal die Aussage, er müsste quasi die gesamte DB in den RAM laden, dort die gewünschten Parameter abfragen und verknüpfen - und das jedesmal! Irgendwann geht dann natürlich auch das von Hause aus ressourcen-“unhungrige” mAirList in die Knie und nimmt den PC gleich mit.

Wir reden hier über einen Mini-Scheduler, der für eine handelsübliche Musikplanung auf einer lokalen Datenbank überraschend viel kann.
Mehr geht immer: Wir arbeiten selbstverständlich gut und gerne mit MusicMaster zusammen und können diese Musikplanung auch hervorragend in mAirList integrieren.

Torben liest das hier mit. Ich habe zwar (noch) keine Antwort von ihm, aber zuletzt ging die Tendenz Richtung “dann löst es halt mit MusicMaster; wir machen denen keine Konkurrenz und haben das auch gar nicht vor, weil es viel zu komplex ist”.

Im übrigen werden wir uns vom Tagging der Feature Requests trennen, weil wir unerwartet feststellen mussten, dass sich daraus eine Art “Erwartungshaltung” entwickelt hat und wir uns damit nur selbst unter Druck gesetzt haben. Das kann nicht das Ziel sein.
Wir freuen uns über Anregungen aus der Community und greifen diese bei Gelegenheit auch auf, wenn sie aus der Sicht des Programmierers realisierbar sind und sinnhaft erscheinen.

Wir haben sogar mit dem Gedanken gespielt, die Feature Requests komplett abzuschaffen und Torben führt eine private, inoffizielle Liste für sich weiter (die noch nicht mal ich kenne).
So ganz vom Tisch ist die Idee übrigens noch nicht.

Das leuchtet mir nicht ein. Wenn ich „Alles“ anzeigen kann, dann kann ich auch „Alles, aber länger als dreidreißig“ anzeigen.

Na, super. Und damit kann man dann auch per Hand in der mAirList-Datenbank einen Titel finden? Der Scheduler ist mir relativ egal. Ich wollte lediglich eine Lanze brechen für bessere Suchmöglichkeiten.
Aber ok, ich habe verstanden.
Besser mit workarounds arbeiten…

So, jetzt wird’s Obstsalat…

@calypso60
Angefangen hatten wir mit der Musikplanung; bei @CoolSpot war’s die Automation. Na schön.
Da gibt es ein klares “Nein, sorry”.

Du kommst jetzt mit händischer Musikplanung und einfacheren Suchmöglichkeiten.
In #3 hatte ich schon Möglichkeiten aufgezeigt: Suchparameter oder eben nach Attributspalten in der Bibliothek sortieren.

Und im Grunde ist’s wumpe ob die Suche händisch oder automatisiert erfolgen soll:

Musikvorlage AND

So etwas (als Beispiel: Titel darf nicht deutsch oder englisch sein) geht leider nicht.

Eine spannende Frage hingegen wäre tatsächlich, ob man die Attribute im Filter nicht nur von Standards ausgehend, sondern auch freihändig eintragen könnte - sowie, darauf aufbauend, ein Attribut mehrfach einsetzen kann:

Sprache=!eng
Sprache=!ger
Sprache=!mul
Sprache=!zxx

(also alles außer englisch, deutsch, gemischt und Instrumentals)

Haken an der Sache: Jetzt müsste mAirList nur noch wissen, ob das AND oder OR-Verknüpfungen sind.

Was ich persönlich als Sahnehäubchen richtig geil fände: Wenn unsere virtuellen Ordner (optional!) automatisch nach festen Regeln bestückt werden könnten.
iTunes nennt so was “intelligente Wiedergabeliste”:

iTunes intelligente Wiedergabeliste

Aber auch da dürfte beträchtlicher Aufwand dahinterstecken. Das ist allerdings eine reine Mutmaßung von mir. Ich bin nun mal kein Programmierer.

Der Zusammenhang, auf den du dich beziehst, stammt aus einer komplexen Verknüpfungs-Anforderung. Vielleicht finde ich’s heute Abend, dann poste ich den Beitrag. Aus dem Gedächtnis, unscharf: Auf den Titel A27 darf keinesfalls ein weiterer Titel aus der Kategorie A folgen.
Und weil’s so schön ist, am besten noch stundenübergreifend.

Entschuldigung, aber habe ich was verpasst? War das in dem Thread bislang eine Anforderung, die ich versehentlich übersehen haben sollte?

Das geht mit diesem Tipp.
Wenn du also nach 3:30+5400 (5400 Sekunden = 90 Minuten, als Beispiel) suchst, sollte das gewünschte Ergebnis zu erreichen sein.

Herrje, dann also meinetwegen „alles, was mehr als 124 BPM hat“. Die Einheit ist doch egal, es geht ums Prinzip!
 

Was ist an „dreidreißig“ nicht zu verstehen? Drei Minuten und dreißig Sekunden sind 180 + 30 Sekunden sind 210 Sekunden.

Wenn ich also, wenn ich Dich richtig verstehe, Titel mit einer Spieldauer über 210 Sekunden schon suchen (finden) kann, warum nicht solche mit einem Tempo größer 124 BPM?

… und warum nicht solche mit Jahr > 1981 UND < 1987 ???

P.S.: Die Methode “alle anzeigen und dann nach Jahr sortieren” dauert bei mir (gerade gestoppte) 68 Sekunden. Das scrollen zum entsprechenden Jahr noch nicht mitgerechnet.

Das weiß nur der Programmierer.
Schauen wir jedoch über den Tellerrand hinaus, müssen wir die Frage stellen, ob das nur für numerische Wertepaare gelten kann oder nicht auch mehr (alphanumerisch, und, falls ja, wie?).

Außerdem bekommen wir dann immer noch nicht die angenommene Anforderung …

Titel ist zwischen 128 und 132 BPM “schnell”

… eingefangen.

So, nu isses aber mal gut.

Ihr habt’s geschafft, ich mache das Forum für dieses Wochenende für mich zu.
Ich engagiere mich ja wirklich gerne auch in meiner Freizeit hier und bin echt gern außerhalb meiner Arbeitszeit für die Community da, aber wenn wir uns anfangen im Kreis zu drehen vom Typ “Es geht nicht” - “Aber warum nicht?”, dann verschwinde ich halt im Musikarchiv, widme mich stärker der Parteiarbeit oder sende vielleicht mal wieder im Webradio und mache die Arbeit “mAirList” eben nur noch zu vertraglich vereinbarten Ansprechzeiten und als Dienst nach Vorschrift.
Finde ich persönlich zwar sch***, aber: Bitte.

Tut das echt Not?

Ich bin raus: Uli, :rage:

Bisher ist das eine AND und das ist gut so.

Im Grunde ist ja das ein ! schon implementiert, um einen Wert zu negieren.

Könnte man nicht zb einfach ein : ebenfalls auswerten und daraus ein “Between” draus machen?

Also ein Filter 1992:1999 macht ein simples
“between 1992 and 1999” im SQL Syntax draus?
(zumindest dann, wenn es numerische Werte sind)

Dann wäre doch vielen geholfen, oder übersehe ich etwas?

Uli, geht’s noch?
 

Alphanumerische Zeichen lassen sich genau so sortieren wie numerische. Die Idee hattest aber Du jetzt.

Hier mal ein Beispiel, wie man so etwas lösen könnte.
Hier kann ich beliebige Felder der Datenbank mit allen gängigen Kriterien abfragen. Mehrere Einträge sind automatisch UND-Verknüpfungen. Desweiteren kann ich ODER-Verknüpfungen realisieren und durch Klammern Kombinationen definieren.
Aus meiner Sicht Idiotensicher.
Solche Filter müsste man in mAirList speichern können. Dann könnte man nach Herzenslust dynamische virtuelle Ordner erzeugen.

ml7-suchfilter1

ml7-suchfilter2

Und schwupps habe ich alle Titel aus 1981 bis 1985, die drei bis dreieinhalb Minuten lang sind und französisch oder italienisch gesungen werden.

Aber da hier ja offenbar nicht nach Gesamtlösungen gesucht wird, sondern man sich lieber im klein, klein verstrickt, bin ich jetzt auch raus.
@UliNobbe schaue doch auch ab und zu mal über den Tellerrand

Und nun zum Abschluss:
Ich werde mich vorerst hier nicht mehr mit Vorschlägen zu Wort melden.
Auch ich kann meine Zeit sinnvoller nutzen…

Auf Wiederhören

1 Like

Das heißt im Klartext, ich soll mir bitteschön zusätzlich eine Software beschaffen, die mich fast 1.500 Euro pro Jahr kostet?! Ist das kundenfreundlich?

Wir freuen uns immer über Ideen und Anregungen. Zumal die allermeisten Dinge immer sehr nachvollziehbar und sinnvoll sind. Leider ist der begrenzende Faktor immer die Zeit, und ich muss immer schauen, was gerade realistisch umzusetzen ist und was nicht.

Die hier vorgeschlagene erweiterte Suchfunktion wäre natürlich eine nette Sache. Aber ich zähle nur mal die Schritte auf, die notwendig sind, um es umzusetzen:

  1. Eine “Anfragesprache” ausdenken (welche Operatoren, Klammern, Felder, Werte, etc. sollen erlaubt sein?)

  2. Eine Übersetzung der Anfragesprache nach/von JSON definieren (JSON wird intern als Übertragungsformat zwischen Datenbank-Backend und Anwendung benutzt).

  3. Eine Übersetzung der Anfrage in ein SQL-Query programmieren - wie oben schon dargelegt wurde, will man ja nicht im RAM filtern, sondern schon auf SQL-Ebene. Hier ist die Besonderheit, dass die Daten wegen mAirList’s dynamischem Attribut-System über mehrere Tabellen verteilt sind, wir haben es also mit sehr, sehr vielen JOINs zu tun. Hätten wir nur 20 feste Felder, wäre alles einfacher :wink:

  4. Last but not least, die ganzen GUI-Dialoge programmieren, in denen sich der Benutzer die Anfrage zusammenklicken kann. Das ist erfahrungsgemäß die meiste Arbeit.

Also ein paar Tage sitzt man da schon dran. Und die paar Tage habe ich aktuell nicht. (Gerade wieder 30 Minuten draufgegangen, um diesen Beitrag zu schreiben.)

Aber ich behalte es im Kopf.

Und noch zum Thema MusicMaster: Da habt ihr etwas aneinander vorbei geredet, glaube ich. Die ursprüngliche Frage bezog sich ja auf eine vom Benutzer definierte händische Suchfunktion. Das andere Thema, solche Suchfilter mit in die automatische Planung einzubeziehen, steht noch auf einem anderen Blatt. Und hier gibt es grundsätzlich eine natürliche Grenze, an der meine bescheidenen Fähigkeiten und Algorithmen tatsächlich nicht mehr ausreichen und ich auf die Möglichkeit verweise, eine dedizierte Musikplanungs-Software wie MusicMaster als “Plugin” in mAirList zu integrieren.

1 Like

Vielen Dank für die ausführliche Antwort. In meinem IT-unerfahrenen Hirn spukte halt der Gedanke: Wenn ich eine Abfrage auf alle Titel mache, geht das ja problemlos: Alle Titel werden angefaßt und ins Fenster geschrieben. Wenn ich jetzt dasselbe mache, aber nur die ins Fenster schreibe, die dabei länger als dreidreißig sind, erscheint mir das nicht so kompliziert.

Denke ich.

Ich.

Das wäre das besagte “Filtern im RAM”, also erstmal die ganze Liste laden, und die nicht passenden Titel ausblenden. Aber wie lange das Laden der Gesamtliste dauert, siehst du ja, wenn du links im Baum auf “Alles” klickst. Und wir haben Kunden mit teilweise sehr großen Bibliotheken (100.000 und mehr Einträge).

Da ist es sinnvoll, auf die Filter-Funktionen von SQL zurückzugreifen, so dass von vornherein nur die passenden Titel ausgespuckt werden. Aber dazu muss “unsere” Anfragesprache eben in SQL übersetzt werden.

1 Like

Auch von mir ein Dank für die Hintergrundinformationen.
Ich bin ja nur Datenbank-Anwender und habe mir das auch einfacher vorgestellt. Schon bei meiner ersten Tonträger-DB (F&A für DOS v. Symantec) konnte man (Mitte der 80er) mehrere Filterkriterien anwenden. Daher kommt wohl meine naive Ansicht, dass so etwas grundlegende DB-Funktionen sind.

Kann ich bestätigen. Ich habe aktuell 190.079 Einträge. Anzeigedauer für alles ca. 55 Sekunden - wenn die Datenbank frisch “Vacuumiert” ist.

Grundsätzlich sind es die, ja. Die Herausforderung besteht immer darin, das, was der Mensch (User) möchte, in die Sprache des Computers zu übersetzen. Das fängt bei den GUI-Dialogen an und endet dort, wo man es in die entsprechenden SQL-Anfragen übersetzt hat.

Und unser (schönes) System mit den frei definierbaren Attributen macht es wirklich kompliziert.

Deine alte Datenbank aus den 80ern hatte vermutlich feste Spalten wie Interpret, Titel, Jahr, Genre, etc.

In der mAirListDB stehen nur die Stammdaten (ID, Titel, Interpret, Länge, etc.) in der Haupttabelle items - die anderen Felder, eben was du auf dem Reiter Attribute erfasst, stehen in einer zusätzlichen Tabelle item_attributes, und zwar jeweils als Tupel (Titel-ID, Attribut-Name, Attribut-Wert).

Bei Suchanfragen muss man diese Tabellen dann miteinander verknüpfen - Fachjargon: JOIN - und zwar im Zweifel auch mehrfach. Das macht die SQL-Anfragen sehr komplex.

Wie gesagt, alles theoretisch möglich, aber erfordert Zeit, die nicht immer vorhanden ist.

Off-topic: Konntest du in der v7 bemerken, dass sich die Ladezeiten verkürzt haben? Sollten sie.

1 Like

Aha. Sehr einleuchtend.