Alt+R - selects result list
Alt+F - selects query field

While the results list is selected:
Up/Down arrows - navigate through results. The highlighted result is also automatically highlighted in XMPlay's playlist (even if XMPlay's windows is not visible). Which means:
- multiple results can be selected using Shift+ Up/Down. By default, after a search, all results are selected (until first pressing Up/Down)
- the selected result can be played using the configured Play shortcut (mine is Space, I'm not sure if this was the default). If multiple results are selected and the Play shortcut is pressed, the first result in the playlist starts to play and the rest of them are queued.
- the selected result(s) can be queued (without immediately starting to play them) using a key shortcut. I'm using Alt+Q but, again, I'm not sure if this is the default.

All key shortcuts (except Alt+R and Alt+F) can be configured from XMPlay's options window.

And this is how I use Find solely with the keyboard.

[EDIT:]

The backup file (xmplay.library~) can probably be removed now, unless anyone can think of a reason to keep it? I'm not sure it was ever really very useful, as it would require manual intervention

Please don't remove it.   It ”saved my life” a couple of times. Yes, I had to do a manual restore of the file, but at least I had what to restore. It has it's flaws/limitations, but it's better than not having a backup file at all.

EDIT: If you feel that it's redundant now, you could change it's behavior to something like ”periodic backup”. Maybe once a week, or once a month, not on every XMPlay close. It doesn't really have to be strict (as a backup interval), but I feel that it's nice to have an automated backup, especially since the library stores information that cannot be recovered from anywhere else (playcount, age, overridden tags, etc...).

EDIT2: About the NoBackup option, I just noticed now: what happened to the xmplay.pls~ file? As I recall, there was also a backup for the playlist. Was it removed, or was I dreaming? 

If you experience peaks again, you can post a new screenshot (the same as above). As I said, the above ideas were just guesses based on that screenshot. Those guesses might very well be wrong. New screenshots (from different XMP settings) might give some more clues though.

Looking at that screenshot, my best guess is that at fault (sort of) is the asio4all plugin. Try changing the output to something else (DirectSound, maybe) and see if it happens again.

Detailed:
XMPlay itself is not even dependent of the Visual C++ Runtime, so on it's own, it shouldn't cause any problems related to msvcrt.dll (since that library wouldn't even be loaded). So whatever it is, it must be a 3rd party plugin. And looking at the screenshot, besides msvcrt, the only active threads are in asio4all.dll. Also, asio4all seems to try to unregister something, which could mean that it's stopping some threads of its own, which is also consistent with the current function call in msvcrt (endthread).
So all in all, this should be your starting point: if those CPU spikes really annoy you, start by removing the asio4all plugin, then go from there.

Could you post a screenshot of the Threads tab for XMPlay in ProcessExplorer, when the problem appears?

I'm not sure if this changed (however I doubt it), but a few years ago I used the SendMessage API to find XMPlay's playing state. Something like this:

int result = SendMessage (XMP_hwnd, WM_USER, 0, 104);

Looking now in the old C++ sources I wrote back then (which, sadly, are very poorly documented and commented ), I can deduce this:
result will be 0 if XMPlay is stopped. I don't remember if there was a difference between stopped with the file loaded (one-click stop), or stopped with the file unloaded (two-clicks stop)
result will be 1 or 3, depending if XMPlay is Playing or Paused (again, I can't remember if 1 is playing and 3 Paused, or vice-versa).

But anyway, if those scripts you are using support sending window messages, you should give this a try. With a simple trial-and-error approach, you will sure be able to find the exact values. It worked perfectly a few years back when I used it.

Also, as far as I know, there is a method of callind any API directly from the Windows command line (cmd). So there might even be a way of using this approach in a BAT file (however, you still need a way to get the XMPlay main window handle, XMP_hwnd).

[EDIT: I just noticed that AEN007 opened a new topic about the same matter. I also posted my reply in his topic, so this post could be deleted (since it is offtopic, regarding the XMPlay support site).]

EDIT: I just noticed that AEN007 opened a new topic about the same matter. I also posted my reply in his topic, so this post could be deleted (since it is offtopic, regarding the XMPlay support site).
I'm not sure if this changed (however I doubt it), but a few years ago I used the SendMessage API to find XMPlay's playing state. Something like this:

int result = SendMessage (XMP_hwnd, WM_USER, 0, 104);

Looking now in the old C++ sources I wrote back then (which, sadly, are very poorly documented and commented ), I can deduce this:
result will be 0 if XMPlay is stopped. I don't remember if there was a difference between stopped with the file loaded (one-click stop), or stopped with the file unloaded (two-clicks stop)
result will be 1 or 3, depending if XMPlay is Playing or Paused (again, I can't remember if 1 is playing and 3 Paused, or vice-versa).

But anyway, if those scripts you are using support sending window messages, you should give this a try. With a simple trial-and-error approach, you will sure be able to find the exact values. It worked perfectly a few years back when I used it.

Also, as far as I know, there is a method of callind any API directly from the Windows command line (cmd). So there might even be a way of using this approach in a BAT file (however, you still need a way to get the XMPlay main window handle, XMP_hwnd).

The alternatives for that would be:
- either force XMPlay to run with Admin privileges (Properties -> Compatibility -> Always run as Administrator). But then you'll have to deal with an UAC alert every time you run XMPlay

- or just "install" (move) XMPlay to another location, not in Program Files. I personally have a completely separate partition where I install all applications. Even though UAC is enabled with default settings, all applications can write as they wish their own files. My VirtualStore is empty (except two ini files, from the Windows folder, which I have no idea how they got there ).


About Dotpitch's suggestion: And Vista. Don't forget Vista. It also has it's own UAC system.
However, for a one-user system, I don't see the big difference between having the settings/playlist in the user folder and having them in the VirtualStore. It's the same thing: a location where XMPlay is not installed, but only writes it's files. So it could very well remain like this.
Or, if it's any detection going to be involved, the default setting should be "ProgramData", not "per-user config". It will still be a global location (for all users), and XMPlay will be able to write to it without UAC interfering. Otherwise, on Vista/7 there won't be any solution for global settings in XMPlay. It will be either "per-user config", either virtualized by UAC (and will also get to a per-user location, because the VirtualStore is, well... per-user )

That's UAC (User Account Control) causing your problems.

Take a look in:
c:\Users\<your username>\AppData\Local\VirtualStore\Program Files\XMPlay (the italic is just an assumption; after you get to the VirtualStore, you should be able to figure it out )

And there I have a feeling you will find an xmplay.ini (and maybe even other files, such as the playlist, library, and so on). Try changing that file and see if it works.

[now]

I didn't say that older versions work like that now. They worked a while back, when I used them. I have no idea if they still work or not.

Right now I'm using the 0.9 version.

Just a curiosity: when I first started using this plugin (before Xander started working on it), Last.fm was showning that ”Scrobbling now with XMPlay” text. Granted, it didn't show the realtime play status (a.k.a the last track was always ”Just listened”), but XMPlay was mentioned above the recent tracks list.

I'm not sure when exactly Last.fm stopped showing that info, and I always assumed that it was actually removed by Last.fm. So... what happened exactly? Where the old versions submitting the player name, and the current ones aren't? Weren't all older versions based on the same 1.0 protocol?


I don't really care about that small piece of info not being submitted. I know what I use for listening. I was just curious. 

It's reated to the buffer size (Options -> Output). The next file is loaded when the current one has less time left than the buffer size.

[stopped]

re-launch XMPlay, playback will still be paused at the same position

Actually, what Ian said is that, when XMPlay is relaunched, the player is stopped, not paused, even though the progress indicator shows the previous song position. And since the player is stopped, not paused (therefore, the output device is not initialized - yet), the play button doesn't flash.


On a sidenote, would it me too much of a hassle to reintroduce the time blinking while the song is paused, at least as (another) secret option? I liked it better that way (personal opinion).

[EDIT:]

What are you planning?

It might sound silly, but basically I'm trying to count how many times a track was skipped (by pressing "Next", or by any other methods that would make XMPlay not count that track as "played").
It's just a little thing I'm trying, to automate a little the playlist cleanup (removal of tracks that are skipped very often). It's just a personal thing for myself, I kinda doubt it will become a full, public plugin.

Another reason why I'm trying this is basically to gain some more experience working with other applications' APIs. Making your own application becomes a somewhat easy task in time, but structuring it to work correctly with code written by someone else is a different challenge.

Thanks for the idea.


EDIT: Could you also please tell me how exactly the XMPFUNC_REGISTRY functions work? In the above case, I assume the key parameter should be ”LibPlayTime”. But how about the section parameter? If I set it to ””, XMPlay crashes (access violation writing memory) and if I set it to ”Library”, GetInt returns 0, but data contains a large negative value (which I assume it's an error). Any hints will be much appreciated.
Never mind... just figured it out. It the XMPlay section 

[Options -> Playlist -> Library -> Count as played after]

Hello,

I've searched a little on the forum, but I couldn't find a topic regarding general XMPlay plugin development. So I thought it might be useful to have a thread for general questions, or maybe API requests. Anyone who might want to start developing a plugin, feel free to use this thread to ask questions.


Skipping to the main problem, I have a few questions for Ian: is there any way, in the API, for a plugin to find out (or get notified) when the current track is considered "played"? I'm referring to the number of seconds needed for the "played" counter in the library to be increased (from Options -> Playlist -> Library -> Count as played after).

I saw in the API these functions:

BOOL (WINAPI *IsPlaying)(); // playing?
double (WINAPI *GetTime)(); // track position in seconds

which could be used to "simulate" the same behavior, but this implies using a secondary thread to poll the status, sync methods and so on, which won't do much except complicate things.

So is there any way to find out when the current track is counted as "played"? Or... could it be added anytime soon?


Another question: is there any way to find out the number of tracks currently added to the queue?

And finally (at least for now): is there a simpler way to use the DDE functions directly? DDE is useful when trying to communicate with XMPlay from an external application. But since a plugin can communicate directly with XMPlay, is there a way to access ALL those functions directly?


Thanks.

[EDIT:]

You're right, it might not.

But since we're debating this idea, why limit to ID3v2? I'm not an expert on music file formats (I mainly like listening to music, not studying it's format ), but I'm taking a look at the OGG file info plugin. As far as I can see, it supports virtually any fields. I see there a small ”Add new” button, which lets you add a completely custom field, having any title and any content.

So if XMPlay were to support all ID3v2 fields, there might be some users who mainly use OGG files which might request a similar feature. And so on and so forth, with different filetypes.

So why not make it better for everyone, from the beginning? Adding a few custom, user-defined fields, should make it easier for anyone who wants additional information from their files.

Just an idea.

EDIT: And another small idea: those custom fields could be used, maybe, by some 3rd party plugins, for some additional track information (that might not be directly stored in the file itself). I thought once about a small plugin I could use, for some more advanced statistics, and these custom fields could help fix some ”storage” problems that I bumped into.

I suppose, it could be a kind of state-of-art principle for Ian - to implement a brand new library with full ID3v2 support instead of such gradual step-by-step ascending.

That would somehow be overkill, in my opinion. Most users don't use most of the ID3v2 tags (I know I don't). And in this case, reserving space for useless fields in the library would just be a waste of space which will lead to very big library files for no reason. Apart from the size of the library files, this might also impact the speed (the time required to process all the library entries on load and on save) and the memory footprint (because all this information will have to be loaded in RAM when XMPlay runs).


Instead, I would propose some (maybe 3?) user-defined fields in the library. These fields could have whatever meaning the user wants (maybe the user could even edit their title).
And maybe the structure of the library (what user-defined fields are enabled and what aren't) could be stored directly into the library, in which case the number user-defined fields could be indefinite. So XMPlay could initially parse this info, and then load whatever it's needed. Of course, this won't be a small code change, but it would be kinda big.

(You can use Process Explorer, double-click the System process and go to the Threads-tab.)

I was just about to suggest the same thing.

However, I'd suggest starting ProcessExplorer and opening the Threads tab (for the System process) before actually starting XMPlay. Because enumerating the System threads (and all their details) is quite a complex process, and if after opening XMPlay there are performance problems, opening ProcessExplorer and then listing the System threads could take ages.

In the find tracks window searching in tags + filenames + titles is not possible currently. Is there a reason for that?

Why do you say that? As I see it, tags and titles are the same thing. I always kept it to "titles & files" and always found what I searched for (no matter where the string was found: filename or tags). What more is there to search?

That is absolutely normal, since the CPU cannot handle all the things you throw at it. And since the CPU usage is at 100%, and the CPU is the one that should also keep XMPlay running...do the math

If the CPU usage is caused by XMPlay, then there's indeed a problem with XMPlay. If not, well...try using less CPU-intensive applications, and let it breathe a little. XMPlay is not at all a CPU-intensive application, but it still needs some CPU power left in order to be able to run.