Winamp 5.55 SDK

[iccle]

Sure Dro, but since those constants (in the beta SDK) have now been removed from <winamp/wa_ipc.h> i just wanted to let you know that i had noticed that name change, as it broke some code i compiled in order to test the beta SDK, which worked in previous SDK's.

Aint no biggie

[abu]

I think I found a bug in this SDK. There was a subtle change in ml_lib.cpp, which was wrong as far as I can see:

code:
diff U3w D:\down\Winamp\SDK\gen_ml\ml_lib.cpp C:\Program Files\Winamp SDK\gen_ml\ml_lib.cpp

--- D:\down\Winamp\SDK\gen_ml\ml_lib.cpp	Thu Aug 19 17:52:36 2004

+++ C:\Program Files\Winamp SDK\gen_ml\ml_lib.cpp	Tue Feb 14 22:46:16 2006

@@ -116,7 +116,7 @@

   {

     if (!stricmp(item->extended_info[x],name))

     {

-      if (strlen(value)>strlen(item->extended_info[x]+strlen(name)+1))

+      if (strlen(value)>strlen(item->extended_info[x])+strlen(name)+1)

       {

          ...

As you see, the braces have been moved. But the old version was right: We want to compare the length of the new value to that of the old value. And that can be found at address "item->extended_info[x]+strlen(name)+1". In the new version, we compare the length of the new value with the length of the name (at item->extended_info[x]), plus again the length of the name, plus 1. Makes no sense, right?

[shaneh]

You seem correct about that. It appears to be a regression, as my old 5.04 SDK has the buggy code too. It must have been re-introduced at some point.

[Benski]

Originally posted by abu
I think I found a bug in this SDK. There was a subtle change in ml_lib.cpp, which was wrong as far as I can see:

code:
diff U3w D:\down\Winamp\SDK\gen_ml\ml_lib.cpp C:\Program Files\Winamp SDK\gen_ml\ml_lib.cpp

--- D:\down\Winamp\SDK\gen_ml\ml_lib.cpp	Thu Aug 19 17:52:36 2004

+++ C:\Program Files\Winamp SDK\gen_ml\ml_lib.cpp	Tue Feb 14 22:46:16 2006

@@ -116,7 +116,7 @@

   {

     if (!stricmp(item->extended_info[x],name))

     {

-      if (strlen(value)>strlen(item->extended_info[x]+strlen(name)+1))

+      if (strlen(value)>strlen(item->extended_info[x])+strlen(name)+1)

       {

          ...

As you see, the braces have been moved. But the old version was right: We want to compare the length of the new value to that of the old value. And that can be found at address "item->extended_info[x]+strlen(name)+1". In the new version, we compare the length of the new value with the length of the name (at item->extended_info[x]), plus again the length of the name, plus 1. Makes no sense, right?

I fixed this bug internally in 5.3x, here's an updated (but still beta) SDK - http://download.nullsoft.com/winamp/beta/WA5.32_SDK.exe

[shaneh]

Thanks for the new SDK benski, some interesting stuff in there. For the menu id request API.. would it be possible to have it take a number of ids required? such that it returns a starting ID, and will have reserved that many ids in sequence?

If not, is it safe to assume that requesting 10 ids in a row would return them in a linear sequence? (obviously requesting them all before handing back control to the message pump).

[Benski]

Shane - for 5.33 I will increment the number by wParam when you call IPC_REGISTER_LOWORD_COMMAND. It will return the first number in the series.

For 5.32 - You can safely call it 10 times, assuming of course you on the main thread (e.g. during your init() call)

[shaneh]

Thanks Benski, that should help out with a few things. Can we use this function to allocate timer ids too? Otherwise an API for that would be good, or just picking random numbers as usual :P No biggy.

My main gripe is with the ATF functionality. Its great that the new IPC_FORMAT_TITLE_EXTENDED does a bit of work, but it doesn't seem to do much.

For example, it doesn't handle %rating% or %playcount% etc. Would it be possible to have something like a IPC_FORMAT_TITLE_EXTENDED_2 which tells winamp that the *p in waFormatTitleExtended is pointing to an itemRecordW, and therefore use that to do the tag processing? Or maybe returning -2 from *TAGFUNC tells winamp the same thing.

Or better still, instead of just querying the input plugins for %tags%, it actually does the full ATF processing? (I assume involving an ML lookup etc) This way any plugins that do ATF processing will automatically be future proofed against new %tags% supported in winamp, and not require much (re)implementation on behalf of plugins. This would be the preferred option I think.

[Benski]

Originally posted by shaneh
Thanks Benski, that should help out with a few things. Can we use this function to allocate timer ids too? Otherwise an API for that would be good, or just picking random numbers as usual :P No biggy.

Sure, but this will take a bit of extra work, because timer IDs were typically picked by banging on the number pad (i.e. there's no good logic to their numbering)

My main gripe is with the ATF functionality. Its great that the new IPC_FORMAT_TITLE_EXTENDED does a bit of work, but it doesn't seem to do much.

For example, it doesn't handle %rating% or %playcount% etc. Would it be possible to have something like a IPC_FORMAT_TITLE_EXTENDED_2 which tells winamp that the *p in waFormatTitleExtended is pointing to an itemRecordW, and therefore use that to do the tag processing? Or maybe returning -2 from *TAGFUNC tells winamp the same thing.

Or better still, instead of just querying the input plugins for %tags%, it actually does the full ATF processing? (I assume involving an ML lookup etc) This way any plugins that do ATF processing will automatically be future proofed against new %tags% supported in winamp, and not require much (re)implementation on behalf of plugins. This would be the preferred option I think.

To be honest, IPC_FORMAT_TITLE_EXTENDED was written for the particular needs of the Media Library (ml_local), although it's likely useful for some third party developers. If you can send me specifics on what you need out of the ATF engine, I can try to implement something to fulfill those needs.

Also of note, there is a (hidden) API to use the ATF engine directly, w/o going through a SendMessage call. At the moment, it doesn't let you do much extra, but I am considering adding things to it like defining your own custom functions and prepopulating (or retrieving) the $put/$get variables. If you have any interest in this, let me know.

[shaneh]

Sure, but this will take a bit of extra work, because timer IDs were typically picked by banging on the number pad (i.e. there's no good logic to their numbering)

Thered be quite a few plugins out there that use random numbers already so I wouldn't go changing internal timer ids to liberally. Perhaps just find a big range of non-used ids and allocate from there, youd most likely only hand out 100 or so at most.

IPC_FORMAT_TITLE_EXTENDED was written for the particular needs of the Media Library (ml_local), although it's likely useful for some third party developers. If you can send me specifics on what you need out of the ATF engine, I can try to implement something to fulfill those needs.

Also of note, there is a (hidden) API to use the ATF engine directly, w/o going through a SendMessage call. At the moment, it doesn't let you do much extra, but I am considering adding things to it like defining your own custom functions and prepopulating (or retrieving) the $put/$get variables. If you have any interest in this, let me know.

The reason Im using this API is to allow wchar formatting. Basically I want to allow for ATF formatting in the same way that winamp can do it for the playlists, without having to handle all the tags myself. Itd also maybe handle some stuff like '%streamtitle%' which isn't that easy to implement in a plugin.

It'd be great to not have to worry about changes to the ATF tags and ML etc and just let winamp do it. Perhaps you could set useExtendedInfo to '2' to tell winamp to do "full" ATF processing.

I assume the 'hidden' ATF API is the tagz.w5s service? I havent used the wasabi interfaces before, I hope they still work with classic skins?

The new functions cover most of what I have implemented myself through %tag% hacks, which i intend to depreciate :P but I wouldnt mind implementing a kind of regex replace function for getting rid of radio stream taglines. eg:

$regex('s/\(.*\)$//', %streamtitle%)
or:
$regexreplace('\(*\)$', '', %streamtitle%)

To remove the brackets from:

songname - artist (104.fm hits)

It may be possible with existing tags with $right, $left, $strchr etc but would be difficult. If not full regex, even something simple such as:

$removetagline('(', ')', %streamtitle%)

would be good (and could also handle nested brackets without some complex regex line). Ive had quite a few people ask how to get this done. Id probably implement this myself if you exposed the API to the tags service.

[Benski]

With IPC_FORMAT_TITLE_EXTENDED and waFormatTitleExtended::useExtendedInfo == 1, if you return 0 from your tag function, it will cause Winamp to go lookup the tag through IPC_GET_EXTENDED_FILE_INFOW_HOOKABLE (which is what ATF is using to resolve %tags% in the playlist titles, save for "filename" and "folder").
Returning -1 just means "empty tag" and is mainly used to avoid mallocing an empty string.


p.s. I'll post an example soon of how to use the tagz.w5s service directly

[shaneh]

Yes I'm pretty sure I am using IPC_GET_EXTENDED_FILE_INFOW_HOOKABLE correctly, it formats every other tag fine. It just fails to format %rating% and %playcount% even though these are formatted fine in the playlist. It seems the ML isn't hooking these calls.

Some other tag functions I wouldnt mind implementing are $color and $font for Toaster, although whether thats necessary depends on whether I decide to use HTML or not.

[Benski]

Originally posted by shaneh
Yes I'm pretty sure I am using IPC_GET_EXTENDED_FILE_INFOW_HOOKABLE correctly, it formats every other tag fine. It just fails to format %rating% and %playcount% even though these are formatted fine in the playlist. It seems the ML isn't hooking these calls.

Some other tag functions I wouldnt mind implementing are $color and $font for Toaster, although whether thats necessary depends on whether I decide to use HTML or not.

Quick question before I debug this. In Prefs->Local Media, is "Use Library title information for Playlist Item Formatting" checked or not?

[shaneh]

Yep its enabled. The playlist allows using %rating% etc fine so I suspect its being used.

[Benski]

Looks like it's a bug in ml_local and not in the IPC_FORMAT_TITLE_EXTENDED API. It will be fixed in the next version. Thanks for the heads up and sorry about the confusion.

For reference, here's an example of how to use IPC_FORMAT_TITLE_EXTENDED

code:


static wchar_t *TagFunc(const wchar_t * tag, void * p)

{

	if (!lstrcmpiW(tag, L"test"))

	{

		return L"<<WORKING>>";

	}

	else

		return 0;

}

 static void TagFree(wchar_t *tag, void *p)

{



		 // nothing

}



static void QuickFormat(char *blah)

{

	waFormatTitleExtended fmt;

	wchar_t tempWideFn[MAX_PATH];

	wchar_t out[1024];

	MultiByteToWideChar(CP_ACP, 0, blah, -1, tempWideFn, MAX_PATH);

	fmt.filename = tempWideFn;

	fmt.useExtendedInfo = 1;

	fmt.spec = L"%artist% - %title% - %playcount% - %test%";

	fmt.p = 0; // don't need context

	fmt.out = out;

	fmt.out_len = 1024;

	fmt.TAGFUNC = TagFunc;

	fmt.TAGFREEFUNC = TagFree;

	SendMessage(plugin.hwndWinampParent, WM_WA_IPC, (WPARAM)&fmt, IPC_FORMAT_TITLE_EXTENDED);

	MessageBoxW(NULL, out, L"Results", MB_OK);

}

[shaneh]

Cool thanks Benski, itd be great not have to handle these myself, would %streamtitle% work too?.

Ive now got a C++ abstract framework in place to transparently switch between the different formatting methods depending on version. With the next release or beta I should be able to release gen_msn based on it, and just use the old ansi formatter for 5.32 (which manually does the %rating% lookups etc) rather than give that version special attention.

Mind you, my tag processing is probably a bit more efficient than letting the ML handle it, as I imagine it does a lookup for the file each time for every tag. Whereas I cache the itemRecord once and use it every time for the entire processing of the atf spec.

Itd also make ActiveWinamp much easier to code, and I can drop heaps of legacy code cause it will only target the most recent release.

So looking forward to it