For those following my intermediate updates on twitter then you’ll already know some of the things that will be covered in this combined update (which was started on monday but things got in the way so I’ve decided to combine in week 38 as well since i’m not likely to do much else this weekend). So without holding you up any more, lets get on with the update for the last two weeks…
The main thing done has been getting the bits needed to allow for tweeting what is currently playing in Winamp and was based on a recent user request to try to get around issues with the service that they’re currently using. So by shifting it to Winamp it should a) be more reliable and b) give better control over what is posted.
As can be seen from the screenshot above, it’s making use of Winamp’s ATF (advanced text formatting) support which makes it easy to use the metadata from the current file whilst still being able to add in normal text.
Since the tweet I put up about this, I’ve improved the handling so it now makes an attempt to warn from the preview if the tweet will be over size by changing the text colour of the group header in addition to just showing the character count.
Overall even with eventually finding a usable library to add this support it’s taken a bit longer to get done and working nicely than I’d expected it to take. The main pain was dealing with the authorisation aspect and getting the preferences UI to transition between the different steps involved (as you need to enter your details, then enter an access pin and then hope it’s all correct :) ). But the main thing is that it’s now in and works though am sure I’ll need to do some tweaking of it once it’s available to test.
Related to getting tweeting working, I decided to use twitcurl which relies upon libcurl (something I’ve previously used). As I’ve in mind making more use of it [libcurl] to do networking instead of using the existing jnetlib (which as covered months back doesn’t do HTTPS or more recent web technologies correctly or at all). So the end result is making a libcurl.dll for WACUP which allows for it to be more easily shared around (depending on how things progress).
If only everyone creating #podcasts cared about providing metadata tags.
Good thing I can now correct that with my #winamp update project :) pic.twitter.com/fMNIWI176F— Darren Owen (@The_DoctorO) October 5, 2016
Going back to something from early in Week 37 and based on a feedback response, I’ve added the ability with the podcast handling to auto-fill in the tags based on the feed and episode information for those fields not set.
This is configurable via the preferences option highlighted above (default on) and will set title (episode title), artist (feed name), genre (just set as ‘podcast’), year (using published date information) & comment (episode or feed description depending on what is available).
I’m hoping that this will be helpful for those using Winamp to handle their podcasts as it’s already helping me in addition to the tooltip preview :)
The only other big addition has been a new diagnostics preference page tab which was based on some of the week 34 comments relating to memory usage to produce the following:
Firstly the numbers reported come from an OS provided API but don’t necessarily match up with what you may see in Task Manager or other tools (as that gets / calculates things in a different manner I believe). So like with any comparison, as long as it’s done consistently then that’s the best way to go (i.e. using this page).
I have gone a bit further than I initially thought and added the button and also the option which is an automated way of pressing the button not long after Winamp was started. Whether any of that is helpful or not is debatable as memory usage and impact on usability varies depending on the system, how much is used, what other programs are doing and using, etc.
So my thought is that this new page and options might be helpful for some (and myself as well to have a consistent measure for memory usage) but maybe not for everyone (other than the checkbox option :) ).
In general the OS is smart enough to know how to handle what memory it keeps available but once Winamp has been loaded, as can be seen from the screenshot, there’s a lot of potentially allocated or briefly used memory which is no longer directly needed and so can be recovered. This doesn’t mean Winamp is being bad in itself as a lot of the working set usage can come from just plug-ins being loaded and their initialisation code which is then never used again which is then OK for the OS to recover (either when forced or as it should do eventually with time).
Otherwise I’ve been working on some odd bugs I’ve found (nothing major, just little niggles) and trying to work out why an older modern skin (Vortex) was crashing.
The Vortex skin crash when starting playback happens in a component of Winamp which isn’t checking a timer delay from the skin correctly and based on what I remember of the bug reports that compatible Winamp releases were sending showed similar crashes. Fixing it is a bit tricky as there is source code for most of the component that is at fault via an older wasabi sdk but the skin source doesn’t exist either (and maki decompilers are very crude so it’s not simple to track down and fix it from that side). But at least I know what is causing the issue and can try to make a live patch or even a complete replacement component as time allows.
So that’s it for this combined update of what’s been going on over the last two weeks. I now just need to keep my head down and get on with things as the week of the 31st October should hopefully be an interesting one. Here’s a general summary of what was talked about:
- Winamp can now tweet what it’s playing
- Auto-filling missing tags in Winamp downloaded podcasts
- Adding some basic memory reporting / recovery options
- Looking at some weird and wonderful bugs
- The end of the month should be interesting…
-dro
Good to see that you’re still able to make a little progress. I’ve been lurking and watching the progress since Radionomitry bought WinAmp several years ago, and I’ve just been trying to keep the faith. I still use the latest build you’ve released, and I wait patiently for the next. I’m so glad that there are a dedicated few that love the product as much as I do, and still but their time and effort behind making this the best product it can be.
Even if another version sees the light of day, I just want to say thank you for everything you’ve done, Dr. O. You are awesome.
New features look cool, and I’m excited to try them out someday.
I’d offer to help code some things, but the explanations up on the site about why you guys don’t really want to bring new coders on, is completely understandable. So, I’ll just wish you guys tons of luck and lots of love. Keep up the great work, and take your time!
What about Winamp 5.7 Beta tweaks?
Celerian: Just to make sure it’s clear, what I’m doing is in no way affiliated with Radionomy / whoever owns Winamp so any updates I put out (soon as per this latest update) are completely separate from anything that may or may not see the light of day from it’s owners. So what I’m hoping to achieve overall is based on the fact that Winamp for Windows (nothing can be done about the other platforms [Android and OS X / macOS] due to them being monolithic programs i.e. a single program file with no plug-in system).
Anyway, mainly just wanted to thank you for the kind words and to hopefully clarify things a little bit (as a few things in your comment made it seem like this was an official update).
Vygantas: I’m not sure what “5.7 beta tweaks” you’re referring to.
The Winamp 5.7 releases were paired with Winamp 5.64-65 releases .The only difference between the two being that the 5.7 betas had the failed Winamp Cloud feature, otherwise everything that was in the 5.7 betas were in the paired 5.64-65 releases. This means that the 5.66/666 releases (which are ~6 months newer than the last 5.7 beta release) should have everything that went before along with all of the final tweaks, etc that were able to be done in those final AOL owned days.
So if there’s something you’re specifically missing then please let me know and will see if there’s something I can do or suggest to help you out.
Hi DrO, all right?
Thank you this changes about memory, an suggestion, a action on wacommand to Call Empty can also be fine. DrO about an other post about changes in ML, playlists list, go some suggestions, an good thing is add an Search Field (filter) in Playlists, Bookmarks, History etc, and also to Milkdrop presets to search including presets in multiple folders, an preset bookmark can help much too, it is to users with many presets (I have + or - 40k). Other thing is keep the focus (blinking cursor) when use Clear Search in ML fields, because after, the user many times do an new search. Other suggestion is an global setting to search fields font size (or also for buttons) instance ML, JTF etc, to users which like big fonts, and mainly who need, is an accessibility. bye
Thanks for all your hard work!
Lucas: I’m ok thanks, just a bit hectic trying to get things ready for the last week of the month.
I’m not sure what you mean by “a action on wacommand to Call Empty”. Do you mean clearing the playlist or something else?
The history view already has a search filter. For the playlists and bookmarks views, it’s something I’ve in mind (see https://getwacup.com/blog/index.php/2016/07/07/library-playlists-looking-for-ideas-for-its-replacement/#comment160708-124549 for what I’m thinking about for a normal playlist view) though for the general root items I need to think about how best to do it so the results make sense i.e. just show the playlist that it the match relates to (easier) or show the match from within the playlist (more complicated).
Doing things with Milkdrop to be honest isn’t something I’m too interested in doing. Though I had thought that Milkdrop already had a search option already built-in. If not with the source code for it available, there’s nothing to stop someone else with an interest in messing around with it to see if they can implement what you’re asking for.
The focus aspect could be done but it’d then be trying to work against normal UI handling i.e. when you click on the clear button then that by design sets the focus to the button being clicked. So forcing the focus back to the search field would be a bit odd (it’d also likely break tabbing support around the dialog). The alternative if using 5.666 and a compatible language pack is to press F6 and that will re-focus the search field - not as automatic as you’re wanting but it’s the best way without introducing other problems.
With the final thing re: font sizes, they should already be following the global playlist font size (unless that option has been un-checked) so by making that larger should then make all of the other UI elements like buttons, menu text, etc consistently larger. Using Ctrl + NumPad Plus / NumPad Minus when the playlist editor is focused can allow for changing that (alternatively there’s the option on the playlists preference page for the font size).
Dro, thanks, I think than MD incredibly dont have search, or I dont know how use, about playlists search I think which results only by the playlists title is better, but is possible also an checkbox to switch the mode. But I think which almost ever the user search the title.
For Milkdop I thought it was F3 when the Milkdrop window is focused (I don’t have it installed currently to check). You can also press F1 with the Milkdrop window focused to see what the keyboard actions are.
With the playlist searching, I always thought that it’d make more sense for it to match the search to any part of the data that is available from the playlist (much like how the jump to file search works - which looks at the filepath and the stored playlist title). Though I’ll take you comment on board for when I get around to implement playlists search.