config per directory?

[Llorean]

What happens if you put a new audiobook on, but forget to include a local .cfg to turn shuffle off? Or want to hear an album in order for once, but it has a local .cfg that turns shuffle on?

Really, the best way to handle it is to be responsible yourself, and maybe use the quickscreen to quickly toggle shuffle on/off as needed.

[oayz]

If current directory doesn't have local cfg than default should be used (see my pseudo code).

I completly agree with you - this a feature most people including me can live without. Yet it does provide tremendous flexability. BTW, as I just learned from you from another thread CFG files currently can only be stored in the root ...

[Llorean]

.rockbox is not "the root", and .cfg files can be stored anywhere, it's just that one option that only shows them within a certain folder.

It sounds like your folder-specific config files needs to have two values for every option then, one for "this folder's choice" and one for "the overall choice." Basically, it needs to treat them not like normal cfg files - it can't actually change the value of the option, just cause a temporary override when that folder's played that will be reverted at the stop of playback or when anything in any other folder is played.

[oayz]

Well no, that wasn't my intent. I suggested to keep a pointer to global CFG - either default or the one user manually loaded. This CFG will be reloaded every time we exit a directory with local CFG thus restoring "original" settings.

Of cause logic may be different but the intent is simple:
- keep CFG load/parse/apply as it is now
- in directories with no local CFG keep current RB behavior

It's not fully thought thru proposal - some may suggest different (more complex) bahavior in directory tree. For example if directory BOOKS have local CFG it may propogate to sub-directories.

Thanks for correcting "root" and yes I now remember that we can browse files and click on CFG anywhere.

[Confuseling]

@ soap and oayz

Just to clarify, I'm not arguing that in the long run, if the feature were fully developed, it would be of most use to audiobook / podcast users. I'm just saying that an initial form of it, hard disk spinning up warts and all, would be of clear use in this case. Given that it would be transparent, and have to be consciously turned on, I see no harm in making a useful but limited feature, and incrementally perfecting it to the point where it would be usable on an album by album basis.

The best is the enemy of the good, and all that.

@ Llorean

The case where you've got a config file in a directory and want to override it is an interesting one. You could maybe have three potential levels of settings; global settings, loaded as per now from a cfg file, local settings loaded because they're specified in a particular directory, and current settings if you adjust anything on top of that - discarded once you've left the directory again. Perhaps, ultimately, it would make sense to give the local / current ones an icon, or colour code them, in the settings menu.

It might also be nice to have a way to update local cfg files with new values. So if I went into a directory, then adjusted any parameters that were already specified in that directory's config, I could browse to the settings file and write them back with an 'update from current settings' or something from the context menu.

[Yotto]

I think a more common usage case would be album-specific audio settings (EQ, etc.)   

Shuffle was the one to make me open this thread. It's distructive - on few occasions I have it ON for playing music and forget to turn off switching back to audiobooks. 10 chapters later I relalized it's not a crazy athor, it's my stupidity :-)

Please remember that it's not simple music/books case. Even for music you may want to have shuffle of for album and on for compilations.

Maybe you can do what you are looking for with bookmarks?

I have two bookmarks (actually I have many, but two that matter for this discussion). The first is for all of my music. It's a shuffled playlist (m3u file that's in alphabetical order, but Rockbox has shuffle turned on). The second is of all my podcasts. It's a directory, with no m3u file, and Rockbox handles it as a dynamic playlist. It is NOT shuffled.

I never ever have to modify the "shuffle" setting. Playing the music bookmark loads it shuffled and I'm happy. Playing the podcast bookmark loads it not shuffled and I'm happy.

[oayz]

Yes, sounds like another way to handle shuffle. I could also have shuffled and non-shuffled m3u's.

The point is local CFG provides complete solution. Shuffle, EQ, timeouts ... everything. Shuffle is the biggest issue, EQ is the next one. Someone may have directory for parties - with crossfade etc.

To Confuseling:

I think we already have the infrastructure: we can save theme settings or audio settings or both. Maybe control settings should also be separate. If we could only browse cfg files and overwrite existing ones w/o having to type filenames ... (this was already mentioned in another thread)

[Chronon]

I would probably use it mostly to set crossfeed on/off by directory (album).

[pabouk]

I personally would like to have just about 3 - 5 different configurations for distinct directories (inherited in all their subdirectories). So for me there is no need to store the local configs to the involved directories. If it makes implementation easier / more efficient the local configs could be at a central location (for example in .rockbox/config directory or in a single .cfg file).

Which setting I would like to vary between directories:
- auto bookmarking
- default speed of playback (not possible in the configuration file at the moment)
- crossfeed
- maybe EQ
- maybe shuffle
- maybe skip length

In addition (sorry for little off-topic in this thread) it would be great if Rockbox traces completely listened files (listened from beginning to end) or files manually marked as listened so they could be later automatically moved / deleted (either files or references in a playlist) by a plug-in. I think many podcast listeners would welcome this functionality.

[soap]

I've seen crossfeed mentioned several times in this thread in connection with audiobooks / podcasts.

What is the audio disadvantage of having crossfeed on with these types of audio?

[Didgeridoohan]

Thanks for the tip! If this thread will die I'd definetly use it. The problem is that most of the time I decide to shuffle when I already playing (got bored with same order). Also "insert shuffle" will not work for auto-change directory, will it?

Local config covers it all ...

For the times you want to shuffle after creating a playlist, use "Reshuffle" in Context Menu -> Playlist

[Chronon]

I've seen crossfeed mentioned several times in this thread in connection with audiobooks / podcasts.

What is the audio disadvantage of having crossfeed on with these types of audio?

To clarify, I tend to listen to albums in random order (random folder advance).  Some (especially) older albums tend to be mixed with certain instruments panned hard left or right.  Crossfeed improves the experience of listening to such albums considerably.  On the other hand, I prefer not to apply crossfeed to some types of electronic music, for instance.  Some method of automating setting changes should enable crossfeed to be applied only to the albums I want.

[Confuseling]

One other thing that hasn't been explicitly mentioned is that the number of hard-disk based players is declining relative to flash based ones. Presumably, on a flash target, the buffer problem is irrelevant?

Maybe it would be interesting to run a poll, to find out the distribution among RB users. I'm assuming that there are more using hard-disks, because most targets are a few years old - but I wonder by how much?

[saratoga]

One other thing that hasn't been explicitly mentioned is that the number of hard-disk based players is declining relative to flash based ones. Presumably, on a flash target, the buffer problem is irrelevant?

No, they all use the same buffering system.  Theres just one rockbox for all devices.

[Confuseling]

I don't quite follow you. Isn't "spinning up" flash essentially costless? Doesn't that mean that for an increasing proportion of targets, the buffer problem is irrelevant - that you can load a config file between each track, and not suffer from a noticeable battery impact?

I'm not saying that that discounts it, just that it bears consideration (unless I've misunderstood...)