Use generated playlists as input playlists in playlist generator

[jonasgantner]

Im Playlist Generator eine Generated Playlist als Input Playlist verwenden können. (aktuell ist nur liked playlists und meta input möglich)

sonstige, nicht so wichtige features: Die Navigation zu den einzelnen Views (Login, Song Tagger, Playlist Generator) in den Header (z.B. als Tabs) einbauen anstatt über das öffnen der sidebar.

Add Tag button und Add Tag Group als eigene buttons darstellen, nicht erst im dropdown auswählen

Counter anzeigen im Song Tagger Tab (jeweils Anzahl an Liked Playlists, Generated Playlists, Liked Songs, ... hinter den Text in Klammern)

Zahlen hinter den Namen der Nodes im Playlists Generator entfernen (oder haben die einen spezifischen Sinn für den Nutzer?)

Suchleiste im Song Tagger einbauen

[BenediktAlkin]

Danke für dein Feedback!

Eine Generated Playlist als Input Playlist zu erlauben ist zwar technisch möglich, hat aber aus meiner Sicht zu wenig Nutzen für die Komplexität die dabei eingeführt werden müsste. Aktuell ist es so, dass das Programm 2 Arten hat wie die Musikbibliothek mit Spotify synchronisiert wird.

• Liked Songs und Liked Playlists werden in den Song Tagger eingelesen (Sync Library Button)
• Ein Playlist Generator wird ausgeführt und erzeugt die Playlist von der lokalen Musikbibliothek auf Spotify Das hat den Vorteil, dass der Playlist Generator immer auf dem aktuellen Stand der lokalen Musikbibliothek ist (relevant für z.B. die ArtistFilterNode) und muss nichts im Hintergrund von Spotify herunterladen/nachsehen was u.a. einige Zeit dauern könnte und somit den Playlist Generator "laggy" machen würde. Dazu kommen noch weitere Probleme, wie z.B. dass man dadurch rekursive Abhängigkeiten der Playlists erlaubt.

Derzeit kann man Generated Playlists quasi auch als Input nehmen, indem man den den Knoten der mit einem Playlist Output Knoten verbunden ist einfach zu weiteren Knoten verbindet welche wieder in einen Playlist Output führen können.

Die Navigation halte ich in der aktuellen Version für ganz gut, da wenn man diese in den Header einbaut schnell mal Platzprobleme entstehen wenn man den Song Tagger nicht als maximiertes Fenster verwendet.

Die Zahlen hinter den Nodes identifizieren die Node eindeutig. Das ist zwar in den meisten Fällen irrelevant, aber bei der Remove Node benötigt man diese wenn man zwei gleichnamige Nodes als Input hat. z.B. zwei Liked Playlist Inputs führen in eine Remove Node, dann weiß man ohne die Ids nicht welche von welcher entfernt wird.

Counters hinter Playlist Gruppen/Playlists und eine Suchleiste sind gute Vorschläge. Sind notiert aber haben keine hohe Priorität.

[outOfBoun]

Hi! I like this project, but having this functionality would be great.

I wanted to use it in a way that can help me filter out songs out of an unsorted playlist. Songs that can be assigned to some other playlist are "moved", while the ones that fail to be filtered by existing rules are "left in place". This would require having an output playlist work as an input playlist and vice-versa. But I don't think it would require a recursive approach. Just having the static state at initialization should be enough for my use case. Although I can see that enabling this and using it for more complex use cases could lead to problems if the user expects something else regarding how playlist state gets refreshed during execution. (as said above, it won't get refreshed during that execution).