I'm in for $38 (just sent w/ Paypal). I'd love to contribute to this project at some point as well, if I ever I find the time.
Best posts made by thenoblesunfish
-
RE: macOS support
-
Query the Strawberry database to get filenames for a given playlists?
A somewhat whimsical thought, but: before discovering Strawberry I was using a pretty low-level approach of mpd + ncmpcpp and bunch of homebrewed scripts to do things like transfer music to my phone (where I play it with PowerAmp). Maybe there's already a good way to transfer music to my phone (from OS X to an Android (Fairphone) phone) with Strawberry - all ears if so! But assuming there isn't, it seems like maybe I could just do something like
- Put a list of the playlists I want to sync in a text file
- Run a query directly on the Strawberry db to dump out the filenames (in order) of files in playlists with matching names
- Use that to generate .m3u files
- Use my existing scripts to move the files and .m3u playlists to the phone
Is the step about the query reasonable? I'd just want to be able to query for all the songs in a playlist with a given name. Perhaps I could even crib from the source code to export a playlist.
-
Getting used to starred playlists and playlist tab bar
I'm still getting used to using Strawberry, and I don't understand the tab bar of playlists or why there are un-starred (unsaved) playlists.
I'm biased by my iTunes usage, to be sure, but it seems like it'd be simpler and more usable if:
- all playlists were starred (saved) and appeared in the side bar - I can read the full names there, and I can nest them in folders if there are a lot.
- I could click once on one of the playlists (or smart playlists) in the side bar, and have that appear in the main portion of the window, like iTunes.
- the currently-playing playlist (or its folder) was marked with a the play icon in the playlist sidebar
- "Add to another playlist" worked for any (non-smart) playlist, not just one of the ones that happen to be open in the tab bar.
Am I missing useful properties of the interface as it is? Is the alternative approach above reasonable or even preferable but difficult/low-priority to implement?