next »

[dbz]

I can imagine that adding checkboxes to the plugins list would be very helpful when searching for dodgy plugins, as you wouldn't have to rename/move all your plugins if you need to identify a broken plugin anymore.

I never even thought of that, but you're absolutely right - it's like an added bonus.

[Ian @ un4seen]

I have an idea that could be a really good feature. I think there needs to be a mode to switch between a minimal selection of plugins and a full-blown selection of plugins...

Personally, I don't really see the need for a "lite" mode with some plugins disabled, but the ability to disable plugins could be useful for testing purposes, as saga suggests. I'll look into it.

I think the disabled plugins will still need to be loaded to get their name for the plugin list (before being unloaded), in which case disabling them won't have decreased load time. Actually, perhaps the plugins could be left loaded and just skipped over when it comes to playing files, to allow quick enabling/disabling (without having to restart XMPlay). If the plugins are unused and memory gets very low, Windows will be able to swap them out of memory.

A couple of suggestions regarding drag and dropping files into lists:

1. When the DragN'Drop cursor is hovering the list a line between track lines will indicate the target destination of the inserted files.

2.While in DragN'Drop mode crossing the down or up edges of the list will scroll the list up or down slowly. Going further from those edges will increase the speed of the scroll.

The target playlist entry should already be highlighted when hovering over it, the same as when not drag'n'dropping. If it isn't, please try another skin, in case the skin's colour scheme means that it's not very noticeable.

Regarding the 2nd idea, that seems like it would break the ability to easily drop files to the end of the list. Currently, if files are dropped outside of the playlist but in the playlist panel, the files will be added to the end of the list. Wouldn't your suggestion prevent that?

[dbz]

I think the disabled plugins will still need to be loaded to get their name for the plugin list (before being unloaded), in which case disabling them won't have decreased load time. Actually, perhaps the plugins could be left loaded and just skipped over when it comes to playing files, to allow quick enabling/disabling (without having to restart XMPlay). If the plugins are unused and memory gets very low, Windows will be able to swap them out of memory.

I was wondering if this would be possible. You helped me awhile back figure out how to load in files using Winamp plugins into a program I was working on... so remembering back then, the thought crossed my mind that this might be a "catch-22" situation as you've described - where in order to say you don't want to load the plugins, you first have to load them. There wouldn't be anyway around that would there? I understand that once the program is started, the plugins have to be loaded - that's fairly obvious. But my main focus of this was to cut down the load time and the memory usage. On a newer system it may not even be noticeable, but on an older system it really is.

How about this? What if you scanned the plugins folder on startup and you use the "ini" file to store a list of the plugins there and what state they are, enabled/disabled? If the plugin isn't already listed in the "ini" file it would be added there and given an enabled state. So first time through, all the plugins would be added to the file and set as enabled. And everytime XMplay is run, you would update the "ini" file to reflect what plugins are present. Then XMplay would read the file and use it to determine what plugins it should load and populate the plugin list (also from the file). Would that work? It's about the only thing I can think of that might solve the problem.

If your only concern is for testing purposes, then enabling/disabling plugins (while keeping them loaded) is definitely the way to go, in my opinion.

[saga]

On a newer system it may not even be noticeable, but on an older system it really is.

Even on my old Athlon rig, loading the playlist/library took the most time for me, I think, and it's still like that.

[dbz]

I don't doubt that, I'm just saying every little bit of savings in speed and memory helps. And when you just want to play one mp3 file, you don't really want to wait 8-15 seconds for the program to start - when it can be more like 2-3 seconds.

[Eugenii]

dbz
I think this can be done even with help of .bat file. It is depended on how xmplay detects plugins, if I think right, then renaming *.dll to something like *.dll0 must be enough to not load all plugins.
If you want to have choice when you click song/playlist (not "run.bat"), then it can be solved with help of associations like I done with mini control bar.

added later:
I just put run.bat from archive in the folder near xmplay.exe and execute it. It works for me.

[dbz]

I'm not really familiar with the structure and syntax of batch files, but I think I follow the jist of what your file is supposed to do. However, when I ran it I get this message "Out of environment space... Uncorrect choice... Press any key to continue..."

If I understand correctly, the batch file is trying to rename all the dll files to dll0? I can see that would work if you want an all-or-nothing approach, but in my case I still want to have the choice of keeping a certain number of plugins still active. What would be the simplest approach to handling that? Would you still do the "@ren *.dll *.dll0" to rename all the files, and then exclude each active plugin with "@ren plugin.dll0 plugin.dll" (where 'plugin' is the actual filename)?

If there's a solution to the error message when running the batch file, then this could work. But even so, it still comes across to me like some kind of a hack to the program. I realize sometimes that's the only way to fix a problem (when source code is lost), and I'm not trying to shoot down every idea or be negative (I welcome other ideas gladly) - but when a project is still in active development, and the developer is willing to listen to our suggestions, I think the best approach is to let the developer handle it - since they know more than anyone else about their own program and they can re-write the source-code, which is far better than resorting to some other work-around.

[Eugenii]

Out of Environment Space Error Check first or second method (for 2nd changing properties of a .bat file, if there would be memory tab, or maybe command.com).
dog symbol "@" just hide result of command from user
If you need to "switch-off" 10 plugins and leave on only two 2, then it would be easier to write 3 lines as you say, but it is leading to 2 more renaming operations. Writing line for each file could take more time from you, but less from OS to execute (I don't sure here, maybe 3 lines will execute more faster than 12). So test first method and if you like result - use it.

A developer often has own vision of project's evolution, and it is his full right. So if you want some new feature, you can wait for it, look for another project (as I came from KMPlayer to gapless XMPlay) or make it with your hands. It's your full right too.

[dbz]

Ok, I got rid of the "Out of environment space" error message, but the other messages still persist. And reading the article, it says "NOTE: The maximum amount of memory that you can allocate for an MS-DOS program is 4096 KB." Does that mean the DOS program itself or, in this case, XMplay? Because I think XMplay could exceed that limitation after loading a number of plugins.

A developer often has own vision of project's evolution, and it is his full right. So if you want some new feature, you can wait for it, look for another project (as I came from KMPlayer to gapless XMPlay) or make it with your hands. It's your full right too.

I completely agree with you.

[Eugenii]

The maximum amount of memory that you can allocate for an MS-DOS program is 4096 KB

For dos-box where user-input, renaming operations and starting of player are proceed.
Hm... it seems that in win98 you must use choice instead of set /p...
try both files in archive

[dbz]

That seemed to work better, the only problem now is when I choose A or B I get a "File not Found" message. Is it looking for the plugins in the same folder as xmplay.exe? I keep all the plugins in a separate folder named "Plugins". I tried changing it to @ren \Plugins\*.dll \Plugins\*.dll0, but I got another error "Invalid Parameter - \Plugins\*.dll0". Like I said before, I don't know much about Batch files, maybe you can help me out.

[Eugenii]

using wildcard "*" in renaming operation doesn't allow moving files, so you can't use drive or folder name.
you must set absolute path to each plugin or move .bat to the plugin folder and change start line to

start ..\xmplay.exe

you can also try to replace choice strings to (if it will be more comfortable):

echo 1- w/o plugins
echo 2- with plugins
choice /c:12 Choose an option

tip: if you haven't tried yet, .bat file lets you to create a shortcut for it (e.g. place it on your desktop)
p.s. maybe when you get it to work, moderator will have to clean the topic from our conversation

[dbz]

Ok when I select "w/o plugins" it works, but when I choose "with plugins" it behaves like I've selected "w/o plugins" - so I can't get all the plugins renamed back to what they were. And yeah, I didn't mean to hijack the thread with this stuff. If you can figure out why option #2 isn't executing when I select that, then that should do it. Ian can of course delete whatever information he feels is off-topic or unnecessary. I appreciate all your help, and this can act as a temporary solution until there is a hopefully more integrated solution.

Something else just dawned on me. By putting plugins in sub-folders in the plugin folder (which I had already done before trying all of this), those plugins aren't affected when you rename the ones in the main plugin folder. So rather than list (in the batch file) each and every plugin you want to keep active, you could just put each of them in a sub-folder. That way they are always active, while the plugins in the main folder get toggled on/off with the batch file. It works pretty good if you ask me.

[Eugenii]

Ok, I think last version of .bat. You just have to place If Errorlevel # Goto in descending order.
You can use any combination of .bat code and files/folders, if it works and suits you.

[dbz]

That last version works perfectly. Thanks again... now back to your regularly scheduled program.

[amit]

The target playlist entry should already be highlighted when hovering over it, the same as when not drag'n'dropping. If it isn't, please try another skin, in case the skin's colour scheme means that it's not very noticeable.

I thought that instead of highlighting the tracks entries themselves xmplay can highlight the space between them. Thus when you hover (while dragging files) the upper half of a track row , a line above will be drawn and the files will be inserted there; if you hover the lower half a track row , a line will be drawn below it and the dragged tracks will be inserted beneath it.

Regarding the 2nd idea, that seems like it would break the ability to easily drop files to the end of the list. Currently, if files are dropped outside of the playlist but in the playlist panel, the files will be added to the end of the list. Wouldn't your suggestion prevent that?

One solution would be to accelerate the scrolling speed as you move away from the lower or upper edges of the list. After a distance the scrolling speed can be as high as getting to the end (or beginning) of the list instantly.
Another option can be to drop the files at the end of the list when you add right click to the constant hold of the left button(while drag and dropping files).

[Chinese Sausage]

I'm not sure if it has been suggest before, but is it possible to be able to "stick" in place the extended playlist/info window to the player like in Winamp or AIMP?
The "Lock in position" option helps but still it would be nice for XMPlay to be able let the extended playlist "stick" in place (up, down or sideways) without having to do it pinpoint precise.

[saga]

Just wondering, how many times a day do your move your XMPlay windows? I don't think I have touched the positioning of the XMPlay windows here for years, and I certainly didn't need the help of magnetic windows to arrange the main and playlist window to do that. Although, of course, making the playlist and main window magnetic (and not just the screen border) would probably a nice compromise.

[Chinese Sausage]

I don't move it often because I know I will have to arrange it pinpoint precise, because it does not stick as in others players, otherwise I would move the player more freely and would make different layouts withe the player and the extended playlist. I would not always limit the player by locking it in a certain position. I think this is a small disadvantage XMPlay have over other players. I often wonder if implementing this function will increase the player's download size or will it affect other available functions.

[rst]

only these suggestions:

- 'Select all' in playlist and library, in orther to delete all with a simple key press.
- A setting to rotate the visualizations ramdomly each x seconds or minutes.
- The player is extremelly good, and the only thing that left to have is the Video play, specially DVD with menu handling.
- An interface button, or other easy way (shortcut keys), to enable the encoder output to perform fast operations without to have to go to the XMplay settings.