You guys are never satisfied right??? Haha.Actually i dont have anything in my wishlist except maybe ASIO or kernelstreaming. That should be good for DSP Volume and balance. Smaller buffer equals less delay when you change volume you know!

But that is a real low priority anyway now that -boost works im all happy, dont need anything more!

I second the request for "Kernel Streaming Output" as a choice in preferences.

Streaming the sounddata outside the OS, from softdecoder directly to soundcard, bypassing the trunctuating kmixer.sys.

Using the shortest possible signal path through kernel streaming out, i am shure would together with its awesome decoder (iŽll be damned it it doesnt sound better than madplug), would give XMplay the edge, delivering the highest possible fidelity, clearness, naturalness, dynamic and unpoluted by kmixer.sys, as good as it gets Yummi

I second the request for "Kernel Streaming Output" as a choice in preferences.

Streaming the sounddata outside the OS, from softdecoder directly to soundcard, bypassing the trunctuating kmixer.sys.

Using the shortest possible signal path through kernel streaming out, i am shure would together with its awesome decoder (iŽll be damned it it doesnt sound better than madplug), would give XMplay the edge, delivering the highest possible fidelity, clearness, naturalness, dynamic and unpoluted by kmixer.sys, as good as it gets Yummi

Correct me if I'm wrong, but I don't see how using a different output system can affect the sound quality. The only thing you could posssibly change would be any delays in the system, which would be so small as to be unnoticeable. You don't have a noticeable delay between doing something in UT and hearing the sound, and that doesn't use DirectSound by defualt.

Correct me if I'm wrong, but I don't see how using a different output system can affect the sound quality. The only thing you could posssibly change would be any delays in the system, which would be so small as to be unnoticeable. You don't have a noticeable delay between doing something in UT and hearing the sound, and that doesn't use DirectSound by defualt.

I would say any kind of processing will affect the sound. The question is how much. Maybe i couldnt hear the difference of bypassing the windows mixer but im sure somone else could. They also have this bass and treble control i wonder how they implemented that thing...

The thing is you can have smaller buffers when you have lower latency. And the smaller buffer gives you faster response for DSP volume change.

I would say any kind of processing will affect the sound. The question is how much.

Yes, but the only processing being done is the mixing of the stream from XMPlay with other streams from different applications, and resampling if needed by the sound card (e.g. if the sound card doesn't support 96kHz then kmixer.sys will resample the stream down).

Quote

They also have this bass and treble control i wonder how they implemented that thing...

Not sure - it'll either be in kmixer.sys or the hardware.

Quote

The thing is you can have smaller buffers when you have lower latency. And the smaller buffer gives you faster response for DSP volume change.

Actually it won't with how XMPlay is written. The way things are done in XMPlay depends on if DSP is set. If DSP is being used, then any volume changes take affect at the point in the buffer the change happened. This causes a lag equal to the buffer size, and is unavoidable when using waveOut. If DSP is not being used, then the volume changes take affect instantly (actually, whenever kmixer.sys wakes up and reads the next 10ms or whatever), because the volume change is passed to kmixer.

Creating a seperate stream into kmixer.sys would bypass the delay when changing the volume with DSP, but would not reduce overall latency by any real amount.

Of course, I could have got all of this completely wrong. I've done that before

Wishlist for next XMPlayPlayer is fine for me it's the skinning area i think could use some more options1.The ability to have knob volume for main and the either Knob_volume_mini or just being able to have slider's in mini mode would be great.2.Being able to skin the extended info background (add background etccc)3.Being able to make the panel's pull down instead of being only able to pull from left/right.4.Sound level vertical instead of only just horizontal5.EQ sliders either vertical or horizontal (goes for volume balance sliders also )6.Skinning the info panel would be nice also instead of only having to stick with square panel.

"*.DBM: DigiBooster Pro"An Amiga tracker format... and considering how rarish it is I don't think being inbuilt would be a good idea. Much more like plugin material that one... if anyone around here could write winamp input plugins that is...

Wishlist for next XMPlayPlayer is fine for me it's the skinning area i think could use some more options1.The ability to have knob volume for main and the either Knob_volume_mini or just being able to have slider's in mini mode would be great.2.Being able to skin the extended info background (add background etccc)3.Being able to make the panel's pull down instead of being only able to pull from left/right.4.Sound level vertical instead of only just horizontal5.EQ sliders either vertical or horizontal (goes for volume balance sliders also )

Heh,Meant the extended playlist,make it into a panel on it's so u could go different shape's with it.The main thing I personally would like to see is to have vertical sliders/sound level.And to have different (or only) knob(s) for panel_main,and then using slider's on panel_mini.The reason for the later is,I have had very cool knob_volume and balance but have'nt been able to implement them into any skin because they are usually to big to fit in mini mode,so to have volume control in mini mode I just had to cut the knob's completely out. :/

6.Skinning the info panel would be nice also instead of only having to stick with square panel.

i dont understand this point .you talking about info window border transparence?

I think he wants to be able to use any shape for the playlist window, like with the main player. It is currently possible, but I haven't seen any skins that use a non-square shape.

Quote

See-through areas=================It's possible to make skins of any shape by marking areas as see-through.This is done using a "magic" colour in the panel (or info window corner)bitmap, as determined by the "color_seethru" skinconfig option. Slidersand scrollers can also make use of the magic colour, so that the areaunderneath shows through.

For backward compatibility, when a "color_seethru" is not specified, thecolour of the top-left pixel of each panel bitmap will be the magic colour.

Logged

0xbeta

hi there, after the long and sucessful time i had with the stp (sys tray player) player tek developments forced me to switch to a newer player. because of a suggestion at the stp forum i d/led the xmplay and i have to confess it is the best by now (for my needs of course).however, there are some things i really miss and like to mention:I. the play button in random mode is a big issue in the forum. i second the recommendation that the next button in random mode should truly be random next song. the right click feature jumps only in the active directory and assign it to a hotkey is second best because of not being mousebased and i have to activate xmplay by a mouseclick.II. in stp there is a nice feature "play random first track". will also solve a question raised in the forum.III. the time display could have more choices: time played/time to play (track/playlist) etc.IV. i just cant do multiple tag editing. it is anoying to right click at every single track. have a look at stp. there it is solved very lovely.V. a feature could be added: "after end of playback": turn of computer, exit xmplay etc.VI. the song which is played could be highlighted in some way. so it is easier to find it in huge playlists. or maybe a button "jump to recent song"VII. also very good in stp is an addition to "find track". there is a drop down menue just like the windows start button: tracks (which will list the entire playlist) and album (which will list the recent directory). maybe this could be done by a right click menue at the recent title in minibar modus.also when i right click directories in total commander to play in xmplay music does not start to play automatically.

so,thats for nowsorry for not registering to the forum (there are seerveral flames for that behavior), but i am not that regular forum writer and also just wanted to have my suggestions noticed. i will be back when a higher version is available.

I. the play button in random mode is a big issue in the forum. i second the recommendation that the next button in random mode should truly be random next song. the right click feature jumps only in the active directory and assign it to a hotkey is second best because of not being mousebased and i have to activate xmplay by a mouseclick.

Right click the play button (or press "End") to jump to another random track, and it should be truly random as it is. Also you can assign this to any hot key in the shortcuts tab of the options: Shortcut Options

VII. also very good in stp is an addition to "find track". there is a drop down menue just like the windows start button: tracks (which will list the entire playlist) and album (which will list the recent directory). maybe this could be done by a right click menue at the recent title in minibar modus.

Not sure I quite understand this one, isn't the extended playlist more suitable for listing the playlist?

VII. also very good in stp is an addition to "find track". there is a drop down menue just like the windows start button: tracks (which will list the entire playlist) and album (which will list the recent directory). maybe this could be done by a right click menue at the recent title in minibar modus.

Not sure I quite understand this one, isn't the extended playlist more suitable for listing the playlist?

I think 0xbeta means a menu system for navigating thru a music directory, a bit like the Start menu but with music files instead of shortcuts to programs.

Feature request: a way to lock the default playlist read-only without breaking track queuing persistance.

What currently happens is that the queue information is stored in the default playlist (%xmplaydir%\xmplay.pls). If this file is made read-only, then any changes to the queue will not be stored across instances of XMPlay. Should a queue have been stored in the file when it was made read-only, XMPlay will always load the same track queue.

Suggested change: store the queue information in a seperate file (e.g. %xmplaydir%\xmplay.que) or in the registry (e.g. HKCU\Software\Un4seen Developments\XMPlay2\Queue).