Useful Info -> What info should you know when making plugins?

[DrO]

Finding those little extra bits of info for making your plugin can be hard especially when you don't know what you're searching for. Remember searching for hours to try and find out about something and fail So what should be done about this?


Well my thought is to add to the forum a "useful info" sticky which should point to relevant info, etc. As well i'm looking at providing example code for most of the api messages (taken also from examples other members have posted just to make it easier when you first start using the api) with an updated sdk installer coming in the next few weeks.

So what other info do you think should be made part of this sticky? Post here and i'll sort through it in the next few weeks as i finish doing the bits i'm working on.

-daz

[Petepan@london]

Empty plugins like the generic empty project for all types of plugins.

.. starting with the ml_type first

[DrO]

what about ml_ex in the sdk? though it needs some more documenting i think

-daz

[Petepan@london]

Yeah it does need more documenting and it is not exactly "Empty", but it is what I am using at the moment.

[DrO]

lol, no pleasing some people
point noted and i'll get a ml_basic added as soon as i can though for some of the plugins, you need the 'extra' parts in to see what's going on ie input, output and vis though ml and gen can be stripped to a basic level

-daz

[Petepan@london]

Hey, I am just being a helpful newbie .... giving you an insight in to the mind of a person who has no idea what he is doing but is still building a plugin

It is good to have both ml_basic as a foundation to build your own and ml_ex with all the 'extras' so you can see what you can do with it.

Buttom up building vs top down.

[DrO]

that's good since the aim is to help newbies get on without having to search for hours on end. the aim also is to have ml_basic, ml_ex and the original version of ml_www in there as well.

-daz

[shaneh]

Although not for a plugin as such, I think some info on how to do all the IPC calls from an external app would be nice, as I think quite a few people start off by writing an external app (even though its harder!). An explanation on these issues would be good too.

I also took part in a thread on how to catch song changes, which isn't really documented in the SDK. The newer 'PLAYINGFILE' or whatever IPC is only new, and doesn't catch http title changes. (the 666 message does though).

Some docs on how to subclass the various windows could be good. These issues are mainly for general plugins, theres probably heaps more for input/output/vis plugins.

@petepan: I think the ml_ex is probably pretty good as a basic skeleton type code. Its not too difficult to cull the stuff you dont need, but at the same time it provides a good framework for the stuff that many ml plugins would need. You were obviously able to get it going in a couple days, which is not bad considering how much effort goes into getting some other undocumented stuff going.

[DrO]

shaneh: i agree with you there, the number of times i've seen that over the few years i've been active/browsing it would make sense to have something on that (issue noted).

i'd better get browsing then

-daz

[torsius]

I posted some very simple code that provides a general interface for interacting with winamp from an external process that allows most (if not all) of the plugin api calls. I even included a sample vc++ project demonstrating how to use it, should help lots of folks out (even though noone responded to it in the thread )

here it is

[Lord Darius]

And once again, I think it would be appreciable if the WM_COMMAND parameters for winamp were in their own header file .

[DrO]

do you mean something like this?

-daz

[edit]

will need to comment out the defines in wa_ipc.h at the bottom for it to compile fine + fixed an issue with the header not compiling (v1.0a attached)

anyone noticed the typo mistakes in wa_ipc.h?

[/edit]

[DrO]

and another file sorted, i've gone through ipc_pe.h adding in some info with working example code as needed.

-daz

[Lord Darius]

you're doing a great work DrO, thanks a lot

[DrO]

Originally posted by Lord Darius
you're doing a great work DrO, thanks a lot

thanks

-daz

[shaneh]

Some useful info I found in the audioscrobblers sources. I knew about the 666 message, but this explains it a little better. It is relative to the PE window. Credit to Spib from the audioscrobbler plugin for this.


#define WA_STATE_CHANGE 0x0000029A

PEWndproc:
if(message == WM_USER)
{
if(wParam == WA_STATE_CHANGE)
{
int nType = HIWORD(lParam);
int nTrack = LOWORD(lParam);
// Ignore the double issue play message
if(nType != 16384)
return TRUE;
if(SendMessage(m_hWndWinamp,WM_WA_IPC,0,IPC_ISPLAYING) == 1)
{
DWORD dwNow = GetTickCount();
// Winamp Sends two quick song change notifications so
// here we check if the last notification arrived less than
// 400 milliseconds after the last in which case we ignore it.
if((dwNow - m_dwLastPlay) < 400)
{
// Ignore second notifcation
}
else
{
m_dwLastPlay = dwNow;
//Track changed
}
}
}


This is more useful than the 'PLAYING_FILE' IPC, as it also catches track changes within http streams. Be careful though, as it is called multiple times with http streams for the same title, so you need to check that it has actually changed.

I think the 'GetLibraryWndIPC' or whatever it is plus the other library ipc calls should be added in ml.h or somewhere. I have written up a brief summary under 'Unodocmented APIs' [sic].

[SarCaSM]

Something useful now might be a how to compile using the Microsoft Visual C++ Toolkit 2003 that they recently released for free. Command line how to I mean, dunno. thought it sounded like an ok suggestion.

[DrO]

SarCaSM: i'll see if i can have a play with it once i find and download it

shaneh: ta, will document that as well as my version in a bit. as for the ml header, i'll add them into the version i'm making though i'll see if we can get the devs to better document the ml.h file (saves me some work as well)

-daz

[DrO]

wa_hotkeys.h... another one done and ready to go
this should show how easy it is to add a global hotkey, enjoy

-daz

[Safai]

Originally posted by DrO
wa_hotkeys.h... another one done and ready to go
this should show how easy it is to add a global hotkey, enjoy

-daz

if your plugin already has a window of some sort, it would be easier to set hotkey->wnd to your window instead... then there is no need to subclass winamp

[DrO]

Originally posted by Safai
if your plugin already has a window of some sort, it would be easier to set hotkey->wnd to your window instead... then there is no need to subclass winamp

very true, but it's only meant as a basic example (the window proc is just to show the message detection). reading through it should show that things can be tweaked to a per coders preference

-daz

[Kaldo]

How about an example of using winamp's dlg, for a none ml_ex plugin.... just a suggestion....although im sure most people could figure it out faily quickly.

[DrO]

Originally posted by Kaldo
How about an example of using winamp's dlg, for a none ml_ex plugin.... just a suggestion....although im sure most people could figure it out faily quickly.

do you mean skinned windows like winamp does? if so then gen_mandy (slightly delayed ) is what you might be looking for

-daz

[Kaldo]

actually i am talking about wa_dlg.h....but if that is what gen_mandy uses then that would be a yes....not neccessarly skining the dlg....but just using winamps built in functions for a dlg. if it skins it for you already...then that would be a plus....im more or less just trying to get more information on using winamps built in functions for a dlg....it would actually save alot of time on coding a plugin for winamp as thats less code u have to write for your dlg's and what not... Thanks for the reply.

-kaldo

[shaneh]

Winamp only allows to create the outer window skinned. Buttons and scroll bars etc have to be manually skinned by picking apart bitmaps and bitblting them around the place.

[Kaldo]

im not actually refering to skining the dlg at all..im just trying to get more information on using winamps built in functions for a dlg for a plugin...like an example of showing how to use it, or more information on how to do it...

-kaldo

[shaneh]

There are no built in functions for a dialog, you just create your own with CreateDialog, common controls and wndprocs etc. Any tutorial which shows you how to create a dialog using bare bones API calls will work, and is how it is done.

[saivert]

Re: Skinning and Dialogs

How does the Media Library skin the scrollbars and the headers in the list-view. Does it subclass the scroll bar??

Re: Song change notifications
I just run some code in the WM_TIMER case in Winamp's subclass window procedure and compare the previous filename of playing song with the current. If it's not the same, then we have a song change. I previously did this in the WM_SETTEXT case since Winamp is changing it's Window title when the song playing changes.
Nullsoft should have implemented a more robust and efficient notifications API, like:

code:


notifyStruct notify;

notify.notifyhwnd = myhwnd;

notify.flags = NOTIFY_SONGCHANGE;

SendMessage(hwnd_winamp, WM_WA_IPC, (WPARAM)&notify, IPC_SETNOTIFICATION);

Which is NOT implemented now!

[shaneh]

I suspect it does owner draw type stuff for the scrollbars etc.

The 666 message seems to be what winamp sends on a song change. Something sends it to the playlist whenever the title changes (ie includes everything, including 'buffering...' type stuff, internet stream title changes etc). As it is the nullsoft trademark '666' number Id suspect this is quite intentional, and has been there for a while. Its probably used internally to tell the different components about the new title. The newer 'playing_file' message doesnt catch stream title changes.

I dont like using a timer, as you are restricted by the resolution of the timer, have to do a strcmp every split second, which is redundant, and various other problems. You are better off just catching 666 in the playlist wndproc, as it is sent whenever there is a title change, and seems fairly compatible with all versions.

[saivert]

I know that WM_TIMER is a bit redudant, but catching WM_SETTEXT is what I actually used in my NxS Balloon Tip plug-in. And to catch the '666' trick (number of the animal/devil) you would need to subclass the playlist window which I don't like to do as I'm not touching the playlist editor in NxS Balloon Tip. I know that checking the filename isn't a good solution as people may have the same song appearing multiple times in a row in the playlist, so I may very well investigate into the '666' trick. As I previously said: There should be a more staright-forward way of doing this.
Subclassing is not a robust way of doing things since there is a risk of interfering with other plug-ins then. A proper notification registration system must be implemented in Winamp's core.

[saivert]

I'm now using the '666' trick in NxS Balloon Tip. Thanks to all!

[shaneh]

Just watch out for duplicate messages when listening to streams. The 666 message is sent whenever there is a title update, and I guess title updates are sent every few seconds on a stream. For some reason there is also an additional 666 message sent when winamp first starts up.

[saivert]

I was recently going through wa_ipc.h where I discovered that you could subclass Winamp's main window (plugin.hwndParent) and do this (taken from NxS Balloon Tip's source):

code:


if (message==WM_WA_IPC && lParam==IPC_CB_MISC)

{

	switch(wParam)

	{

	case IPC_CB_MISC_VOLUME:

		if (config_displayonvolchange)

			PostMessage(plugin.hwndParent, WM_WA_IPC, BALLOONMSG_SHOW, g_BalloonIPCMsg);

		break;

	case IPC_CB_MISC_STATUS:

		if (config_displayonpbchange)

			PostMessage(plugin.hwndParent, WM_WA_IPC, BALLOONMSG_SHOW, g_BalloonIPCMsg);

		break;

	case IPC_CB_MISC_INFO:

	case IPC_CB_MISC_VIDEOINFO:

	case IPC_CB_MISC_TITLE:

		break;

	}

	return CallWindowProc((WNDPROC)lpOldWinampWndProc,hwnd,message,wParam,lParam);

}

[shaneh]

Hmm... makes sense :P What is '..MISC_STATUS' for?

Why arent you using the ..MISC_TITLE? wouldnt that be the title change?

Funny I never noticed those with spy++. I think there were too many _WA_IPC messages so I filtered them maybe.

edit; i guess status is for switching from play to stop etc.

[saivert]

I'm using IPC_CB_MISC_TITLE in my plug-in. It was just not included in the post.
IPC_CB_MISC_STATUS is triggered when playback status changes.
case IPC_CB_MISC_INFO is triggered when info like kbps and channels change. likewise with case IPC_CB_MISC_VIDEOINFO.

IPC_CB_MISC_TITLE is also triggered multiple times if playing a HTTP stream (ShoutCAST, e.t.c).
How do you check if a song is a HTTP stream reliably. Just scanning for "http://" in the filename isn't a good idea, or what??

[shaneh]

I couldve sworn I tried those CB.. but couldnt get them to work. Every plugin Ive seen uses the 0x29a/666 method. Perhaps they are only available in later versions of winamp or something.

Every bit of code Ive seen also seems to scan for http: to detect http streams. Its lame I know, but Ive done a bit of reverse engineering and I seem to recall even winamp doing that internally. It does it in the modern skin notifer wasabi code.

Itd be good if the input plugin returned something for getextendedinfo("server") or something, but Im pretty sure it doesnt.

[booster_2k2]

Originally posted by saivert

How do you check if a song is a HTTP stream reliably. Just scanning for "http://" in the filename isn't a good idea, or what??

I've been using IPC_GETOUTPUTTIME with mode 1 (so as to get the track length), which in case of streams returns -1 or something like that; additionally, you have to check if there's something playing, but I prefer this version to looking for substrings.

Is there a way to obtain the name of the artist and the song already separated? I've seen in a post something about IPC_GET_EXTENDED_FILE_INFO, but I couldn't make it work.

[sid.terminator]

i am not able to find API functions , and without API functions , how can i build program for creating plugins for winamp

[DrO]

it's all in in.h, out.h, gen.h, vis.h ml.h and wa_ipc.h (and other header files in the sdk depending on the plugin you're making) and assumes you know about win32 and c/c++ so you can correctly build the plugin (using the relevant examples in the sdk as a framework).

-daz

[emilles]

My main questions at this time center around getting the language that Winamp is configured for so I can choose appropriate resources in the plug-in to match. It seems lame to request that the user configure the language for Winamp and then configure the language for each plug-in separately. But I don't see anything in the API that supplies language Winamp is configured to use.

Also, for those who have internationalized your plug-ins, what method did you use to do so (separate build for each language, one build with all supported languages included within, main build in English with smaller language "packs" that can be added on, something else)?


Other than that for right now, the biggest problem I had developing my plug-in initially was understanding the sequence of events that the player would subject the plug-in to. It was clear from the SDK headers what callbacks existed, but I needed to figure out on my own what the sequence of the callbacks would be and there tended to be a lot of variation depending on the input plug-in being used (for the output plug-in at least).

Also, certain callbacks are issued from the player's main thread and others seem to come from another thread (or maybe a couple others). Some callbacks can be issued in parallel to others and some have a serial relationship with certain other callbacks. A few details on multi-threading issues would probably help new plug-in developers avoid a lot of problems.