Winamp SDK and control by python

[bobdobbs]

I was having a look at some automation of winamp, with the aim of grabbing screenshots of the GUI, to compare how it looks natively and under Wine (and be able to easily regenerate them each time a new version arrives)

This (ancient) python winamp control library amazingly still works
https://github.com/hugovk/winamp

It
> Uses the winamp api http://www.winamp.com/nsdn/winamp2x/dev/sdk/api.jhtml
> and windows messaging to control winamp.

On the other hand it's incomplete and uses magic numbers from the SDK.
Where can I find an up to date version of the SDK, and is this even a sane approach ?

I had a look into autoit, but that looked like a bit of a pain (though it does have python bindings which is something).

[bobdobbs]

Ah, found the SDK

http://download.nullsoft.com/winamp/plugin-dev/WA5.55_SDK.exe

(this is extractable without running the exe).

[dro]

There's also some newer stuff at https://getwacup.com/sdk/ but it's all a bit of a mess at the moment but going with the 5.55 copy & updating the files should cover up to 5.666.

However most of the Winamp api side of things is just simple SendMessage() calls (which allows a lot of the old control aspects to still work) unless you're running as a native plug-in where you can do some more stuff but it's nowhere near like the fb2k sdk (which is a modern version of what Winamp3 was trying to provide) where everything is properly defined.

-dro

[mveroukis]

Perhaps I mentioned this already, but I think many would benefit if this (ie. the SDK itself) was hosted on github. I don't think it's the sort of thing anyone would consider forking, but having it up in a place like that makes it a lot more accessible and discoverable - and not just for the SDK itself but for WACUP as well.

[dro]

it's all a bit of a mess at the moment

Indeed & it's on the 2020 hit list. Main thing is I need to clean-up what I've got & have generated for WACUP (*) vs what is out there from older SDKs (which makes sense to keep around).

-dro

(*) Which isn't SendMessagey but goes more towards library linking which I know some will despise / can't use but it works better for the core though I'll have to expand some of the SendMessage API to make things easier. It also is why trying to improve command-line support & what can be done by that is probably better since trying to make a plug-in isn't worth the effort in a lot of cases vs skill sets & how modern devs do it

[mveroukis]

I hear ya. There might still be benefit for it to be there sooner (as opposed to where it is now) as it also allows us to track changes over time.

Anyway, I was toying around with my Ampwifi plugin. Are you saying there's a new api/sdk on the horizon that I should wait for?

[dro]

Most of my changes won't really make a difference to anyone making a plug-in now as they're more convenience changes but as I'm trying to maintain backwards compatibility things should still "just work". If wanting to lock down to just working in WACUP instead of other Winamp versions then it'd be needed but most won't care about having some of the wasabi services & a few other things pre-provided depending on the type of plug-in.

Tbh the main things that help for any plug-in & aren't linked to any version of the SDK is only loading settings when needed, not re-saving settings that haven't changed (i.e. just change them when changed via the config) & not having a lot going on in init(..) unless needed (i.e. a lot of things can be done a bit later in loading than immediately which makes the player more responsive on loading).
-dro

[mveroukis]

I've been using the wa_ipc messages. I noticed there's also a wasabi folder in the original winamp sdk but not in the one under getwacup.com/sdk. Is that a sign that I'm on the right track?

As for the init(), ya, my plugin spawns it's own thread so not much going on there.

[dro]

It depends on what's needing to be done as the wasabi services are used for a number of things (e.g. interacting with the library playlists). What's on the site /sdk page was only ever meant as a small subset of newer files related to 5.666 to go on top of an existing 5.55 SDK install.

Anyhoo, I've just done a bit of collation on the SDK files today & will be trying to do something every day over the next few weeks just to get things to a point where it can be put on github, etc instead of being all over the place as everything currently is.

-dro