I started implementing it back then, but it was kinda low priority, and I never finished it... now that you've reminded me, I'll have another look at it (and the HP filter thing too).

Sorry, I don't have any neat package of code to give - it's all tied in with other stuff.

Although XMPlay doesn't use standard Windows controls (buttons/scrollers/etc), you could probably recreate a similar effect/behaviour subclassing the standard controls.

Nope, XMPlay does not use "p-code".

As far as I'm aware, "p-code" = psuedo-code = interpreted = slower

Yep, should definately be a tray menu item for the "Options and stuff", and maybe a hotkey too... I'll put an updated EXE in the 2.8 ZIP shortly, so if anyone has any other little annoyances to sort, post them here now

Nice to see that most peeps like the update

But i still miss a stop button in the tray meny when XMPlay is in the system tray  :-/

Didn't think of that, as I mostly use hotkeys myself... mostly. I'll try to remember next time

I think that it would be a good idea to make XMPlay start in tray when "Always in tray" option is selected. At this moment you have to minimize it after it starts to make it  drop to tray. This one click isn't a big deal, but I think that it would be more logical to always keep XMPlay in tray when somebody selects "Always in tray".

When "Always in tray" is enabled, XMPlay should start with the icon in the tray (rather than the taskbar)... does it not do that there? (note: that doesn't mean it starts minimized though )

Boggy has the idea. The edit control has the id 0x480. Send the BN_CLICKED notification (for the "OK" button) to the parent window to make the change.

Yep, you could use a template instead of creating the extra controls by hand. Either way, you'll still need to implement a callback/hook function to initialize your controls and process notifications from them

You need to specify a callback function in the "lpfnHook" member in the OPENFILENAME structure when you call GetOpenFileName, and then create the extra contols in that callback/hook function when it receives the WM_INITDIALOG message... I'm sure there must be Delphi classes that'll simplify the process for you though

are you rendering non-visible columns too?

Yep, the whole pattern is pre-rendered. This makes scrolling very fast/smooth, but does mean that there can be a little delay (dependant on number of channels/rows and CPU speed) in pattern changes... I think this is preferable to fast pattern changing with slow/jerky scrolling

When there are many tracks in a module, the pattern changing lags somewhat (similarly to MPT's follow mode)...  My problem is that some releases ago this lag used to be less noticeable.

I guess that would be since the channel scrolling was added? In the old days, if there were loads of channels, the channels would be bunched together and the volume column would be removed from the display. But now with scrolling, that doesn't happen, so there is more rendered than before.

Yep, I've replied now

Do you have the output set to 24/32-bit? It sounds like the problem described in this thread...

http://un4seen.com/YaBB.cgi?board=xmplay&action=display&num=1053277928&start=30

It doesn't only affect XMPlay - it affects other programs too, but as most don't use 24/32-bit output, you probably won't notice it

I'm not planning to start on XMPlay 3.0 for a little while yet (after BASS 2.0), but yep, this could be something for 3.0... with so many people wanting to do translations, how can I refuse?

Nope, string resources are not used. There are 3 types of text in XMPlay...

• GUI/skin... these obviously can't be changed, but there's not too much text like this.
  
• Dialogs & popup menus... these are in resources, but that's dialog/menu resources.
  
• Info text & help bubbles... these are hard-coded.

The last 2 could be made to use string resources, and it is an idea I've considered in the past as there have been offers to translate it to a few languages, but the problem is maintenance - when text is added or changed, the language "packs" would need to be updated too. For example, if there were language packs prior to 2.8, they would have needed a major update

Check that you've got the track looping (bottom-right of the main panel) switched off.

Brightguy & Tsorovan... The "Output Options" panel was kept because it contains stuff (amp/eq/reverb/etc) that it's useful to be able to access quickly without having to open another window (or maybe while you're doing other things in the "Options and stuff" window). Whereas the other left panels contained options that would probably be used very rarely - you'ld likely set the options once, and leave them like that - so it made no sense to keep those panels, with the new "Options and stuff" window.

Removing all the left panels would also seriously break most existing skins... a big hole in "Vintage", for example

Nah, still no VERSIONINFO

Anyway... I think I'll leave the existing skins that look fine as they are, and just recompile the couple that need a little altering (ie. to remove the obsolete panel names).

It was a tricky decision, but the fact is this change had to happen sooner or later, to be able to add new options without being restricted by what would fit in the panels. It would probably be best if it was 3.0, but I'm not sure that the overall changes are revolutionary enough to warrant a jump from 2.7 to 3.0, and I'm sure you lot wouldn't want to wait any longer for the next XMPlay release while I thought of and added the "revolutionary changes"?

I was considering leaving the "Miscellaneous" panel in, so that any fancy author logo would still be visible, but in the end I figured that would just be half-assed, and it was best to go the whole way. Also, the fact is that with most skins, the removed panels were purely functional, and did not contain any frilly stuff - only really Graphite, Risky, Windows Classic and X-RD2506 have special graphic bits there. And with the vast majority of skins, one will not even be able to tell that there were once other panels

The skin author URL will be in the "Options and stuff" window (there's also a new "author name" skinconfig option to be displayed instead of the URL). I may also also add a "skin author" button in the main panel.

Btw, the new skins will display a warning when used with older XMPlay versions, so that the user is informed that they need to upgrade.

Well, let's see which buttons will be on the new panel. I might be arsed to completely redesign it for 2.8
Same with Windows Classic and Snatch... Dunno about Wood yet... I think it's obsolete... What do you think?

I think only X-RD2506 and Windows Classic will require a bit of fiddling, to remove the obsolete panel names... Snatch and Wood look perfectly fine as they are

I say no. A program -- barring any major whole-number version changes, which this update is not -- should always be back-compatible. This includes, in my opinion, skins.

However, if it is not feasible, I would have no problem redownloading all available official skins, if necessary.

I think you may have misunderstood, so I'll just clarify

You won't have to redownload any skins - existing skins will work just fine with XMPlay 2.8 as they are (the obsolete panels just won't be used).

The question is whether to remove those obsolete panels from the existing skins to reduce the filesize? The skins will work with XMPlay 2.8 either way, but with the panels removed, they won't work with old XMPlay versions.

Oh, and while I'm here, would there be any way for me to get back on the beta-testing list?

There were several requests to beta test 2.7, but I got no reports back from most, so I stuck with the usual small group this time

But, ok, if you're a hardcore user with a keen eye for a bug

XMPlay 2.8 will be available very soon. The most apparent change will be the integrated "Options and stuff" window... it turned out so nicely, that I decided to remove the "Device Setup", "Integration", "Miscellaneous" and "Plugins" panels - only the "Output Options" will remain in the left panel.

This will make XMPlay a bit smaller, but more importantly, it will also make skin files a lot smaller (and, of course, mean less effort to create them too ).

So, the question is whether to recompile the existing skins with the obsolete panels removed?