And just to clarify, I'm modifying global_settings directly, like this:
global_settings.pitch_timestretch = !global_settings.pitch_timestretch;
Is that an improper way of changing a setting?
-David
On 20.06.2009 05:08, Paul Louden wrote:
Al Le wrote:
IIRC, it has been discussed several times, and the agreement has
always been that these settings should not be persisted and should
rather be reset to 100% at every power on.
Why should we remove the ability for someone to save these sett
Paul Louden wrote:
Jeff Goode wrote:
Agree here. There are a number of times when I want to disable
ReplayGain. In fact, I usually leave it off unless there's a
specific reason I want it on.
Jeff
Again, everyone who's said they want it on hasn't explained how they'd
be able to detect it
pondlife wrote:
Though, as well, a "nudge" UI (possibly even a plugin) could be made for
this specific thing to allow the simplification of the pitch and speed
settings without losing this specific way to accomplish this task.
I guess the current pitch screen could be moved to a plugin j
Jeff Goode wrote:
Agree here. There are a number of times when I want to disable
ReplayGain. In fact, I usually leave it off unless there's a specific
reason I want it on.
Jeff
Again, everyone who's said they want it on hasn't explained how they'd
be able to detect it was on, why it actua
Dominik Riebeling wrote:
If you're really that anal-retentive about it,
Do we really need to use this kind of wording on this list? Guys, please.
It requires less characters than typing "overly obsessive about such
small details as a setting you almost certainly cannot even distinguish
Al Le wrote:
IIRC, it has been discussed several times, and the agreement has
always been that these settings should not be persisted and should
rather be reset to 100% at every power on.
Why should we remove the ability for someone to save these settings? We
already have fixed.cfg if someo
Thomas Martitz wrote:
I agree with all what pondlife said.
Paul, am I right? On the one had you want to "waste" 64K of RAM, and
on the other hand you want to reclaim binsize/ram by making the
pitchscreen a list? Some (work-in-progress) targets are already short
on RAM (the clip has only 300K
gl wrote:
Are you saying you'd even know or care if replaygain was used? How
would you possibly detect it if it was always on?
So if you don't want to use it, don't create files with replaygain in them.
Because I want my files as minimally processed as possible. And I
want to preserve
> then you're doing it wrong how about posting the diff?
My current diff is kind of convoluted because of all the stuff I'm
doing to the pitch screen, but I've discovered another detail of the
problem. When I modify those settings they're changing correctly in
the global_settings struct. The
2009/6/19 David Johnston :
>> to have them saved you need to add them to settings_list.c
>
> Yes, I did that. That's what's confusing me. I added two entries to
> settings_list.c and corresponding ones to settings.h but it's still
> not getting saved.
>
> -David
>
then you're doing it wrong
> to have them saved you need to add them to settings_list.c
Yes, I did that. That's what's confusing me. I added two entries to
settings_list.c and corresponding ones to settings.h but it's still
not getting saved.
-David
Flyspray contains 452 open patches:
0 days old: Arabic Language Translation Improvements
2 comments, 1 files: http://www.rockbox.org/tracker/10351
1 days old: Rockbox Utility Japanese language update.
0 comments, 1 files: http://www.rockbox.org/tracker/10349
1 days old: Japanese language updates
Flyspray contains 261 open bugs:
0 days old: I found in Two Bugs by my iPod 3rd Gen.
0 comments, 0 files: http://www.rockbox.org/tracker/10353
0 days old: plugin lib highscore: fix and improvement
0 comments, 1 files: http://www.rockbox.org/tracker/10350
2 days old: Status Bar is viewable in plu
Agree here. There are a number of times when I want to disable
ReplayGain. In fact, I usually leave it off unless there's a specific
reason I want it on.
Jeff
Dominik Riebeling wrote:
On Fri, Jun 19, 2009 at 3:04 PM, Paul Louden wrote:
In the general trend of "streamlining the menu st
> If you're really that anal-retentive about it,
Do we really need to use this kind of wording on this list? Guys, please.
- Dominik
On 19.06.2009 16:10, alex wallis wrote:
but if I understand your idea right, this would mean a user then has two
things to alter if they want to change both pitch and speedh.
If I use the pitch screen I normally change only one setting at a time:
either the pitch (if I want to adjust the song
On 19.06.2009 16:09, pondlife wrote:
The current UI nudges the pitch up/down only while you hold a the key down,
making it really easy to use. I really can't see that a menu UI would work
so well.
May I suggest a help in judging this? Imagine we have this implemented
through menues and two
On 19.06.2009 15:45, Paul Louden wrote:
pondlife wrote:
Plus, the pitch/speed values are not settings - they are not persisted.
They could (and possibly should) be.
IIRC, it has been discussed several times, and the agreement has always
been that these settings should not be persisted and
pondlife schrieb:
In the general trend of "streamlining the menu structure" I'd like to
bring up the idea of removing the Replaygain toggle.
I know there was at least one objector in the past. Can anyone see some
obvious actual problems with it?
Use of Replaygain has an impact o
2009/6/19 David Johnston :
> So I'm doing some work on the pitch screen UI, mostly with regards to
> cleaner, more intuitive integration of the timestretching
> functionality, and I have a couple questions:
>
> 1. I'd like to set it up so that Rockbox remembers whether
> timestretching is on (not j
So I'm doing some work on the pitch screen UI, mostly with regards to
cleaner, more intuitive integration of the timestretching
functionality, and I have a couple questions:
1. I'd like to set it up so that Rockbox remembers whether
timestretching is on (not just available) and whether pitch is be
> In summmary, you've identified three improvements...
>
> 1) Enable timestretch by default
> 2) Display speed based on user's perception, not on algorithm parameter.
> 3) Swap pitchscreen axes on wheel targets
The changes I'm currently working on (which are just about complete)
take care of #2.
Disagree, I never play with replaygain - if I get some files tagged
with it, I don't care what the originator wanted, I don't want it
automatically enabled.
Are you saying you'd even know or care if replaygain was used? How would
you possibly detect it if it was always on?
Because I want m
On Fri, Jun 19, 2009 at 3:04 PM, Paul Louden wrote:
>
> In the general trend of "streamlining the menu structure" I'd like to bring
> up the idea of removing the Replaygain toggle.
Why remove it? I've had (a few) occasions I liked it being able to
disable Replaygain. I'd rather merge the two "En
On Fri, 19 Jun 2009, Ray Lambert wrote:
FYI: The source archive appears to be missing from the server. I'm getting
a 404 error on: http://download.rockbox.org/release/3.3/rockbox-3.3.7z
That's fixed now, just give it some time to get synced out to the download
mirrors and try again!
Thank
> Okay, that's more or less what I thought. Couldn't this be accomplished
> with either pause/unpause, or my previously described method using the
> menu?
I think the timing would be much trickier, plus at least double the button
presses required. In particular pausing would interrupt the flow
pondlife wrote:
This is where we fundamentally disagree. There is very little redundancy -
only that both the procentual and semitone mode share the nudge option (and
I think that's reasonable in this context).
First, the percent and semitone options are basically redundant anyway -
if
pondlife wrote:
I'm not entirely sure what you mean by this. Could you explain a little
more?
Sure - the only reason that Timestretch can be enabled/disabled is to save
on RAM. This is basically the same reason we allow configurable limits for
"Max entries in file browser", "Max playlis
> most of the screen is ... redundant.
This is where we fundamentally disagree. There is very little redundancy -
only that both the procentual and semitone mode share the nudge option (and
I think that's reasonable in this context).
The more I think about it, the more I think we have the whee
rockbox-dev-requ...@cool.haxx.se wrote:
Hello friends!
I'm happy to announce that Rockbox 3.3 was just released!
FYI: The source archive appears to be missing from the server. I'm
getting a 404 error on:
http://download.rockbox.org/release/3.3/rockbox-3.3.7z
~ray
> I'm not entirely sure what you mean by this. Could you explain a little
> more?
Sure - the only reason that Timestretch can be enabled/disabled is to save
on RAM. This is basically the same reason we allow configurable limits for
"Max entries in file browser", "Max playlist size", plus give
alex wallis wrote:
How often do you want to increase the pitch exactly the same amount
as the speed increase, so that the pitch is 30% higher AND the
runtime of the file is 30% shorter? It's only for these very specific
cases that there would be more for the user to do.
Well actually, I us
alex wallis wrote:
but if I understand your idea right, this would mean a user then has two
things to alter if they want to change both pitch and speedh. I like
having the flexibility of the three settings of just pitch, pitch and
speed together and just speed. Removing one would create m
alex wallis wrote:
So why not have some kind of menu when you first enter the pitch
screen with the three modes to select from.
The idea is to reduce complexity, not add more. While "nudge" may be an
issue for debate, most of the screen is overcomplex and redundant.
Adding to it doesn't solve
cleaning.
pondlife wrote:
Sorry - I misread that.
(I do think that the basic menu layout is a bigger usability issue than
the points you've raised though - "General settings" indeed ;-) )
While the general layout is a problem, aside from replaygain the two
screens I've mentioned are
pondlife wrote:
Sorry - I misread that.
(I do think that the basic menu layout is a bigger usability issue than the
points you've raised though - "General settings" indeed ;-) )
While the general layout is a problem, aside from replaygain the two
screens I've mentioned are very hard t
alex wallis wrote:
but if I understand your idea right, this would mean a user then has
two things to alter if they want to change both pitch and speedh. I
like having the flexibility of the three settings of just pitch, pitch
and speed together and just speed. Removing one would create more
pondlife wrote:
Maybe we should put all of the "RAM saving" options together under System >
Limits and enable Timestretch by default?
I'm not entirely sure what you mean by this. Could you explain a little
more?
The current UI nudges the pitch up/down only while you hold a the key dow
> Didn't I specifically say that I didn't want to discuss the menu layout,
> but rather things that could be removed or screens that could be fixed
> that are more or less independent of layout?
Sorry - I misread that.
(I do think that the basic menu layout is a bigger usability issue than the
I'm very much in favour of replaygain being on by default especially
since it really has no significant side effects for users that don't
have the tags. I don't like the timestretch being on by default mainly
because it will just wase ram for most users.
On 6/19/09, Paul Louden wrote:
> gl wrote:
cleaning.
pondlife wrote:
Use of Replaygain has an impact on battery life IIRC. Might be better to
merge the "Enable replaygain" option into the "Replaygain type" menu as
an "Off" option. (This would default to Track gan if shuffling", giving
one less menu ioption and the desired default
Rafaël Carré wrote:
That is significant actually, some targets are quite short on RAM
(Sansa AMS with 2MB of RAM for example)
If the setting can't be enabled permanently, it also can't be enabled
temporarily on these players and thus needs to be removed anyway. If it
can be enabled tempora
> My understanding was that it cost 64k of RAM. That's not terribly
> significant. It's not small, but for avoiding user confusion (forcing them
> to look in two places, and reboot, to use a single setting, which
> basically means the manual is required for them to figure this one out)
> it's p
Andrew Hart wrote:
If folks really want to stream-line, why not remove the "Enable replay
gain" option from the "replay gain" menu and add a "no replay gain",
"off" or "ignore replay gain tags" option to the "replay gain type" setting?
Personally, I'm happy with how it currently stands. The cu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 19 Jun 2009 08:45:35 -0500
Paul Louden wrote:
> My understanding was that it cost 64k of RAM. That's not terribly
> significant.
That is significant actually, some targets are quite short on RAM
(Sansa AMS with 2MB of RAM for example)
- -
If folks really want to stream-line, why not remove the "Enable replay
gain" option from the "replay gain" menu and add a "no replay gain",
"off" or "ignore replay gain tags" option to the "replay gain type" setting?
Personally, I'm happy with how it currently stands. The current
arrangement als
snip
To me the most "obvious" improvement would be to drop the toggle for time
stretch (despite RAM cost, this is the sort of feature that should be
always on
I disagree - with the current algoithm the RAM cost is significant, and
the impact timestretch has on sound quality (e.g. mono output a
gl wrote:
It seems to me that it's reasonable to assume that if a user puts
replaygain tags on their files, they mean to use them. If a performer
distributes their files with replaygain tags, they're also meant to
be used.
Disagree, I never play with replaygain - if I get some files tagged
Xinlu H wrote:
I second that.
I pose for you the same question - how would you know, and why exactly
would you care?
pondlife wrote:
Hi Paul,
Also, if we're to address the menu layout (and we should), I'd suggest that
http://www.rockbox.org/twiki/bin/view/Main/MenuLayoutDiscussion offers the
best proposal. I know it needs a bit of bringing up to date, but Marc's
basic idea is good, IMHO.
Didn't I spec
On Fri, Jun 19, 2009 at 9:44 AM, gl wrote:
>
> Disagree, I never play with replaygain - if I get some files tagged with
> it, I don't care what the originator wanted, I don't want it automatically
> enabled.
>
>
I second that.
Xinlu
Hi Paul,
Also, if we're to address the menu layout (and we should), I'd suggest that
http://www.rockbox.org/twiki/bin/view/Main/MenuLayoutDiscussion offers the
best proposal. I know it needs a bit of bringing up to date, but Marc's
basic idea is good, IMHO.
pondlife
pondlife wrote:
Use of Replaygain has an impact on battery life IIRC. Might be better to
merge the "Enable replaygain" option into the "Replaygain type" menu as an
"Off" option. (This would default to Track gan if shuffling", giving one
less menu ioption and the desired default behaviour.)
It seems to me that it's reasonable to assume that if a user puts
replaygain tags on their files, they mean to use them. If a performer
distributes their files with replaygain tags, they're also meant to be
used.
Disagree, I never play with replaygain - if I get some files tagged with it,
I
> In the general trend of "streamlining the menu structure" I'd like to
> bring up the idea of removing the Replaygain toggle.
> I know there was at least one objector in the past. Can anyone see some
> obvious actual problems with it?
Use of Replaygain has an impact on battery life IIRC. Migh
In the general trend of "streamlining the menu structure" I'd like to
bring up the idea of removing the Replaygain toggle.
I know there was at least one objector in the past. Can anyone see some
obvious actual problems with it?
It seems to me that it's reasonable to assume that if a user puts
Hi all,
Still no progress this week too. However, since my last exam is on Tuesday,
I should be able to resume working on the project.
I have a question though, in the case of a sim build, is there something
similar to time.h's clock() function (The standard time.h not rockbox's), to
time certain
>
> Can you move this code from librm to the test program, if it's unused
> by the rockbox codec?
>
It seems like this would be the only solution. The test program will have
its own copies of rm.[c/h] back.
--
MT
59 matches
Mail list logo
