Latest restricted WACUP beta release is build #16956 (September 23rd 2023) (x86 & x64 changelogs) | Latest WACUP public preview is build #16956 (September 23rd 2023) (x86 only)

NOTE: Beta testers are added in a limited & subjective manner as I can only support so many people as part of the beta test program to keep it useful for my needs.

Unless I think you're going to be helpful, not all requests will be accepted but might still be later on. Remember that beta testing is to help me & the limitations currently works for my needs for this project.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Aminifu

Pages: [1] 2 3 ... 23
General Discussion / Embedding albumart in MP3s
« on: August 30, 2023, 07:21:24 AM »
What is left to be done before WACUP is able to embed albumart in mp3s again?

Skins / Re: Graphic Equalizer window of the JVC Tape v1.2 modern skin
« on: July 20, 2023, 03:39:39 AM »
I found a simple way to simulate a stereo response for modern skins with left and right channel vis displays. Just add different "speed=" values for each channel to the code in their xml files that control the frequency responses. Experiment with different values to get a variation between the channels that you like.

Of course these are not accurate stereo responses. However the result looks pretty good and can closely match what you hear, if the variation is kept small

All this time and I never knew that listview controls is part of Windows. Some of my apps use them and some block them. The control I like is the one that auto-sizes columns based on the widest item in the column.

If WACUP allowed that one, it would make configuring ml views a no-brainer for those who don't mind horizontal scrolling.

Skins / Re: Graphic Equalizer window of the JVC Tape v1.2 modern skin
« on: July 16, 2023, 07:53:09 PM »
Hi Eris,

I know that Winamp/WACUP doesn't provide direct stereo channel support. In some cases, the mono data provided can be made to simulate  stereo. The simulation is not 100% accurate, but it's better than nothing, imo.

What I did with some skin scripts (that exposed their control logic) is duplicate the applicable control section and added an additional timer (so that each section has it's own timer). Then I slightly adjusted the responses frequency ranges for 1 of the control sections. Finally I assigned 1 section to the left channel and the other to the right. This is what I referred to as a 'fix'. I should have said a 'work-around'.

The control logic is not the same in every skin, but I've been able to apply the basic idea to exposed control logic for some visualizations and animated speakers.  I can pm you examples of what I did, if you want to see them.

Skins / Graphic Equalizer window of the JVC Tape v1.2 modern skin
« on: July 15, 2023, 06:53:51 PM »
@Active Skinners,

The left and right channels for the 18 band spectroscope on the graphic equalizer window of the JVC Tape skin respond exactly the same. It's looking like my stereo tracks are mono.  I can clearly hear the difference between the left and right channels in most of my music. It would be nice if these left and right channels simulated that, even if somewhat inaccurately.

I've been able to 'fix' this with other skins with similar animated displays. I've not been able to find the script(s) and/or xml files in this skin that control these channel responses. I want to change whatever is needed that would slightly alter the responses between these channels. I would greatly appreciate any help with this.

Sorry for the miss-information. I need to do better. You are correct.

In my defense, such as it is, I have v2.0.5 installed with Winamp and I very seldom use it. I try to keep up with what's going on with Winamp, but other than a brief period of testing a new release, I only use it when I need to embed album art. Now when I need to do that, I mostly use the Quinto Black CT v3.7 skin.

Now that you have pointed out my error, I remember that I don't like the way coverflow works in v2.0.5. I should have said it works differently, instead of saying it doesn't have the feature. I now remember I don't like a lot of the changes in v2.0.5.

As you know, there are 4 images instead of 5 and the portions of album art are larger in v2.0.5. It takes a little longer for each image to appear and I don't have the same image repeating when I load Winamp with v2.0.5. It works as expected, in that I get the images from the selected track in the playlist and the first few following it.

Of course WACUP, with core code changes, now works a lot differently than Winamp, internally. Anyway since you don't have my coverflow issue with WACUP, it probably is something in my configuration or the way it's setup causing this issue (which is very easy for me to live with since a solution has not been quickly found). Of as dro says, it's due to the way gen_ff lets requests for metadata from different threads at the same time get stepped on.

Hi ariszlo,

I'm also using your script that displays in the seek bar tool tip the percentage of playback used and scripts for animated speakers from another skin. I didn't bother to disable them to see if they're involved with the coverflow issue. I'm going to keep using these scripts even if they are.

Version 2.0.5 doesn't have the coverflow feature. It's the main reason I'm not using it, along with a bad implementation of automated speakers, imo.

Hi dro,

You jinxed it this time. The coverflow feature is back to it's bad behavior. It again only starts working correctly when another track is selected or when the next track starts playing after the initial track has played.   ;D

Hi ariszlo,

Nothing I try gets the coverflow to work correctly when this version of the skin is initially loaded with my configuration of WACUP. So, I returned to the script version released 8/19/21. Please don't waste more time looking into this. It's easy for me to get it working, as I explained earlier. I simply need to do whatever action that causes WACUP to issue a title change message.

The important thing for me is you got the expected 5 line display to work correctly all the time (when first loaded and during playback regardless of what's listed consecutively in a playlist).

Have you noticed the number of times this thread as been read? It appears there is a lot of interest, but only a hand-full of people have chosen to make a comment.  ::)

Good news. With the latest beta v1.9.10.16000, the coverflow feature corrects itself as soon as playback starts.

Hi ariszlo,

Main thing, no more crashes when using this skin. Must have been something else triggering them.

Thank you very much for the updated fileinfo script. Now I always get the expected 5 line display in the info box.

I'm still seeing the same album art for the initial pl selection displayed 5 times in the second info box, instead of album art for the first 5 pl entries. It's really not a big deal since it corrects itself after the initial selection is played or I switch to another selection. Since you're not seeing this, it's probably something it my configuration causing it. I'm only using mp3s at the moment and all the files have embedded album art images.

I'm also using the gen_win7shell plug-in that dro updated for use with WACUP. It can be used for customizing what's displayed when pointing to WACUP's taskbar icon. I configured it to display album art for the pl selection as it's background. Sometimes this album art is not displayed. Maybe this plug-in or whatever is causing it to randomly fail to display album art is involved with why I see multiple versions of the same album art for the initial pl selection upon loading WACUP with this skin.

I didn't know that WACUP has the ability to auto-resize columns relative to their headings. I missed or overlooked the announcement of this feature. This may be getting inadvertently triggered somehow causing the column width changes that I randomly see.

Following is the line in the changelog for the fix I'm talking about. I'm probably not understanding what it means.

"Fixed some of the local library view column sizes not always being saved due to not getting the expected listview notification"

I certainly agree that the column width changes I'm seeing should not be happening. I'll take some screenshots now and when it happens again so that you can see what I'm talking about. There are slight changes due to different fonts, but that is not what I'm referring to. After you see it, maybe you can come up with a possible reason for why it is happening. Probably gen_ff 'dropping the ball' from time to time.

I believe you that my suggestion to save individual configuration data in the studio.xnf is not possible. Saving individual configuration data would not be needed anyway, if the global scheme worked as it should (which it usually does). I have only seen the files in the users plugins/ml/views folder updated when I make an associated configuration change.

The next time this happens, I'll check to see if a file was changed before I re-configure. If not, I'll see if a shutdown and restart fixes things.

The current global method of maintaining the selected configuration of views within the media library appears to work well for classic skins, but not as well for modern skins.

More often than what I would like I have to re-configure these views when switching between modern skins due to unsolicited changes of set column widths. It happens most often with the history and playlist views. I have not had to re-configure when using and switching between classic skins. Since I mostly use modern skins, maybe I just have not seen the need to do so yet.

Any small inadvertent changes made when re-configuring then affects all skins. Maybe these configurations should be saved individually for each modern skin in the studio.xnf file. Unlike classic skins, the overall media library windows are not the same size with modern skins. A particular column width could work well for one modern skin, but not another.

The changelog for the current beta states a fix was made for this issue, but this fix is not working for me.

Hi ariszlo,

I'm happy with the script you suggested I use for fixing the info boxes in the DeFix skin. But, there is something happening that I want to tell you about. When first starting a WACUP session with this skin and script, the info boxes are not showing the expected info. But after the first selected file in the playlist is played (or manually switching to the next file and back) everything looks as expected.

One of the info boxes displays 4 lines (title, location, year and decoder) instead of the normal 5 lines (title, artist, album, year and decoder). The title displayed in the 4 line display is the ATF string used by the playlist editor window instead of the track's title that is displayed in the 5 line display.

The other info box normally shows the full albumart from the selected track and slivers of albumart from the next 4 following tracks. When first starting (before completing playback of the first selected track or switching to the next track and back) the full albumart and slivers of albumart shown are all from the first selected track.

I assume this is happening because the System.onTitleChange function in the script doesn't execute until playback of the first track completes or the first selected file is changed.

Also I think this skin with this script maybe causing the latest version of WACUP to crash, if it is left loaded without starting playback for an extended amount of time (30 minutes or more). I have no proof of this other than WACUP has not crashed when left loaded and not playing anything with other skins for around the same amount of time. I normally don't load WACUP without soon starting playback. However I have been using WACUP's ALT+3 file editor (the last two days) to edit the metadata in some of my files without starting playback. When I do it with this skin loaded a crash occurs after a half hour or more. When I do the same thing with another skin loaded no crash. There has also been no crashes when using WACUP to play files with this and any of the other skins I use, while editing files that are not in the playlist. This is weird, doesn't make sense and is probably circumstantial, but the crashes the last 2 days have only happened when this skin was loaded without starting playback. Can you think of anything this skin and script could be doing without starting playback that could cause a crash?

I know that I can't use the ALT+3 editor to edit a selected file that is playing. I can edit a selected file that is not playing, but could that be leading to the crashes? I've also been using this skin's feature that lets me get info for the selected PL file thru my external web browser. Could this be leading to the crashes?

Pages: [1] 2 3 ... 23