Topic: 3.6 reports, queries and bugs

[Dotpitch]

3.6 is here, enjoy it (during Christmas ) and post any problems/bugs/questions in this thread.

[Jimmy Neutron]

I didn't think to say anything before this, but releasing 3.6 with the "old" default skin (without a spectrum display) does XMPlay a disservice.  There's been too much work put into XMPlay (thanks Ian!) to have potential users walk away based on the initial out-of-the-box appearance.

Please make an updated default skin a priority for 3.6.1.

[SmartOne]

Will you please make the equalizer bands adjust by 0.1 dB using the mouse and the scroll wheel?  It's hard to match multiple bands.  

Will you please also add an option to snap the playlist window next to the main window?

[Pike84]

I didn't think to say anything before this, but releasing 3.6 with the "old" default skin (without a spectrum display) does XMPlay a disservice.  There's been too much work put into XMPlay (thanks Ian!) to have potential users walk away based on the initial out-of-the-box appearance.

Please make an updated default skin a priority for 3.6.1.

Hmm... I'm not so sure about this. First of all, looks has never been one of XMPlays "selling points". Also, it's not so easy to make a good looking "general purpose" skin, and the current one works well, I think - myself, I've used many skins over the years, but I always eventually go back to the default one .

[Chinese Sausage]

I'm not sure how good the default skin would have looked with a new spectrum analyzer. IMHO the default skin is very serviceable, clean and with good contrast and clear, readable fonts. I almost never use the playlist though (not wide enough for the track titles).

Perhaps Ian and Cypress were giving us instead a new "default" skin with Rated?

While I think it is important that the player itself looks good, most important is the overall functionality, sound quality and the practical features, while also preserving it's small size and memory footprint. That's the greatness of this player, that it does what all audio players suppose to do, but much better

[Pike84]

Perhaps Ian and Cypress were giving us instead a new "default" skin with Rated?

Eh? Where did this one come from ?

It's actually looking pretty good, and the large size works on my screen.. but it's a little, um, unconventional for default skin, and it's also too big, since many users may not have big enough screens. It's also quite big in bytes.

[edit]Uh... There's no "random play order" button in this skin's extended playlist? I miss one, especially for sorting purposes (I like to keep the queue visible in the small one) .

[edit]By the way, is it possible to have some sort of anti-aliasing for the skins' edges? Skins with round forms, such as this one, suffer badly from those sawteeth .

[Jimmy Neutron]

With my comment, I didn't mean to diminish the value of the great sound.  The users already active in this forum are "sold" on sound of XMPlay, and they know about different skins if features and appearance are important to them.

But I'm thinking about the other people out there who are using something else.  They may see an announcement about the new XMPlay release and decide to download it so they can compare it to whatever they are using now.

So we have a shiny new toy and we don't want to show off the new features?  Because the sound alone should be enough to convince them to switch?  If sound was all it took, then they'd already be here and there wouldn't be any need to develop the new features and skins, right?

[Pike84]

So we have a shiny new toy and we don't want to show off the new features?  Because the sound alone should be enough to convince them to switch?  If sound was all it took, then they'd already be here and there wouldn't be any need to develop the new features and skins, right?

Well, my point at least was, that the current default skin is very good already. Also, I don't think the mentality around XMPlay has ever been about converting the users of other players, and the new features are mainly from community to community. Anyone can join it if they like, of course.

If sound was all it took, then they'd already be here and there wouldn't be any need to develop the new features and skins, right?

Many people think XMPlay is already good enough as it is, and it's not about just the looks or the sound; it's the whole package . I'm not saying the new features shouldn't be used though - perhaps the default skin could be updated, but we don't need a new one for every major update.

[oddiophile]

BUG: The EQ slider range is reverted to the old +-10dB   (v3.5.1.53 'stuff build' extended this trange to +-12dB)

and this:

- Will you please make the equalizer bands adjust by 0.1 dB using the mouse and the scroll wheel?  It's hard to match multiple bands.  

- Will you please also add an option to snap the playlist window next to the main window?

[Cypress]

By the way, is it possible to have some sort of anti-aliasing for the skins' edges? Skins with round forms, such as this one, suffer badly from those sawteeth .

yep that's the limitation of the current skining because either is complete solid or transparent ... just imagine the endless posibilities with the support of alpha transparency everything would look awesome to give an example of this take a look at this opera widget this is just a zip file renamed to the extension of wgt wich has inside an html+pic+xml file just drag this widget to the opera browser and you'll see semitransparent areas as well as some soft shadow test it at different backgrounds so u can see why PNGs are the future

just imagine instead of the mainPanel.bmp we would just export it to mainPanel.png
with the same functionality to keep things simple

the tiny widget here
http://www.mediafire.com/?cs5jebh98aag3pk

the opera browser here
http://www.opera.com/browser/

Saludos Cordiales

[mono_demon]

On Suggestions for 3.6 thread [ http://www.un4seen.com/forum/?topic=10659.0 ]
Theres a suggestion regarding playlist which is under Playlist and library
1) Play from library (bypass Playlist)
2) Replace playlist to start playing directly

the problem is, i cant bypass the playlist, or play directly from library.
i checked in the option, it seems i still have to manually add the files into playlist.
is those suggestion still havent been applied in the 3.6 version?

if it has been applied, how do i make it to play directly from library?
thanks! 

[NiZero]

There are problem with 3.6 version at least in Windows 7 x64 - it doesn't work from first start - player frozen if no xmplay.ini present (player can't create it?).
3.5 works ok, why?

[Dotpitch]

On Suggestions for 3.6 thread, theres a suggestion regarding playlist which is under Playlist and library
1) Play from library (bypass Playlist)
2) Replace playlist to start playing directly
is those suggestion still havent been applied in the 3.6 version?

No, those have not been implemented in 3.6. It's a wishlist, and it would've been an insane amount of work to implement everything.

There are problem with 3.6 version at least in Windows 7 x64 - it doesn't work from first start - player frozen if no xmplay.ini present (player can't create it?).

Trying it here, it indeed does freeze. It creates xmplay.ini, but that remains empty and the player freezes after the 'Welcome to XMPlay' dialog box.

[garson]

I expected Expand CUE file to virtual tracks would be implemented in 3.6.

[Pike84]

I too thought that it was of the more important ones - also for mods with subsongs.

[sampppa]

I expected Expand CUE file to virtual tracks would be implemented in 3.6.

Same here.

[Chinese Sausage]

[edit]By the way, is it possible to have some sort of anti-aliasing for the skins' edges? Skins with round forms, such as this one, suffer badly from those sawteeth .

+1

[deus-ex]

Code: [Select]

Plugins / Input
---------------
Priority filetypes:
    This is a space-delimited list of filetypes that the plugin will get 1st look at, before the built-in decoders
    and other plugins. Normally,  built-in decoders get 1st look at files, followed by the plugins (in the listed order).
I experimented with this new feature today and found that while it allows me to define which input plugin to use for playback it does not take this properly into account for the plugin info screens. That is sometimes I get the situation while a predefined plugin is used for playback another non-predefined plugin supporting the same file extension (not necessarily the same file format!) is invoked for the plugin information which shows garbage (non-readable text), in the worst case no plugin info screen appears.

I found this issue to appear when using the Winamp input plugin IN_XMP v3.3.0 together with two other Winamp input plugins supporting AdLib formats, IN_ADPLUG v1.8.2 and IN_ADT2 v0.962. Everything works seamlessly when just using both IN_ADLIB and IN_ADT2 which share support for several AdLib file formats. The issues appear when additionally using IN_XMP which also supports some AdLib file formats and among many other module formats one named Imago Orpheus that uses the same file extension .imf which is also used for Apogee IMF Files.

Examples for issue

• Playing an Imago Orpheus module with IN_XMP the plugin info screen of IN_ADLIB gets invoked which displays garbage.
• Playing any .amd file (AdLib format) no plugin info screen is opened.
• Playing .hsc files (AdLib format) for some files the info screen of the pre-defined plugin appears, for others no screen is shown.

Download from MODLAND (please feel free to browse):
Plugins: In_AdLib v1.8.2  ·  In_Adt2 v0.96.2  ·  In_XMP v3.3.0
Modules: AMusic (*.amd)  ·  HSC AdLib Composer (*.hsc)  ·  Apogee (*.imf)  ·  Imago Orpheus (*.imf)
 

My guess is (part of) the root cause probably lies within the plugin IN_XMP which does not allow to en-/disable supported file formats while IN_ADLIB and IN_ADT2 both support this feature. Previous to XMPlay v3.6 I was not able to use IN_XMP in a satisfying way at all as it grabs all of its supported file formats for playback overriding any other plugin with similar format support.

[Ian @ un4seen]

BUG: The EQ slider range is reverted to the old +-10dB   (v3.5.1.53 'stuff build' extended this trange to +-12dB)

Yep, the EQ slider range was switched back to +/-10 dB. I realized that many skins label the EQ sliders, and figured it wasn't worth breaking them just for 2 extra dB

What I may do instead is only extend the range in the DSP options page and/or allow skins to define their own EQ slider range.

There are problem with 3.6 version at least in Windows 7 x64 - it doesn't work from first start - player frozen if no xmplay.ini present (player can't create it?).
3.5 works ok, why?

That's a strange one. It seems to be related to a change that was made to block the screensaver when fullscreen vis is active. A modification of that is now up in the XMPlay package. Let me know if you still have any trouble with it.

Code: [Select]

Plugins / Input
---------------
Priority filetypes:
    This is a space-delimited list of filetypes that the plugin will get 1st look at, before the built-in decoders
    and other plugins. Normally,  built-in decoders get 1st look at files, followed by the plugins (in the listed order).
I experimented with this new feature today and found that while it allows me to define which input plugin to use for playback it does not take this properly into account for the plugin info screens. That is sometimes I get the situation while a predefined plugin is used for playback another non-predefined plugin supporting the same file extension (not necessarily the same file format!) is invoked for the plugin information which shows garbage (non-readable text), in the worst case no plugin info screen appears.

Does that issue only apply when viewing plugin info for playlist entries, not when viewing plugin info for the current track? Note there are different shortcuts for each of those things. In the latter case, the Winamp plugin being used to play the file should also be used to display the info. The "Priority filetypes" processing doesn't currently apply otherwise though; I'll look into that for 3.6.1.

[Dotpitch]

There are problem with 3.6 version at least in Windows 7 x64 - it doesn't work from first start - player frozen if no xmplay.ini present (player can't create it?). 3.5 works ok, why?

That's a strange one. It seems to be related to a change that was made to block the screensaver when fullscreen vis is active.

Erm... just curious, what exactly went wrong there? What's the link between simulating keypresses and writing files?

[deus-ex]

Does that issue only apply when viewing plugin info for playlist entries, not when viewing plugin info for the current track? Note there are different shortcuts for each of those things. In the latter case, the Winamp plugin being used to play the file should also be used to display the info. The "Priority filetypes" processing doesn't currently apply otherwise though; I'll look into that for 3.6.1.

I wasn't aware of the two different plugin info shortcuts just until you pointed them out. I confirm that when accessing plugin info for the current track all works as expected like you described above.
Thanks for the clarification, Ian.

And now a Merry Christmas to all of you!

[NiZero]

There are problem with 3.6 version at least in Windows 7 x64 - it doesn't work from first start - player frozen if no xmplay.ini present (player can't create it?).
3.5 works ok, why?

That's a strange one. It seems to be related to a change that was made to block the screensaver when fullscreen vis is active. A modification of that is now up in the XMPlay package. Let me know if you still have any trouble with it.

XMPlay 3.6.0.1 works from first start, but there is no information about first start now - such as popup window with RTFM etc. and opened xmplay.txt

[Ian @ un4seen]

That's a strange one. It seems to be related to a change that was made to block the screensaver when fullscreen vis is active.

Erm... just curious, what exactly went wrong there? What's the link between simulating keypresses and writing files?

The problem wasn't actually related to the XMPLAY.INI writing, but rather the displaying of the "Welcome to XMPlay" message. More specifically, the use of the AttachThreadInput function to attach the input processing of XMPlay's update thread (which displays the welcome message and performs the screesaver blocking amongst other things) with the main thread seemed to result in the main thread not processing any Windows messages (hence the GUI freeze) after the welcome message was shown on Win7. I'm not entirely sure why it had that result, but the use of AttachThreadInput was changed to avoid the issue.

XMPlay 3.6.0.1 works from first start, but there is no information about first start now - such as popup window with RTFM etc. and opened xmplay.txt

Did you delete the XMPLAY.INI file? If not, please try that, as the welcome message will only be shown if the file doesn't exist.

[NiZero]

XMPlay 3.6.0.1 works from first start, but there is no information about first start now - such as popup window with RTFM etc. and opened xmplay.txt

Did you delete the XMPLAY.INI file? If not, please try that, as the welcome message will only be shown if the file doesn't exist.

Of cource it were deleted, but nothing happens next time - just XMPay with default settings and new xmplay.ini created.

[Philidor11]

Using the Play All button for a symphony in a folder still produces 4 instances of XMPlay, each playing a different movement simultaneously.

Was hoping 3.6 would include a fix.

As someone graciously pointed out, right-clicking on a folder and left-clicking "Open with XMPlay" works, but sometimes that's inconvenient.