Winamp Scripting

[shaneh]

The example included with the activewinamp distribution (AWExamples/waform) is a C# application which handles track change events.

I just tested it and it works ok with Winamp 5.3

[bwechner]

Alas I tested it too and didn't work. I'm happy to try again when I get home (having tried a few times already). And I'll give it a whir on another PC too. But if I'm stuck, what diagnostic tools are there for seeing why an event driven callback fails?

The example C# app in fact is the only way I could divine that the ChangedTrack property needs for some reason I don't understand the += incrementor rather than the = assignment operator.

[shaneh]

Are you sure your 'Winamp' object is global? It will be destroyed (along with all event handlers) once it goes out of scope if not.

At line 15 you can see it is global:

http://activewinamp.cvs.sourceforge.net/activewinamp/activewinamp/Package/AWExamples/waform/Form1.cs?revision=1.2&view=markup

The reason it needs a += rather than assignment I suspect is because you want to "add" a handler to the list of handlers, not override the handler.

[bwechner]

Shaneh, thanks. I'm confident and will check when I get home again (to see my code). I can't rule out an obvious error (very common after all) but I am aware of scoping issues. I'll report back here.

But, I can't get the provided demo to work either. Well it compiles and runs just fine on my box at home and functions quite well, except for the callback it seems (a break point there never triggers wen I change WinAmp tracks).

I have the same interpretation of the += requirement, but to be honest I am in lieu of understanding the consequences happy to override the event handler. I'm left assuming that perhaps there in a WinAmp internal handler that if overrridden has some unpleasant side effects (WinAmp not functioning correctly). Who knows? It seems to be by design of ActiveWinAmp or WinAmp anyhow that this eventhandler cannot be overridden.

[Pamarro]

How do u write scripts for the following actions?

- Add currently playing song to Bookmark
- Open 'View file info...' box

There don't seem to be Global Hotkeys for these two actions, so thats why I'm asking.

[esulin]

I just wanted to follow up on bwechner's posts...

I just started playing around with ActiveWinamp in C# the other day.

First off I played around with the code in Visual Studio 2003. I compiled and tested the sample c# program, and then wrote my own test program to familiarize myself with the code (i'm a relatively new programmer). In any case, in VS2003 everything worked perfectly and the events worked correctly.

I have since then installed Visual Studio 2005, and have convereted both the sample program and my program to the new format. It seems that both are now experiencing some form of problem when the events are fired by winamp. I have attempted to trace where the problem is and I got some very strange results (code being skipped). Although this could just be an error in my debugging efforts.

I will look into it further. But in the meantime I just wanted to point out that I seem to be having the same (or similar) problem bwechner's having.

UPDATE:
Well, what I noticed earlier seems to be true.

I am working with the sample code provided with the plugin in VS2005.

I placed breakpoints on the first three lines of OnTrackChange() (including the {).

When I changed track either through winamp or through the app the program would break at the {, but when I pressed continue, it did not move on to the "int pos = playlist.[...]" line but it seemed to exit the function and revert back to idle.

I ran the app and changed track several times, and on one of the tries, the code actually ran, and everything worked as it should. When I changed the track again, I faced the same problem as earlier.

I have noticed that if I wait a certain amount of time between skipping tracks that it's more likely that the code runs.

In any case, I'm not quite sure what the problem could be as I didn't even know that a function can just quit without some form of 'try' code or exit command, or without throwing a runtime error.

Let me know if there is any further info I can provide to help debugg this.

[bwechner]

esulin,

Thanks enormously for the experiments. I'm using Visual Studio 2005 Express and so it does look like we share a problem. Good efforts your side. I've lacked time with the Christmas and Birthday hooha surrounding these weeks for me and want to experiment some more too.

On the face of it, it seems that VS2005 introduced a new "feature" over VS2003 (given the sample code seems to work in VS2003 as expected). I wonder if shaneh is using VS2003 or VS2005 when he reports the demo code works?

The symptom's you're describing to challenge the imagination. No exception is thrown, nothing, just silent exit. I did try break points on the opening { as well and didn't catch any entry, but only tried a few times a week or two ago not exhaustively. It seems from what you've described to be timing related and quite possibly a threading issue with VS2005 and/or ActiveWinamp int he .NET 2 world?

Bizarre and a blocking issue alas. A real downer for now as I was very excited about ActiveWinamp!

[shaneh]

I'm pretty sure I was using VS2005, although the project distributed is for 2003 and I had converted it.

I wouldn't be surprised if breakpoints don't work very well. The event is synchronous, meaning it runs in a single thread and waits for your code to return before giving back control to the Winamp thread. You would want to ensure you do as little as possible in your event handler - perhaps just adding the event to a queue and handling it in another thread.

Instead of using a breakpoint you could try just outputting a debug statement or something just to see if the event is getting through. I will try re-write a small demo in VS2005 and see how it goes.

[esulin]

shaneh,

I actually tried that too...

I setup a list control and output two consecutive messages to the control in the first two lines of the function.

I found that when debugging it would break on the {, and then also break on the first line (messagebox listbox). The next continue would exit the function. During the times that the function exited, nothing was added to the control, even though according to the debugger it looked like the line should have been executed. During the instances that the code did work, both messageboxes calls correctly added to the listbox.

I also have VS2005 running on my laptop and am experiencing the same problem there.

The desktop is running Winamp v5.21, while the laptop is running v5.3.

I've downloaded the VS2005 SP1 last night and will give that a go on the off chance that the problem is due to some bug that has now been resolved. Will post progress.

Also, I tried running the code again today without any breakpoints, and regardless of what I tired it wouldn't execute the code. Although, when I put the break points back in, it managed to execute once.

I also executed the VS2003 project again just to double check that, and it worked perfectly.

UPDATE:

Also worth mentioning two more things.

First, I also noticed one additional thing, and I'm unsure whether it's related to the debugger, or to AW. Namely the first time that the OnTrackChange() is called VS freezes up for an amount of time that is always the same on each machine (i.e. 15 sec. on the laptop, 10 on the destop). This could be to do with the debugger processing something, or it could be waiting on a timeout or something like that from WA (the times might be different due to different playlist lengths).

Second, on my laptop the exact same code that is running on my desktop seems to return a blank value for playlist[i].Artist and playlist[i].Title, while the desktop coded runs fine.

[shaneh]

I think popping up a message box can be quite dangerous in an event handler when dealing with COM. I can't remember the exact details, something to do with it having its own modal message loop, and thus the COM messages are processed by the messagebox code. Something like that anyway.

You could try without the message box. I'll look into it further when I get a chance.

Also, you could try a simple VB script based event handler, as seen in the scripts examples.

[esulin]

Sorry about the confusion, I meant to say 'listbox', not 'messagebox' (will edit). The code is:

public void OnTrackChange()
{
lst_status.Items.Add("On Track Change Event Test 1");
lst_status.Items.Add("On Track Change Event Test 2");
int pos = playlist.Position;
ActiveWinamp.MediaItem mi = playlist[pos];
try
{ [and so on...]

The reason for two of them is because during debugging the app breaks on the first line and thus I wanted to have a second line of non-acitvewinamp related code to break on to see if the first gets executed.

[esulin]

Another update.

I've installed VS2005 SP1, but that hasn't fixed the problem. Although interestingly enough, the 10-15 second freeze I mention above now occurs every time the function is called.

Further more, I noticed some info the might be pertinent to the problem in the 'Locals' detais. When the debugger breaks on the { breakpoint the state of the 'winamp' object is as follows:


-winamp|{ActiveWinamp.ApplicationClass}|ActiveWinamp.Application {ActiveWinamp.ApplicationClass}

-[ActiveWinamp.ApplicationClass]|{ActiveWinamp.ApplicationClass}|ActiveWinamp.ApplicationClass

Hwnd|Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.|int

MediaLibrary|Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.|ActiveWinamp.MediaLibrary

Panning|Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.|int

Playlist|Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.|ActiveWinamp.Playlist

[and so on]

(columns are | delimited)

I assume this timeout is responsible for the problem. Any suggestions on what I can do to further trace the problem?

[shaneh]

I can't reproduce this with the demo, theres no noticable delays or missed events. Have you tried running the code outside of a debugger and without breakpoints etc? Just as a standalone exe?

Are you using the latest version of AW from the CVS? Perhaps you need to regenerate the interop code or something.

[bwechner]

Well, I've played around a bit and with VS2005 I can report:

The trackchange and volume change callbacks do not work at all in the demo or my code in debug mode.

They work find in a release build (standalone exe!)

So, I have no idea what's going on, but that's what I've found on my box.

Thanks for getting me that far, and I hope esulin's problem gets sorted too!

[bwechner]

A progress bar?

Now that I have a small app working with track change events, I thought it nice if I could get a progress bar up as a song is playing in WinAmp.

The real hitch though is, that I can't find in ActiveWinAmp and property of a media item (or anything else, or a method) that would reveal how much of the song had played.

In short I can't work out what to set the progress bar to.

If I had that I could then update the bar every half second or so and get a nice progress bar during play on my app.

Any thoughts there? I haven't explored all the messages I could send to WinAmp yet (one of those may do the trick, but it would be nice if the COM object directly gave measure of this).