Week 6

It’s now the end of week 6 which some might have noticed I’m posting on the correct day unlike last week and the main things have been getting the library export via the command-line working (without output to M3U, M3U8, PLS, & CSV file formats) as well as working on some updates for a replacement of the module decoder plug-in (in_mod.dll) based on libopenmpt (which already provides a basic Winamp input plug-in but it doesn’t implement all of the functionality needed to integrate fully into the recent Winamp releases.


The exporting functionality was as much as I’d gotten done as importing (as I’d hoped to have done by now) needs a bit more work to be done to determine the best approach as well as looking at means to obtain metadata from the files to be added when Winamp is not running. As the native input plug-ins can be made use off when Winamp is running to get the appropriate metadata, but when it is not (which is somewhat important when allowing things to be done via the command-line as needed. At the moment I’m seeming to be going towards taglib being used to aid with this scenario. Though I’m also partially tempted to use it (and a few other options) to generically handle tags on all of the input plug-ins

One additional thing with working on the library export handling was that I’ve greatly reduced the time an export takes for PLS and CSV formats going from 2-3 seconds down to less than 0.5 seconds for a like-for-like comparison. These changes also being rolled back into the library exporter plug-in which will be included though I’ve still to optimise how the code is provided (as it’s a bit silly providing two copies of code that do the same thing *cough* jnetlib.dll and jnetlib.w5s *cough* ).


With the work on the replacement module decoder plug-in (in_mod.dll), providing a version based on based on libopenmpt was something that had been agreed on when I was working on Winamp but nothing happened due to changing circumstances.

The reason for wanting to make this change is that the existing module decoder plug-in hasn’t been updated in years (it’s based on an ancient version of mikmod) which is a bit too crashy for a lot of people’s likings along with not being comparable on module support and output quality. And yes I’m aware that there are newer versions of mikmod that a replacement module decoder plug-in could be based upon that but I quite like the libopenmpt version and the way it works.

So this week I’ve started on some of the work needed to make it better integrate into Winamp (as the version currently provided is more akin to that which will work with 2.x and not a recent 5.x release), with the following being implemented so far:

  • basic metadata reading (e.g. for ATF support)
  • unified alt+3 dialog (to be consistent in ui)
  • in-Winamp plug-in uninstall support (something that not many use but is handy if a plug-in fully supports it)
  • changing to use the Winamp settings folder instead of the OS registry for settings (which allows for portable support to work)
  • few other misc tweaks to preferences and library dependencies

I’ve also been toying with some of the enabled functionality compared to the version currently provides and will be doing a bit more testing to see how that works out. The only thing that I’ve not fully looked at is what is needed for the library to support certain module files that use external sample files (i.e. the examples provided with the main OpenMPT program) but that’s possibly not something for me to worry about but it’d be nice to see the replacement working consistently for comparison between the two :o)


Otherwise I’ve done a bit of tinkering to get Winamp to not wait for so long after uninstalling a plug-in or being instructed to restart itself (which was a bit of fun to get that lowered to a few 100s of ms instead of 5 seconds). I’ve also been messing around with intercepting metadata reading from input plug-ins so the response can be altered as needed (e.g. making the 64th Note input plug-in provide a ‘%type%‘ and ‘%family%‘ response so it doesn’t list under ‘other formats’ during Winamp setup without having to try to recompile such an old plug-in that was aimed at Visual Studio 6!).

Sadly I’ve had no responses to any of the attempts I’ve sent regarding older plug-ins that I’d been looking at including. So they’re replacements have now been added to the todo list to be started on in the coming next few months.


For the coming week, I’ll hopefully be looking into some query changes / additions for the replacement library engine (I needed a few days off from that code to clear my mind) and forcing myself to get the comments system working on here. Plus doing any further research and tinkering that comes to mind, so until next week, have a good one.

-dro


Comments:

  1. As this comment exists, I’ve got the comment system working at last!

    [edit]
    There’s a bit more to do but things should suffice as a starting point.

  2. Yes it is! Finally! =)

  3. Even on mobile. Nice website by the way, clean and neat, as your coding? XD

  4. Thanks Victhor for the confirmation that it’s ok.
    I wouldn’t call my coding clean by any means :o)

  5.   Lycanphoenix  |  Sunday, April 24, 2016 - 00:22:55

    One of the very first things I wanted to request (and have always wanted) was using OpenMPT’s sound engine instead of the existing module decoder, so I am glad that I read this little tid bit first. Something that I do not like about the old plugin is that you multi-song modules are more difficult to manage without “Seek by Pattern/Row”, but not only do I have to go into and out of the preferences menu to enable/disable that, having it enabled messes with the classic skin’s built-in visualizer (maybe have an option to display hexadecimal Sequence/Rows alongisde Minutes/Seconds?).

    On the subject of the Classic Skin, it would be nice if the built-in visualizer was available in more framerates/colors (cyan/blue/purple, 60 - 144 FPS, etc)… and if it was all in optimized PNG format instead of BMPs (the executable PNGgauntlet is very useful for this), then it might use even less memory. (Switching to Grayscale, Tiled or Paletted graphics might even allow people to change the classic skin’s colors!)

  6.   Lycanphoenix  |  Sunday, April 24, 2016 - 04:10:55

    So, it turns out that 134.BMP inside winamp.exeBITMAPS… is corrupt. Won’t open at all. Which sucks.

    Currently in the process of converting everything else to BMP though.

  7. Lycanphoenix: bitmap #134 appears ok for me when extracted via resource hacker (http://www.angusj.com/resourcehacker/).

    With the classic skin vis and the fps it runs at, that’s something which is built-in so other than completely overriding the functionality, I’m not aware of anything obvious that would allow for it run at a higher fps. with the colouring, it can be changed via a custom skin which is just the specific parts of an extracted Winamp base skin and modifying that. Thinking about it, it might be handy to provide a copy of that anyway.

    As for using png, it’s only the local file size that is smaller (and the convenience of png over bitmap), the size of the decoded image data is still going to take up the same amount of size. But providing a means to use png instead of bitmap files was something I’d looked into when I had an official hat on, but it’s still something that I’d like to do.

    As that might have to be done as part of a possible replacement classic skin engine that follows the classic skin specification but allows for other files, the potential of better alpha support and ideally being able to scale to an arbitrary size (for all of the Winamp skinned) instead of the limitations present on just some of the built-in windows (as a means to make Winamp a bit more usable on higher DPI setups).


Add comment:

Fill out the form below to add your own comments