Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

Can you use "git diff" to generate your patches, or at least use unified diff format ("diff -u")?

Problem is, I see a block of code like this ...

358a412,413
>     bool prev_songautoeq = aud_get_bool("audacious", "equalizer_songauto");
>     s_songautoeq = prev_songautoeq;

What do you think about making the user interface for this feature much simpler?

1. Turning the AUTO button ON would immediately save the current equalizer settings to an auto-preset for the current song.
2. Turning the AUTO button OFF again would delete that auto-preset and return to the previous equalizer settings.
3. When a new song plays, the auto-preset for that song will always be loaded, if it exists, and the AUTO button would light up. This means there would be no way to disable the feature entirely, only on a per-song basis by deleting individual presets. (Edit: You could, of course, still disable the equalizer entirely.)

The first time a user clicks on the AUTO button, we'd want to pop up a message dialog explaining what it does, with a "Don't show this again" checkbox. The biggest problem with the old implementation of this feature (aside from it not working at all for several releases!) was that no one knew how it worked.

Also, a couple of implementation ideas:

1. Let's keep the config format compatible with Audacious 3.6.x; that is, store all the auto-presets in ~/.config/audacious/eq.auto_preset.
2. I don't think we need a separate "default" preset, as long as we don't overwrite the settings stored in the main config file. It's probably better for the UI code to stop accessing the "equalizer_xxx" config values directly, anyway.

1: Good idea!

2: ditto, except if the prev. song also had a preset file, we need to be sure to revert to the previous "non-auto-preset" values as opposed to the prev. song's values! I was playing w/XMMS the other day (to see how this shtuff worked) and it did not handle this properly either (kept last song's auto preset after switching to a non-auto song - losing your non-auto settings).
Also, by "delete" I hope you mean just reset the equalizer, not delete the song's preset file?

3: I disagree. In XMMS, AUTO just permits song-specific presets to be used (and the equalizer to be changed). I like this (XMMS way) idea better. In my patch, I light up the [Preset] button on the equalizer as the indicator for this purpose when a song-specific preset is loaded. The skins contain 2 states for this button. XMMS doesn't seem to ever light it up, but only uses the 2 states as "pressed-and-held" and "not-pressed", but I simply toggle to the opposite state whilst pressed & held, then back to the proper indicator state when released.

1(paragraph b): Is eq.auto_preset to be a directory or file? Directory: cool, single file: could become large & will make it harder to remove song presets w/o having to create a separate GUI for that purpose? At least, maybe "eq_auto.preset" or "eq.auto_presets", since more than one.

2(b): Sounds great as long as we can keep the last-known non-song-specific settings somewhere.
One other thought a/b files - Some streams (and stdin? - haven't tested) don't seem to always have "names". I think my patch makes sure it falls thru to something like "unnamed", which sortta sux, but not sure best way to handle that.

My 2¢

Jim

Jim Turner wrote:

... Also, by "delete" I hope you mean just reset the equalizer, not delete the song's preset file?

I actually meant, delete the preset for that song. But maybe this is not a good idea.

... In my patch, I light up the [Preset] button on the equalizer as the indicator for this purpose when a song-specific preset is loaded. The skins contain 2 states for this button. ...

It would be a novel use of the Preset button, but I don't think I agree with it. The Preset button isn't meant to be a toggle; toggle buttons have four states in the skins, not two. How about making the AUTO button access a small drop-down menu with three options: Enable auto-presets (checkbox), Save auto-preset, Delete auto-preset? Then make it light up only when auto-presets are enabled AND a preset has been loaded for the current song.

Making changes to the equalizer settings while an auto-preset is loaded should save those changes automatically, I think. Otherwise those changes would just get lost without warning when the next song plays.

... Is eq.auto_preset to be a directory or file? ...

Single file; that's the way it was in 3.6. Yes, it could become large, but the alternative--creating hundreds of tiny (around 150 bytes) files--is rather wasteful of disk space, so that's not ideal either.

That (small dd menu w/3 options on [Auto] button) sounds like a a good plan. Single file should in practice work fine too (I don't use very many auto-presets, though some abUsers might). Idk how it worked in 3.6 since I never used it until recently when I noticed that a cpl. of streams I started using sounded awful w/my normal eq. settings and I figured out that they must be already "equalized" and I switch between 'em regularly. My patch used separate files b/c that was the quickest and easiest way for me to make it work by piggybacking off the existing "Export Preset" and "Load Preset options.

The reason I like my idea of toggling the [Preset] button is that then I can see both whether I have "Auto Preset switching" ([Auto] button) on and, if so, whether or not the current song has (altered the EQ with) it's own auto-preset.

So, let me see if I got this straight: User brings up EQ., IF [Auto] is on and abUser changes a slider, it immediately saves it to/as that song's auto-preset and EQ settings revert when song is finished/changed; ELSE it immediately saves as the current (non-auto) EQ settings as normal. If that's the case, then the menu only needs 2 settings: 1:[Activate Auto Preset] or [Deactivate Auto Preset] (depending on current state); and 2:(iff preset exists for this song) [Delete Auto Preset]. The top choice (to toggle) should be under the mouse when menu pops up allowing a double-click of [Auto] to just toggle.

If user brings up EQ, turns Auto on in song A, then changes EQ settings whilst song A is playing (saves changes as song A's auto-settings), then plays song B (which has already has it's own auto-settings) - EQ settings then change to B's settings, then plays song C (which does NOT have it's own settings), EQ settings should revert back to what they were BEFORE he changed 'em whilst song A was playing (Is your head hurtin' as much as mine yet - LOL?!) That's why my patch creates 2 aud variables: "equalizer_autoload" saves the state of the [Auto] button (on|off) and "equalizer_song_auto" which saves the state of whether the EQ was last set to a song's auto-settings or not, so that when changing songs or Audacious is restarted, we know whether or not we need to revert to last known "non-auto" settings or not (output.cc) and why it creates a "_nonauto.preset" preset.

Regards,

Jim

After finding and fixing a bug in my patch causing the improper switching / restoring presets when first creating a new auto-preset during play, I decided to document it a bit better. Here's what I've found:

I see 4 possible scenarios when opening an entry (either by song-advance or startup): (N=entry has no auto-presets, P=entry has presets, shown as [Prev. Entry]->[Current Entry])
based on prev. entry played: (NOTE: we handle P->N regardless of [Auto] state!)
1) N->N: Do nothing with equalizer.
2) N->P: (IF [Autoload]) Save current EQ settings as "default", then load entry's auto-preset.
3) P->P: (IF [Autoload]) Load entry's auto-preset file.
4) P->N: Load the prev. saved "default" preset file.

If [Autoload] is OFF, then the only 2 possible states are N->N and P->N since no
song-specific preset is checked for, much less loaded.

Hope this is helpful.

Jim

Jim Turner wrote:

After finding and fixing a bug in my patch causing the improper switching / restoring presets when first creating a new auto-preset during play, I decided to document it a bit better. Here's what I've found:

I see 4 possible scenarios when opening an entry (either by song-advance or startup): (N=entry has no auto-presets, P=entry has presets, shown as [Prev. Entry]->[Current Entry])
based on prev. entry played: (NOTE: we handle P->N regardless of [Auto] state!)
1) N->N: Do nothing with equalizer.
2) N->P: (IF [Autoload]) Save current EQ settings as "default", then load entry's auto-preset.
3) P->P: (IF [Autoload]) Load entry's auto-preset file.
4) P->N: Load the prev. saved "default" preset file.

If [Autoload] is OFF, then the only 2 possible states are N->N and P->N since no
song-specific preset is checked for, much less loaded.

Hope this is helpful.

Jim

Hi,

I downloaded Audacious 3.8.2 for Windows, and noticed the AUTO button is not clickable.
I tried the same button on Ubuntu many months ago and it worked to some degree.
I was a Winamp heavy user decades ago and value greatly this Audacious port.

Appreciate some help.

@Waky: That's b/c this is a proposed patch, which has not been implemented in Audacious as of this time. It IS implemented in my forked version. Email me directly (see my profile) or search Github for Audacious fork as this is a separate, competing project that I don't feel right about advertising for or discussing here.

Regards,

Jim

Thanks Jim. I don't have time to work on porting your changes myself, but I would review a pull request if someone has time to make one.