Not an issue, but a suggestion

[ClaireCJS]

Where are suggestions supposed to go on github? Here?

I'm requesting the addition of a now-playing.m3u or txt that is the filename of the song currently being played.

I'm working on a winamp monitor that works on those $13 usb-lcd screens (check out turning_smart_screen-python project). And since I want to use it from other computers that don't have direct access to winamp, i rely on the plugin for fetching the album art and song title info. I can fetch them via win32 calls if winamp is on the same computer, but not if it's on a different computer.

Same thing for finding the filename. It can be done (but i haven't done it) by querying winamp to return the playlist, then the position in the playlist, then examining that entry. But even that is more resource [and development] than if your plugin simply exported the filename as a 3rd file, and that solution only works on same-machine, not on a different machine. Currently i have to parse last.fm logfiles which is very ugly because they change their logfile format approximately every 3 years and it's been a big deal every time they've done this in the past 16 years.

TL;DR — Your plugin replaces some internal functionality i had, but for me to truly be able to fetch everything i want out of winamp from another computer, life would be a LOT easier if your plugin exported a 3rd file. txt, png, and m3u for the filename.

Any chance we could do that? I imagine it's at most... 5 lines of code, if that. I recognize that i could maybe do it myself but .. i don't want to make forks. I want to continue to rely on your instance of this project rather than making my own, because, quite frankly, I have my own projects to manage and want to do the least work possible, as i'e already spent about 30 hours on this winamp screen thing hahahaha.

[ExecThTs]

I have a PR that implements a feature that could help you: #17

See the multitemplate branch of my fork for details.

[Aldaviva]

Hi @ClaireCJS,

Yeah this is the right place for suggestions. And yes we can do this.

1. To store the currently playing file path in a different text file from the other textual metadata, I would need to review and merge @ExecThTs's pull request and release a new version. It's a useful feature, I just got overwhelmed by the size of the change so I've been putting it off and forgetting.
2. If you are able to extract substrings in whatever process is consuming this text file, you could do something like putting the file path on the first line of the existing text file, before the rest of the metadata, and then splitting on CRLF when reading it. This can be done today with the current release of this plugin, using the Filename placeholder. So a template like

   {{Filename}}{{#newline}}{{Artist}} - {{Title}}

   would render a text file that looked like

   C:\Users\Ben\Music\mysong.mp3
   My Artist - My Title
   

   I'm not sure if putting the filename in the same file would work for your setup though.

[ClaireCJS]

I can get what I want today?!?!?!?!?!

Even better!

And yes, that format would work, since I'm writing the ingest code myself, easy to do whatever with it :)

Oh my gosh. The more I use this place the more I love it.

It's hard to express how grateful I am for this!

[ClaireCJS]

Well shoot, I don't know how I missed that.

There's a ton of values! Holy moly! I'm gonna stick a ton in the file and figure out what to do with them later! I'm a little embarassed that I missed the obvious button because I was rushing towards my goal too fast. You rock!

[Aldaviva]

Hell yeah, glad it works for you and that you're enjoying it here so much!

For a full list of available placeholders along with example values, conditional logic, and value formatting, see the Configuration › Text section of the readme. It includes everything I was able to make Winamp cough up.

[ClaireCJS]

I stuck a ton in.

Totally curious if {subtitles} is going to give me access to something akin to an LRC file because then i could display the lyrics in every room [with a computer] in my house!!!

Since I use minilyrics, i believe a lot of my lyrics are directly embedded in the file. But if they aren't, they are sidecar files just having a different extension, so i could get to them that way too as a secondary.

I should prbobably read the docs. I go full Leroy Jenkins into project sometimes

[Aldaviva]

So far I haven't found a file that makes Winamp return any lyrics based on some quick testing I did, but I didn't try too hard.

[ClaireCJS]

There's definitely a reason I tell minilyrics to embed the lyrics AND save them as a sidecar file in the same folder! I can read them without having to go directly through winamp then, thanks to {filename} being exposed in this most-excellent plugin that i've needed in my life for well over 20 years.

[ClaireCJS]

If you make the lyric accessible... I'll integrate them into my winamp dashboard project. The draw rate is really slow on these $13 5" screens (about 0.4fps) so it might be a bit janky or maybe i'll literally use a smaller font size so it can keep up (it's that bad! haha), but it seems like something super fun to try, because then i could expose lyrics-on-a-screen in other rooms of my house [that have a pc] for a mere $13.

[Aldaviva]

I can't find a way to make Winamp return the lyrics, and it actually seems like Winamp itself does not even handle lyrics outside of certain decoders. Therefore it seems like the best options are for you to either read the lyrics from the sidecar file or parse them from the audio file, both based on the current filename.

[Aldaviva]

Released beta version with all in-progress work: 3.0.0.0-beta.1. I haven't found any bugs in it, but if you do please let me know.