View Single Post
Old 22nd December 2014, 03:36   #20
DrO
 
Join Date: Sep 2003
Posts: 27,873
i've finally had a chance to have a quick play with the plug-in (using 0.2.4667-beta9) and the playback reliability and quality seemed good to me.


building isn't quite as clean as i've only got VS2008 on here. the core libopenmpt built ok from what i could tell with the project in the build\vs2008 folder. the final plug-in dll doesn't at the moment due to differences in the stl (as i see it's aimed at VS2010), but i've got something that vaguely builds to the point i can check dependencies, config dialog, alt+3 but not playback at this time of night. (though for Winamp in general, we need to move on from VS2008 sooner rather than later).


with the officially built plug-in, the only things that jumped out immediately is the alt+3 info handling (where it just dumps it all into a messagebox) which would need to be changed to the common alt+3 handling added in Winamp 5.5. and then there is it writing it's settings into the registry whereas all native Winamp plug-ins use the settings folder and avoid the registry unless needed in-order to be able to portable. that is the most obvious difference that would need to be changed (or it could be maintained and disabled if Winamp is in a portable / no-registry mode as it can also be configured to run in).


so based on what i've seen so far, i think it's something i will look to do a bit more work on to see if there's anything else / what will need to be implemented to make it comparable to the existing in_mod functionality (which from a quick check is transcoding support, some metadata api support and whether to provide the means to control which loaders are enabled like in_mod does).


as such, i think i can say that at some point in the 6.x release there should hopefully be a an in_mod v3 based on libopenmpt in place of the existing mikmod based version.
DrO is offline   Reply With Quote