config per directory?

[saratoga]

I don't quite follow you.

Flash targets use the same buffering system as hard disk targets.  Whatever changes you suggest must work flawlessly on both flash and hard disk targets. 

[Llorean]

Basically, "we aren't going to screw over the hard disk users by adding such a feature, just because there are more flash users." It needs to work for both.

[Confuseling]

Flawlessly on all targets? Like Doom? 

Fair enough, if it interfered with current functionality. This is possibly a fairly wide definition of 'screwing over'.

Anyway, I think I've made my point...

[saratoga]

Flawlessly on all targets? Like Doom? 

Disabling doom on targets without color screens or enough RAM is fine.  Disabling playback on non-flash targets is not likely to be accepted. 

[soap]

Anyway, I think I've made my point...

If your point was to equate non-core plugins with music playback...

If Doom WASN'T included on targets which barely run it, people would bitch all the same.
Damned if you do, damned if you don't.

[torne]

On some of the flash targets, accessing the flash brings the flash chip out of an automatic sleep mode which consumes less power, so it *can* shorten battery life: the difference is much smaller than a hard drive, of course, but it may still be measurable.

[JdGordon]

why has noone mentioned that loading a cfg every (few) track change(s) is a very bad idea because just loading the .cfg is expensive?
There is no way to know which settings a cfg change and most cant be applied inidivudally so you not only need to check for the cfg, you also need to parse it (~200 settings in a massive table which needs to be scanned to figure out what a .cfg line means and how to store it), then we need to apply all settings which includes reloading fonts and themes (which can also actually mean stopping playback and restarting(!))

putting it mildly, this is a very stupid idea from an implementation point of view.

Now, a better solution to almost all the reasons for this has been posted already and I'll post another. Someone rework the quickscreen like has been menionted in one of the other threads to give you almost the same amount of control without wasting time with .cfg files.

[pabouk]

I think no one supposed that per-directory cfg will contain all the possible options. As I can summarize from this thread users need to change just few parameters. I do not understand why most of the settings cannot be applied individually. Do you think that this is the case of the parameters mentioned in this thread? Of course reloading fonts and themes would be really bad if we want to change just EQ, crossfeed or automatic bookmarking.

Stopping and restarting playback does not matter. I think no-one will complain if there will be exception to gapless playback.

We probably do not need unlimited number of configurations so they can possibly be stored in a parsed form at a single location or maybe loaded into RAM from single cfg during Rockbox startup.

I can imagine that the implementation could be complicated but finally should the software follow easy implementation or usability?

I do not know about a better solution (in the sense of usability). All other solutions require manual intervention of a user.

[saratoga]

I can imagine that the implementation could be complicated but finally should the software follow easy implementation or usability?

To be perfectly clear, the only way this will be accepted is if you have a good implementation.  Usability is not even a consideration until you have that.  So if you frame this as a choice between one or the other, consider the idea rejected. 

Anyway, since the only people actually discussing how this could be implemented seem to agree its both a bad idea and not worth implementing,  is there any reason to leave this thread open?  IMO we seem to agree that we're not going to have the buffering system handle config files, and the only remaining thing to discuss is improving stuff like the quickscreen or hotkeys.  IMO that should probably go in its own thread.

[Confuseling]

Personally, I see no need to lock the thread - it got somewhat heated at points, but has remained civil. Your prerogative.

Final suggestion then, and I'm not going to argue the point; you could limit it to top level directories (or even just literally audiobooks, music, and podcasts), presumably allowing you to load all configurations at boot with minimal interference with the present system.

This would meet some of the use cases, and provide a stepping stone to work from, while heavily limiting the problems. If the problems became tractable at a later date, you could loosen the limit.

[torne]

You're confusing what seems simpler in concept to you, with what's actually simpler to implement. We have no mechainsm for having multiple configurations in memory. We have no mechanism for loading configurations with only a subset of the settings. Adding these things would be complicated.

The ideas being discussed by most of the developers in this thread reuse the existing config file parsing system and the existing single set of global settings in memory to accomplish the task, this is what makes them simple, even though this means they have *more* functionality than you are asking for. Unfortunately the consensus seems to be that the 'obvious' way of doing it is going to have some problems... so unless a way around them is proposed this isn't going to happen. Suggesting something more limited doesn't automatically make it easier, simpler, or more elegant to actually implement, in fact more general solutions to problems are often more simple...

[oayz]

It's great to have developers to step in and provide insight. Even if "config" idea is rejected the problem is still there - there is a need to automatically adjust some settings on per directory basis.

I don't think quickscreen is a solution - it still requires user intervention, isn’t it?

Regarding crossfeed – I believe it’s a typo. Should be crossFADE

[evilnick]

Regarding crossfeed – I believe it’s a typo. Should be crossFADE

Nope. Crossfeed and crossfade are totally separate things.
Although I did think that at first too!

[oayz]

Yes, but it does make sense to control crossFADE on per directory basis. I don't think anyone wants to do it with crossFEED. Still possible though - "I listen this directory on headphones and that - when my RB is docked".

[Chronon]

For me it depends on how the album is mastered.  I usually enable crossfeed while listening with phones to albums where certain instruments are hard-panned.