config per directory?

[oayz]

On many occasions I wish if RB can automatically switch some configuration parameters based on the current directory. For example:
- some music directories are better to be shuffled
- full albums are not
- audio books should never be shuffled
- for audio books different EQ may be preferred
- resume, rewind on resume etc - good for audio books, bad for music
etc.

To take care of all these and possibly other differences let's allow "local" configuration files. Basically if current directory has CFG file it will be parsed and applied.

Though idea and implementation seems trivial there is a question how to treat nested directories (should we revert hierarchically revert back or go back to root default.cfg).

[funman]

It sounds like a job for playlist files (m3u)

[[Saint]]

On many occasions I wish if RB can automatically switch some configuration parameters based on the current directory. For example:
- some music directories are better to be shuffled
- full albums are not
- audio books should never be shuffled
- for audio books different EQ may be preferred
- resume, rewind on resume etc - good for audio books, bad for music
etc.

To take care of all these and possibly other differences let's allow "local" configuration files. Basically if current directory has CFG file it will be parsed and applied.

Though idea and implementation seems trivial there is a question how to treat nested directories (should we revert hierarchically revert back or go back to root default.cfg).

Well, .m3u playlists can certainly help in some respects here...but it isn't the "solution".
In saying that, neither is my suggestion likely to be viewed as the "solution" for the original poster, but, I personally see it as being a lot more versatile...read on:

While you cannot configure Rockbox to load a specific .cfg file on entering a directory, you can most certainly create individual .cfg files and keep them in the folders where you intend to use them, simply remebering to "run" the .cfg before you listen to the content inside the directory.

With this you can set every variable you mentioned in your request...every variable/setting that Rockbox offers, in fact.

You can also configure a "fixed.cfg" to return your DAP to a default state (or, a state of your choosing) each time that Rockbox is booted to avoid having to remember to reset the config files each time.

This is what I do for these cases, and it works very well for me.



[St.]

[Confuseling]

I suppose a transparent way to do this automatically would be to have a config in a directory with a specific name (perhaps the name of the directory + .cfg) loaded automatically when you start playback from that directory. You could even have directives in the config, stating whether it applies recursively to subdirectories or not (making it default to something, so it's transparent again for users who don't want to care about this stuff). [ETA - or even just use 'automatic.cfg' and 'automatic.recursive.cfg' for names...] [ETA2 - now someone's going to chirp up and tell me there's an obscure prog-rock album from 1983 called 'automatic recursive'  ]

I guess then it's only a question of usefulness versus binary size.

Edit - It does open up a slightly grey question though - do you ever want your MP3 player to do something like automatically ramp up the volume massively? It would only take one mistyped number in one config file to deafen yourself. You can make the case that that's no different from the present situation, but it always adds a different dimension when things happen without user intervention. Maybe you'd need a 'maximum volume to allow from config files' setting as well, complicating things somewhat...

[oayz]

No this stuff should not go to playlist. Playlist is a playlist - I'm surprized we start to add things like pitch to it. It may be huge (1000's songs) so adding complexity to it doesn't make sense.

Having special predifined naming convention for local configs makes perfect sense (similar to naming conventions for album arts). This way we may keep configs in local directories or in centralized location.

I agree that saving volume is dangerous. OK, maybe we should not load volume at all. Maybe we should have incremental option (60 is absolute volume while +/-6 is relative to current setting). I don't think it's a showstopper - same danger happens when we change config manually.

The nice thing about original suggestion is it's simplicity and flexability. Just use original config parser and all options become available.

"St's" suggestion to use manual config read is fine but going trough several layers of menu to select appropriate config file evry time playlist takes you to new directory is a mess.

[saratoga]

I'm not a fan of having per folder config files.  Its a nice enough idea in principle, but it would complicate buffering/playback and only be useful for a small number of cases.

[oayz]

Why would it affect buffering/playback? It's similar to reading album art, isn't it?

Yes, it may have a little use for some of us but will enhance flexibility by a lot. Even 2 most useful options - equlizer and shuffle should make this feature worthwhile. People who listen to books and music whould definetly appreciate having 2 set of settings (which they probably already have) and not having manually switch them.

Unless this feature interferes with main functionality why not have it? It's transparent, seems to easy to implement, consistent with current behavior and doesn't require much code.

[saratoga]

Why would it affect buffering/playback? It's similar to reading album art, isn't it?

Reading album art required quite a lot of changes to buffering and playback that are still being worked on.

Unless this feature interferes with main functionality why not have it? It's transparent, seems to easy to implement, consistent with current behavior and doesn't require much code.

Well if its transparent, easy to implement and won't require changing much, I might be persuaded with an elegant enough implementation.  Feel free to post your code for review.

[oayz]

You've got me on this. I'll rest my case - enough is said already.

Here is pseudo code (sorry this is the best I can do):

  On boot:
      current_cfg = /.rockbox/default.cfg

  On user config load:
      current_cfg = user.cfg

  On each directory change:
    if "local.cfg" file is present
        local_cfg = "local.cfg" // apply local settings
        read/parse/apply "local_cfg"
    elseif local_cfg != current_cfg
        local_cfg = current_cfg // apply global settings
        read/parse/apply "local_cfg"
    end
   
Note: read/parse/apply operates the same way as user loading new config via configuration menu.

[torne]

The point is that we don't read one track at a time, we read as many as will fit into memory, so you can't just look for the config file and load it immediately; you would need to look for the config files that correspond to *future* tracks on the playlist and load their contents without applying the settings, and leave them somewhere so you can apply them at the appropriate time later. This is what we mean by changes to buffering and playback.

[Confuseling]

Unless, in fairness, you just allowed loading configs to end the buffer.

I doubt there are many people who have playlists with music and audiobooks / podcasts in, which is the main use case.

[although my head nearly asploded trying to rewrite some keybindings, so the 'feel free to write a patch' point is well taken...  ]

[soap]

I doubt there are many people who have playlists with music and audiobooks / podcasts in, which is the main use case.

*cough*

I routinely do, as I tend to plan my "DAP day" in the morning and create one 10-12 hour long playlist and then (try to) never touch my iPod again until I get home.

[Confuseling]

Fair dues...

1) I suspect you're not 'many people' (in the nicest possible way 

2) I suspect it wouldn't detract from your listening pleasure if there were a little bump between the two...

[soap]

I'm finding your overall point confusing, Confuseling.  As well as specifically what you're attempting to suggest with line-item 2 in the post immediately above.

Do you mind rephrasing the thrust of your "argument" and attempting to lay it out again?

[Confuseling]

I simply mean that a small 'bump' in between different config files, where things like crossfading and gapless playback fail, would probably for most users (who would use the feature anyway) be a worthwhile price. And I'm guessing (with no relevant knowledge at all, admittedly) that that's what stopping and restarting the buffer would entail.

And if the whole thing's transparent and optional, it's no price at all for everyone else.

Not trying to be argumentative - or confusing - I just think that on balance, it's a good suggestion. Caveats about featuritis, bloat, maintainability, writing the darn thing in the first place all included.