Re: Rockbox trademark?
> I couldn't see a reference to Rockbox there
Re: Rockbox joining the Software Freedom Conservancy?
Solomon, you are the main person in the project now -- not only developer-wise, but you also host the infrastructure. You apparently have muc hexperience in the open source field. So if it would only depend on me then I'd say: Do like you think is best. Your explanations have a solid ground. Thank you for your involvement!
Re: Rockbox joining the Software Freedom Conservancy?
> Out of interest, what don't you like about them? For me, they are sort of like of snitch. Observing of licence infringement is needed if a company's business is creating an open source software and selling licenses for it. I think, such companies do that themselves. Rockbox is not of this sort. The best appreciation sign for a piece of software (or anything) is if's being stealt. (V. Nabokov, changed by me)
Re: Rockbox joining the Software Freedom Conservancy?
Personally, I don't like such kind of organizations. This is a general attitude of mine. I've heard of SFC from Solompon's mail for the first time. But I've not being an active project member for a long time now, so my opinion should not count.
Re: Archos is dead; Long live Archos
Am 24.07.2020 um 01:04 schrieb Solomon Peachy via rockbox: I'm about to pull the trigger on a large patch series that (finally) removes all support for the original devices Rockbox was created to support; namely the old Archos models: Oh, they have always been the base of the rockbox towers!
Re: Extending the metronome plugin
I intend to make it play arbitrary rhythms (with emphasis) like klick with tempo maps. Will it still be a metronome then? Or rather a beat machine? I.e. another plugin.
Re: talk rewrite (off topic)
First: please do not top post. I find full quoting, while formally correct, even worse than top posting.
Re: Ladies and gentlemen, we have sound on the Creative Zen X-Fi3!
On 30.04.2012 19:41, Amaury Pouly wrote: I'm pleased to announced that my Creative Zen X-Fi3 successfully played its first song: Vincent Cheng - Seasons (Creative Demo) It's getting boring. Every couple of days new gentlemen mail! :-)))
rbutil/rbutilqt/base/encoderbase.h, r31595
Just nitpicking, but shouldn't the comment read Child class should commit __the__ SettingsList to permanent storage? I.e. with r31595, not the but rather from should have been removed.
Re: Moving sleep timer menu items/ restart timer on keypress
So depending on whether the consensus is (1) a new sleep timer option (my preference), (2) permanently restarting on keypress or (2) no patch applied at all, what do people think about the following? 1; Settings ... Playback Settings General Settings System ... Idle Poweroff Sleep Timer Sleep Timer Start Sleep Timer On Boot Restart Sleep Timer On Keypress Limits ... Theme Settings ... 2; Settings ... Playback Settings General Settings System Idle Poweroff Sleep Timer Start Sleep Timer On Boot Limits ... Theme Settings ... IMO the sleep timer has something to do with starting / shutdown (more so than with timedate), and hence belongs to the same menu as e.g. start screen and idle power off, i.e. to GeneralSettings - System. In other words, I agree with your proposals, just can't decide with which one more :-) -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: Moving sleep timer menu items/ restart timer on keypress
On 21.12.2011 16:17, Al Le wrote: I would interpret the spirit (if not the letter) of Al Le's comment to be a vote for Startup/Shutdown rather than System.. :-) Correct :-) I was just not brave enough to propose a new submenu. Actually, I don't care where exactly it is as long as it is in the same menu as Start Screen and Idle Poweroff.
Re: A typo in apps/metadata/id3tags.c, r31321 ?
I'm glad you brought this up, I double checked the code and discovered I'd made some false assumptions. Glad to hear that! What about the embed_cuesheet vs. embedded_cuesheet? -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
A typo in apps/metadata/id3tags.c, r31321 ?
Is it a typo or an intended code (it occurs twice)? cuesheet_offset += cuesheet_offset+1; Shouldn't it be cuesheet_offset += 1;? Or is the code correct because it is in the branch for UTF16, i.e. two bytes per character? I'm just asking for the case.
Re: apps/metadata.h, r31321
struct embed_cuesheet {
. . .
struct embed_cuesheet embed_cuesheet;
I'd find the name embedded_cuesheet more appropriate. embed_cuesheet sounds
like an imperative to me.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
r31031 (FS #12293): field name
Hello. r31031 introduced a new field in the settings structure -- glyphs. I think that 1. the name is too unspecific. I'd choose e.g. glyphs_to_cache instead 2. it would be nice if the field were commented, since now its purpose is unclear (without looking deep in the code) Any other opinions? -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: Working towards skin engine 2.0 (includes RFC on code!)
I don't quite like the name skinoffset for the type name. It looks too much like a variable name to me. I'd prefer skinoffset_t (for example).
Re: FS#12321 - Touchscreen: List line padding, to more easily select lines
since the theme author will already appreciate what spacing works/doesn't work, for that specific device, for that specific theme. But then the theme author would include the padding setting into the theme's CFG file, right? Including this new feature (if it gets committed) we would have three ways to change line spacing: 1. Skinned lists (very flexible, but much work and learning) 2. The new setting (less flexible, but quickly does what's needed) 3. Generating a font with the desired ascents/descents (much work, not flexible)
Re: jdgordon: r30599 - in trunk/apps: . gui/skin_engine
I think that this commit should be reverted. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: Discussion regarding reordering the main/root menu
I'm a bit scared to look at the other one though. I read automatic reordering and get shivers I can understand you! :-) But I just thought that if the main menu is reorderable, it would not last long until the request for a general reorderable menu comes. And implemented a general schema. Auto-reordering is an option but of course does not have to be used.
Re: Discussion regarding reordering the main/root menu
That said, a patch to even just allow simple reordering of the main menu isnt going to be trivial so we should figure out a better layout I once tried to do exactly that (in FS#6718 (only the main menu) and FS#7809 (general menu reordering with the option of hiding)), but both patches were rejected. I don't remebmer why exactly -- because it is (or was) a forbidden feature or because of the way it was implemented.
About to close FS#9455 - Add half the viewport width in spaces for forward scrolling
Hello. I would like to close FS#9455 - Add half the viewport width in spaces for forward scrolling. An alternative solution has been implemented in FS#11892 and committed with r29104 (long ago). Any objections to closing the FS#9455? If not, I'll close it in a couple of days. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: Thoughts on FS#12124 - drawing the lists with the skin engine
example from the tracker: . . . %?Lcac%LT # Stuff to actually draw, in this case it is the This gets more and more like Perl!
Re: GSoC/Buflib: Weekly report #2
On 07.06.2011 18:31, Thomas Martitz wrote: But I also sent this mail to make it clear that the names are not fixed by now. I think the core_ prefix is less than ideal but I couldn't up with something better yet (mm_ perhaps?). I assume buf_ (or something with buf inside) can't be used? Since then you'd surely consider it. Is there some convention regarding the return values of the alloc functions? I.e. what value is returned if the allocation failed? A negative value? There is a typo in the first comment: it should read these, not this. Also, many comments start with an imperative (Allocate) and end in the 3rd person (Returns ). Just my questions / notions from a short look.
Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
So do I understand correctly that no consensus has been reached and that the patch will eternally rot on the tracker? In such situation I'd say that if the feature should be committed then it should be committed the way the original patch author has implemeted it. Because he is the main person interested in the feature. The main opponent is Paul who happily lived without the feature all the time. That said, I have not the feeling that many developers/users are interested in it so it's questionable whether it should get in at all. A little provocation is intended... ;-)
Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
On 15.12.2010 17:32, Paul Louden wrote: The starting folder sets where the browser *always* goes. This is not uncoditionally true. If you enable the follow playlist option the file browser will start in other directory than specified by starting folder. I mean, if a user uses the option he will probably know what he's doing.
Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
On 15.12.2010 19:15, Paul Louden wrote: I thought follow playlist sets where you end up when you press select in the WPS. Does it also change where you end up if you choose Files from the main menu? No, of course not. But if you go to the browser from the WPS it's also a kind of start browser. And it behaves differently depending on where (what context) you start it from.
r28663: spelling error
In r28663, it should read Мощность сигнала:, not Мощьность сигнала: (in the commit, there is one erroneous letter in the middle of the first word). -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Typo in r28625
firmware/export/system.h:324: /* CACHEALIGN_BITS = 2 ^ CACHEALIGN_BITS */ I assume it should be /* CACHEALIGN_SIZE = 2 ^ CACHEALIGN_BITS */ -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
r28617: Does resetted exist?
Hello. In the changes committed to the manual with r28617 I see since you manually resetted this item. Does the word resetted exist in written English? Shouldn't it be just reset? -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
re r28480
Hello. I have a couple of questions / suggestions about the patch. 1. Shouldn't the vars 'first' and 'last' be declared static? And renamed to something more specific, e.g. 'alloced_list_head' and '..._tail'? 2. Shouldn't the result of the call to malloc be casted to the desired pointer type? 3. I think, the list tail is not properly updated in the malloc function for the 'USE_HOST_MALLOC' branch 4. The result of one malloc call is not checked to be not NULL (the object itself). 5. The function skin_free_malloced could be made static. Are these points valid? -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
35-Nimbus font is not in the fonts pack
Hello. This is mainly for those who maintain the download part of the rockbox site. The rockbox font pack (available at http://download.rockbox.org/daily/fonts/rockbox-fonts.zip) still does not contain the recently added font 35-Nimbus. Just as a reminder. I'd better say this in IRC but have no access to it right now. -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Change file name extension for the shopper plugin
Hello. I suggest that we change the file name extension for the shopper plugin from list to shop or shopper, because list is too general and does not clearly convey what's inside. Any opinions? -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
r27773
Congratulations and kudos to Magnus Holmgren for r27773. Such bugs are very hard to find!
Re: [Theme Editor] Weekly Status Report #9
I'm going to be working immediately on allowing the user to modify, save, export and import the DB IMO the DB doesn't need to be editable from within the theme editor itself. It can be just a config file which is delivered with the theme editor. How often would the DB change? I think very rarely.
Destructors in Theme Editor: virtual or non virtual?
Hello. Out of curiosity I looked at the code of the Theme Editor which is written in C++. And saw, e.g. in the class SkinViewer, that the destructor is declared as a non-virtual function. But shouldn't (almost always) destructors be declared as virtual functions so that the framework (Qt in this case) can correctly destroy custom objects? Just digging out some long forgotten C++ rests out of my memory... -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
Re: Destructors in Theme Editor: virtual or non virtual?
You are perfectly right. When deriving from a class, the destructor should always be virtual in order to call the destructor of the base class. Hrm... I'd understand it the other way around: it should be virtual so that the correct (of the derived class) destructor is called when the object is destroyed by the framework (probably a call via a pointer to a base class). But the net effect is the same ! :-) -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
Re: Destructors in Theme Editor: virtual or non virtual?
Out of curiosity I looked at the code of the Theme Editor which is written in C++. And saw, e.g. in the class SkinViewer, that the destructor is declared as a non-virtual function. But shouldn't (almost always) destructors be declared as virtual functions so that the framework (Qt in this case) can correctly destroy custom objects? The above statement is correct. But it seems also correct that if the destructor is declared as virtual in the base class then it's automatically virtual in all (directly or indirectly) derived classes. So the code in the Theme Editor is OK. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
Re: Destructors in Theme Editor: virtual or non virtual?
On 17.06.2010 20:11, Robert Bieber wrote: [...] but if you inherit from a class that has a non-virtual destructor, and then you delete a pointer to the base class which is also an instance of the child class, the child class' constructor won't be called. Now that someone else has mentioned it, I do think that having the original base class constructor virtual makes all the following destructors virtual, but it's still safest to just explicitly declare them all that way. I think you confuse constructors and destructors here. Constructors are never virtual (and cannot be).
Re: FM presets
please follow our mailing list etiquette and don't top-post to this list. While this is correct, I'd like to note that full quoting is not better, but is used quite often on this list. Isn't it in the etiquette as well? If yes, why is only top posting frowned upon? -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: FS#11273 - Format FM frequency depending on the regional settings
all the radios I own use two decimal places, and having only one just looks a bit weird. This may be true for the radios as in radio devices (because they have an LCD with two digits?), but all the commercials I see here and also radio web pages use rather one digit. E.g. http://www.londonradiostations.co.uk/#FM_radio I wouldn't want to indroduce a parameter (number of digits after the decimal point) to the fms tag since it would make it unnecessarily complicated. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: alle: r26008 - trunk/fonts
On 14.05.2010 12:10, Alex Parker wrote: I'm not sure I think this is a good idea - the font will still appear in browse fonts, yet won't even be able to render the menus in latin characters. This sounds like a recipe for confusion. Given the way font loading works, having no letters won't save any RAM anyway. I agree, it may lead to confusion. I didn't include any letters in the font not to save RAM but because I think nobody would use such a big font as the UI font. Because of this, I also set ascent and descent to zero -- so that the digits can be positioned very exactly. Out of this reason it would be hard to add normal letters to the font since they usually have some ascents/descents. I agree that large numerical fonts make sense for some stuff - I have made 40 and 50 point ones myself for big screen FM targets Where do you keep them? Thoughts? Maybe have a folder with special purpose fonts? Or add glyphs from some other font to this one, e.g. 19-Nimbus? But I (or anybody else) can revert the commit if you think the font makes more harm than good as it's now.
Re: alle: r26008 - trunk/fonts
On 14.05.2010 12:31, Frank Gevaerts wrote: I think nobody would use such a big font as the UI font. In my experience, 22 is too *small* on e.g. mr500 :) 22 is the real pixel height of the glyphs. Normally, the font size includes ascents and descents, so that a gplyph of a 22-font would normally be about 14 pixels high. This font is special in that it has no ascen/descent. All is net height!
Re: alle: r26008 - trunk/fonts
On 14.05.2010 13:55, Dave Hooper wrote: Do we require all fonts to support all codepages? Maybe there's a codepage that means 'just numbers', and filter out fonts that support only that codepage (or something). Obviously that would require loading fonts though rather than just filtering by filename; a separate folder makes more sense to me in that case Which reminds me on the following thought: wouldn't it be sebsible if fonts (.fnt) would (or could) include the list of char areas they support? I.e. something like the rasher's page displays?
Re: alle: r26008 - trunk/fonts
On 14.05.2010 12:33, Alex Parker wrote: What happens if you try to select this font as the UI font? Does anything show? All letters but digits would display as the default font glyph which is a rectangle with a sort of smiley inside. So no, barely something readable.
FS#11273 - Format FM frequency depending on the regional settings
Hello everybody. I already asked for comments on this patch on IRC and am asking the same now via mailing list. If nobody objects, I'll commit the patch in a couple of days. The purpose of the patch is to display the FM frequency with as little digits after the decimal point as possible, but with as many as is needed to accurately display the frequency according to the regional FM setting. E.g. for Europe the frequency will be displayed as 95.3, but for Italy as 95.30 since in Italy the frequency is changed in 0.05 MHz steps. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Recent icon addition
We don't have one for if they can be assigned to a quickscreen, and it's fairly easy to be able to check if an option can be assigned to a hotkey very quickly. I agree in that it's hard to tell what a different icon means. Also, IMO a red icon can be interpreted as caution, dangerous! (I said it in IRC). And a short splash would very well convey that the item is not hotkey assignable. I don't think we need an immediately visible cue about the assignability since I assume that hotkey is (re)assigned only very rarely. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Fixed Morse Code case switching (on Sansa Fuze / FuzeV2 only now).
Here I provide a patch which ... [...] The patch (also attached): Interesting: you know how to produce a patch but not that patches should not be sent to the mailing list but instead put to FlySpray.
Re: Fixed Morse Code case switching (on Sansa Fuze / FuzeV2 only now).
On 07.05.2010 23:01, Alex Parker wrote: On 07/05/10 22:21, Al Le wrote: Here I provide a patch which ... [...] The patch (also attached): Interesting: you know how to produce a patch but not that patches should not be sent to the mailing list but instead put to FlySpray. This really seems unnecessarily rude - someone is trying to contribute, they should be encouraged. Hrm... I rather tried to sound ironically but obviously failed. My apologises to Wenyu Zhang.
r25824: rbutil: add fuzev2
Doesn't this commit contain a typo? Shouldn't the string be platform58=sansafuzev2 instead? (Note v2 at the end.) -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
LANG_WPS and LANG_FILE_BROWSER for hotkeys
Hello. I think that the language id's for displaying hotkey settings (r25529)
should bear 'HOTKEY' in them since they are used in a very specific context. As
of now ('LANG_WPS' and 'LANG_FILE_BROWSER') they look like they were a
generally available phrases, i.e. usable anywhere where e.g. the phrase 'WPS'
should be used.
I'd use e.g. LANG_HOTKEY_VIEW_WPS and LANG_HOTKEY_VIEW_FILE_BROWSER.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Simplifying simple lists
Hello. I'm looking at the simple list implementation and find it not as simple as it could/should be. I'd like to do the following changes as a first step: 1. Eliminate the 'count' parameter of the function 'simplelist_info_init'. If the custom 'get_name' callback is not set then the value of 'count' is ignored and the static value 'simplelist_line_count' is used instead. Hence, if you set a custom name callback you'll also set the number of items. But if you don't use a custom callback (most of the time I think) you shouldn't be forced to provide the count parameter. 2. In the function 'simplelist_info_init', I'd also set the value of simplelist_line_count to zero. Since at that point we begin to construct a new list. After a call to 'simplelist_info_init' we should be able to just call 'simplelist_addline' without any intermediate actions. As of now, you must call 'simplelist_set_line_count' in between. Any comments / thoughts / objections? I have other thoughts about this API, but I'll post them later in a separate mail. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Misconception in the simple list API
What I don't like about the simple list API (in apps/gui/list.h) is the following. Before you show a list you should initialize a data structure via a call to 'simplelist_info_init', passing the structure to be initialized as the parameter. Then, in the simplest and, I think, most frequently used case, you add the list items via 'simplelist_addline'. Here, there's already a discrepancy. The first call suggests that you could, for example, initialize two list structures and then show them one after the other. But that's not true because the list items are stored in a static array, hence there can only exist one list at a time. There are two solutions to this: either make all functions and data structures for simple lists static, or make them non-static (i.e. place the list items array into the simplelist struct). Personally I'd prefer the latter. What do you think?
Re: Bookmark mod
2. For now, the pitch and speed are kept at the current settings if the bookmark doesn't contain pitch and speed information. Should it do so, or should we always assume 100% pitch and speed if no bookmark info is present? I would assume 100%, i.e. the latter
Re: Resume playback even if it reached the end and stopped
Having read the replies to my initial mail, I'd like to try to sum up the opinions. There are some decision points. In all cases it's assumed that the repeat setting is set to off and that the playback has stopped naturally, i.e. because the end of the playlist has been reached. 1. What happens if the user presses PLAY before the DAP switches off? Possibilities: a. Display Nothing to resume (current behaviour, preference of Mike Holden) b. Play the playlist from its beginning (my personal preference) 2. What happens after the DAP switched off (manually of via timeout) and back on? 2.1. The start screen is set to WPS a. Display Nothing to resume (current behaviour, preference of Mike Holden) b. Play the playlist from its beginning (my personal preference) 2.2. The start screen is not set to WPS (but to something else), and the user presses PLAY a. Display Nothing to resume (current behaviour, preference of Mike Holden) b. Play the playlist from its beginning (my personal preference) If I remember correctly, we've already discussed the patch on the mail list, and many had the following preferences: 1-b, 2.1-a, 2.2-b. Should I start a poll in the forum? -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser
Re: Resume playback even if it reached the end and stopped
If I remember correctly, we've already discussed the patch on the mail list, and many had the following preferences: 1-b, 2.1-a, 2.2-b. Should I start a poll in the forum? How about neither and instead add another option? Something like Retain the playlist? What possible values should the option have? Could you be more specific? -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02
Re: Resume playback even if it reached the end and stopped
Something like Retain the playlist? What possible values should the option have? Could you be more specific? You just outlined the two options. Either don't restart the finished playlist, or do. There is another question whether to restart the playlist on startup if the start screen is set to WPS. But then the option would have too many possible values and would be hard to understand. So I think a boolean option is the best. I'll try to come up with a patch. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
Re: Resume playback even if it reached the end and stopped
1. What happens if the user presses PLAY before the DAP switches off? Possibilities: a. Display Nothing to resume (current behaviour, preference of Mike Holden) This is also my preference - if I wanted the playlist to repeat I'd have set it to repeat. Normally, I set the repeat option to off. But sometimes (or even often), after the playlist ends, I think Oh, that was good, I'd like to listen to this music once again. At this point, this feature would be very handy. And I see no reason why the player should refuse to do what I explicitly (and manually) request by pressing PLAY. -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail
Re: Resume playback even if it reached the end and stopped
Couldn't you explicitly (and manually) request it to play the list again by highlighting the list and pressing select? I don't use specially prepared playlists but rather just select a file in a directory. After playlist ends I have to again navigate to that directory since the file browsing context is also lost by then. If you can manually hit play to resume, can't you just turn on repeat and manually hit stop as well? That's a feature we already have, and would give you the same functionality without removing an existing feature for the rest of us. Yes, that would be a viable option. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser
Re: Resume playback even if it reached the end and stopped
I don't use specially prepared playlists but rather just select a file in a directory. After playlist ends I have to again navigate to that directory since the file browsing context is also lost by then. You don't use Follow Playlist then ? I do. But this options only has a meaning as long as you are in the WPS. After the playlist ends there is no WPS anymore and hence nothing to follow. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Resume playback even if it reached the end and stopped
My understanding is that you can also view a playlist after it stopped, so it seems like another option may be to simply view the current playlist, and click on the first song. Aha! I didn't know that. It's never late to learn something new! -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser
Resume playback even if it reached the end and stopped
There is a patch (FS#10343 - Resume playback even if it reached the end and stopped) that implements a very nice feature. Has anyone objections for it being committed? If not I'll commit it when I'll get access to the development environment. Cheers AL
Mismatch in r25007 (Histogram display)?
Hello.
Isn't there a mismatch in the code committed in r25007 (Histogram display)? I
mean the new code in apps/menus/recording_menu.c, specifically this:
{ 4s, TALK_ID(5, UNIT_SEC) }
In the other menu options, the number in the first member matches the number in
the TALK_ID, e.g. { 2s, TALK_ID(2, UNIT_SEC) }.
I'm just asking from the syntactical point of view, I have not exactly
understood what and how the new code does.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: r24917: again no manual update
On 26.02.2010 14:59, Paul Louden wrote: This could be solved rather easily by saying if you can't figure out how to update the manual, post a basic text file to Flyspray containing a description of the tags added and what they do. Or, even better, just ask (e.g. in IRC) for the help. Maybe post a snippet to pastebin. Separate tasks in Flyspray could be a bit problematic if there are several changes to the same thing. We'd then have to analyze their chronological order. The best thing would be to commit the manual update in the same commit. I don't force everyone to learn LaTeX, but I'd like to see the right attitude, i.e. striving to keep code and the manual in sync.
Re: r24917: again no manual update
On 26.02.2010 20:46, Karl Kurbjun wrote: I would not want to see the manual holding up the addition of features. I agree that it is a noble cause to keep it up to date, but I do not see it as critical enough to potentially deter developers from adding features or making changes because they are not familiar with LaTeX. I think adding tracker tasks is a reasonable medium between the two. Fully agreed. But at least the tasks should be added.
Re: FS#10187:Theme Deleter - Parses CFG files and removes their files
Why are we discussing this on the mailing list and not in the FS task?
Re: Credits
On 22.09.2009 19:28, Alex Parker wrote: I'm not too clear why we have a separate manual credits file This may stem from the fact that the manual wasn't an integral part of Rockbox in its early days, i.e. part of SVN etc but was rather developed in Wiki or otherwise. IMO a contribution to any part of Rockbox significant enough to get recognition should be in the same credits file I agree. Now that the software and the manual are one there's no reason to have two files. I'd like to add the three people in CREDITS-MANUAL who aren't in CREDITS to CREDITS and then bin CREDITS-MANUAL. Do you want to preserve the historical order of addition? :-)
Re: FS#10199: Limiter DSP function
On 17.08.2009 07:44, Jeff Goode wrote: Jeff Goode wrote: The latest version of my limiter DSP was just posted this afternoon. Its purpose is to amplify the signal by a user selectable amount, then smoothly reduce gain for those samples that clip as a result. This allows listening to dynamic material in noisy environments that could drown out quieter passages, sort of a smart volume control. [. . .] Nobody appears to have an opinion one way or the other regarding this patch Jeff, I read the patch description and tried to understand what it does but couldn't fully do it. (Disclaimer: I'm not a sound processing expert.) And I'm sorry for not having replied earlier. What I understood from reading the description is that it would have an effect as if you manually change the volume so that silent parts of the recording are loud but loud parts of it don't blow your ears. Is it a correct description? Of course, this volume adjustment is made automatically. What scenarios is this thought for? Because this would distort the song. Is it for text only songs? And how would you need to set the volume manually (before you start the playback)? I see two possibilities: 1. set it so that the silent parts are at desired volume, and the loud parts are made more quiet 2. Set it so that loud parts are at desired volume, and the silent parts are automatically made louder.
Re: FS#10199: Limiter DSP function
On 17.08.2009 16:52, Jeff Goode wrote: The 7k is mostly buffers and the code itself, which is whittled down pretty far already. There's not a lot of fat in there. Hm... I have a question: why not have a large enough buffer that would be used by all DSP effects? IIUC, as of now every DSP effect would reserve its own buffer. Why not have it once for all? Would it be possible at all? I.e. we'd have a buffer and then several DSP processors would sweep over it before the PCM data is sent to the audio chip. Just some thoughts generated by (but related not only to) this patch.
Re: FS#10199: Limiter DSP function
On 17.08.2009 19:40, Jeff Goode wrote: Al Le wrote: why not have a large enough buffer that would be used by all DSP effects? Most DSP functions get along well enough without having their input buffered anyway, so it wouldn't come up very often. Ah, so this DSP effect is the only requiring a large buffer? Then OK. But wait... What about time stretch? I think it also uses some kind of buffer.
Re: Weird code in r22153 (changes to strnatcmp.c)
On 12.08.2009 01:13, Thomas Martitz wrote: If you look at the ASCII-table, the underscore (and a few more chars) is between the upper and lower case chars. Ok, that is the point I missed. I thought it was before all the letters (upper and lower case). Everything else made perfect sense to me (converting both to upper or lower case). I would change the name of the nat_toupper to something like unify_case or the like. I would also remove the code that is now deactivated via #if 0. Such things always make me ask whether the author wanted to just temporarily deactivate the code or ...? The similarity to the original code must not necesserily be maintained in this particular case IMO. We should make code easily readable and understandable instead.
A question about r22222 (Factoring out the parsing of %V tag)
Hello. I saw the changes made in r2 (nice number by the way! :-) And I ask myself why this change had to be made. IMO the parser code should be separated from the pure API and data structures code (since parsing might happen in another way for example, without any changes in the viewport API itself). But this change brings them together. What was the reason. This question is for kugel (the developer who made the change) in the first line but for others who can explain the reason as well. Thanks!
Re: A question about r22222 (Factoring out the parsing of %V tag)
On 12.08.2009 13:35, Thomas Martitz wrote: Al Le schrieb: I saw the changes made in r2 (nice number by the way! :-) And I ask myself why this change had to be made. The commit message says it (in preparation of customlist). FS#8799 will need it to parse a viewport from the settings. To make the final diff smaller I committed this beforehand. Ok. This means that the syntax of the setting and of the WPS will be the same. But I don't think it would be a problem. Another question: in viewport.h I see a declaration of the function viewport_load_config, but I couldn't find this function in a .c file. Where is it defined and what does it do? Now please question someone else's code :D It was not particularly your code that I question, just the code I don't understand. But that happened to be yours :-) And another question: the function viewport_parse_viewport returns VP_ERROR in the case of an error. The constant VP_ERROR seems to be a bit combination and not a pointer. The combination just happens to have the zero value which works, but isn't it dangerous? Wouldn't NULL fit better? I can of course provide patches for these remarks if you prefer but they would be so trivial that I'm not sure it's worth the effort.
Weird code in r22153 (changes to strnatcmp.c)
Hello.
IMO the r22153 introduced a weirdly looking code:
static inline int
nat_toupper(int a)
{
return tolower(a);
}
This makes the question arise (to a new code reader) as to why tolower
is called inside the function when the function itself is named
nat_toupper
Besides, I don't quite understand why this change should fix the problem
mentioned in the commit message (improper sorting of names with
underscores when Interpret numbers when sorting is used). Should the
old code work correctly if toupper is implemented correctly? If the
commit really fixes something, shouldn't the real cause be fixed
(something in toupper IMO)?
Just some thoughts by a casual code reader.
FS#10440 (toggle the pitch changing mode in the other direction): tests and a commit permission needed
Hello everybody. As of now, the pitch changing mode (which on SW_CODEC platforms can have up to four values) can only be changed cyclically in one direction. That leads to the following problem: Assume you're separately changing the speed and the pitch (i.e. you use the timestretch feature). After having changed the pitch in semitone steps, you'd like to do fine tuning in procentual mode (ok, for me personally it's rather theretical since semitone steps are quite small thus allowing fine tuning, but still...). But to reach the desired mode you'd have to go through the Rate mode. Thus the speed and the pitch would be set to the same value in between. To avoid that, I've created the patch FS#10440 that allows to cycle through pitch changing modes in the opposite direction. Would you support such patch? I tested it on H120 and Sansa e200, it seems to work well. I also changed the key mapping for other players but have not tested them all. Now I need two things. First, you support and approvement in committing this patch (i.e. whether the feature is welcome). And second, some tests on other platforms. Thanks AL PS. Should I also post this to the user mailing list?
Re: Afterthoughts to FS#10359 (Pitch screen improvements)
On 14.07.2009 17:00, David Johnston wrote: I don't see how reducing semitone precision to .5 would make it better [...] unless we just decide that accuracy isn't really important, which might actually be the case -- just do a simple linear interp and display with only one decimal of precision Yes, that was the idea -- have just table based semitones (in 0.5 semitone steps, i.e. 49 entries in the table). And even (maybe) drop the interpolation. I.e. when switching from procentual to semitone mode, the next semitone-based value would be set. That said, I would personally like to have better than .5 semitone precision. I was actually a little worried about limiting it to .1 precision when I set up the controls -- I wasn't sure if a super-anal musician would object. I can't understand that since for the fine control there is still the procentual mode. And I think no musician tunes in 0.1 semitone steps. I.e. the probably think this should be a major third up. And when they hear that that's still not what they want they think errmm a little bit higher -- but not 0.3 semitones higher. OK, some may think in terms of 0.5 semitones (i.e. this should be between a major third and a fourth), but not finer. They may hear it, but I think these terms (cents) are not that common in the musical education that people think in that categories. What *would* be very useful though is the ability to toggle the modes in the opposite direction -- to be able to directly switch between procentual and semitone mode while staying in timestretch mode. Those and labels always seemed superfluous to me, for instance. They are not very useful, agreed, but they do no harm too (at least with regard to the binary size)
Afterthoughts to FS#10359 (Pitch screen improvements)
Hello. I was somewhat surprised by the size of the red size delta caused by FS#10359 (committed with r21781). Now I try to find a way to reduce the bin size. I don't see an obvious place but I have the following idea. As of now, in semitone mode, the pitch is changed in 0.1 semitone steps. I think if we'd made it in 0.5 semitone steps some calculations would be simplified - bin size reduction. And IMO nobody needs such fine steps. If you need a very fine tuning, you can still use the procentual mode. So if nobody votes against making semitone steps bigger (0.1 - 0.5) I'll prepare a patch. Or if anybody sees another place where the code size could be reduced please tell me. Thank you. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
FS#10359 (Improvements to the pitch screen UI): ready for commit?
Hello. I'd like to draw your attention to the patch in FS#10359. It improves and enhances functionality of the pitch screen, but does not radically change its behaviour. (The radical change would be a subject of a separate patch which hasn't been started yet.) Please give it a try (or look at the patch) and tell whether you see something that would make it uncommittable (besides the lack of the patch for the manual :-).
Re: Context sensitive default file name when saving settings
On 01.07.2009 13:17, Hussein Patwa wrote: Sounds good to me from a user's perspective. Gets confusing if there are too many plain config files about. They are in different directories, and the user can rename them before saving, but still I think that the change is reasonable and leads to a more convenient behaviour.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 30.06.2009 09:26, Daniel Stenberg wrote: There are way larger or more annoying problems that actually hit people that we can work on instead. Agreed. The feature is not that critical for me personally so if there is no immediate consensus on that I wouldn't like to spend my time on discussing it. I think everyone has understood the objective pros and cons, and the question is in their subjective evaluation -- which is a subjective thing :-). Also, this seems to interest only a few people so I suspect that we argue just to argue -- a little bit :-) For me, this topic is closed now.
Re: FS#10343: Resume playback even if it reached the end and stopped
On 30.06.2009 09:20, pondlife wrote: I'd agree with this fully with one addition: if no power off happens in between. I disgree with this a little, it seems counter-intuitive and overly complex. The basic change needed is that, on playlist end, we reset the playlist pointer to the start (exactly as we would for repeat all), then stop playback if repeat is set to off. Yes, but you answer does not address the dimension of power-off. With the current SVN, if the start screen is set to WPS, and I stop the playback (manually) and then switch off the player, the playback starts automatically after the nect power on. So even if the playback was stopped the last time it will start the next time. I don't see a reason to differentiate *why* the playback stopped the last time. And again: I consider Start screen = WPS as an automatic press of PLAY (or selecting resume playback from the menu) after power on, and hence would expect the same reaction.
Re: FS#10343: Resume playback even if it reached the end and stopped
On 30.06.2009 13:36, pondlife wrote: Yes, but you answer does not address the dimension of power-off I must be missing something - I don't see how power off is related at all. [. . .] I consider Start screen = WPS as an automatic press of PLAY (or selecting resume playback from the menu) after power on, That's exactly how I see it too. If I understood Paul's objections correctly, the power off case was exactly the special case (that's why I mentioned power off in the response to you). Paul suggested, that, if the playlist ended naturally, i.e. played to the end (and hence playback stopped), and then the player was switched off (manually or automatically through idle timeout), the playback should NOT automatically start the next time the player is switched on. We're talking about this particular case only. All I'm saying is that at end-of-playlist (repeat off), the playlist index is reset so playback will restart when PLAY is pressed (or Resume Playback is selected, or the player is restarted with Start Screen = WPS). Yes, this is the description of how the desired behaviour could/should be implemented technically. But we first have to agree on the desired behaviour.
Re: FS#10343: Resume playback even if it reached the end and stopped
On 30.06.2009 15:48, pondlife wrote: If I understood Paul's objections correctly, the power off case was exactly the special case (that's why I mentioned power off in the response to you). Paul suggested, that, if the playlist ended naturally, i.e. played to the end (and hence playback stopped), and then the player was switched off (manually or automatically through idle timeout), the playback should NOT automatically start the next time the player is switched on. We're talking about this particular case only. Ah, gotcha. Personally, I would want it to restart automatically in this case - because it would be consistent [...] That's what I think either. For your benefit: here are some excerpts from Paul's mails: Specifically, I'm not sure it's obvious that ended playback should result in a resume on power on. If a playlist ends, because you set repeat off and then the player idle poweroffs, you may be just as likely to not want it to resume on startup in that situation. - On the other hand, if repeat is set to no that means I want the music to stop after we reach the end of the playlist and not start until I manually resume playback or select a new song. Shutdowns can happen without user intervention (idle timeout) and booting up to playback can cause quite a disturbance if attached to speakers when the user knew it was stopped and the playlist complete when they shut down. There's a difference between booting up and resuming a playlist in-progress, and booting up and starting a playlist that had ended. I'm just saying, a resume on boot when playback had ended from the user's perception could cause a nasty shock, and even hearing damage if they've moved from speakers to headphones or similar. I dont't quite get both points, but maybe that's just me.
Re: FS#10343: Resume playback even if it reached the end and stopped
On 30.06.2009 20:26, Paul Louden wrote: I agree that it can be useful honestly. When a playlist ends, it'd be nice to have the option to _manually_ restart it without hunting it down again. I just don't think it should ever automatically be restarted by other things (such as rebooting the player) as I don't consider that a manual request to start a finished playlist, no matter what the start screen is. Actually, I could very well agree with this also, since my main concern is to have the option to _manually_ restart it without hunting it down again. This would probably require slight modification of the patch though.
Re: FS#10343: Resume playback even if it reached the end and stopped
On the other hand, if repeat is set to no that means I want the music to stop after we reach the end of the playlist and not start until I manually resume playback or select a new song. I'd agree with this fully with one addition: if no power off happens in between. There's a difference between booting up and resuming a playlist in-progress, and booting up and starting a playlist that had ended. I've always understood the setting Start screen = WPS as Please press the PLAY button for me once the player is up. And hence would expect the playback to be started in that case. I.e. whenever pressing PLAY after power up would start playback, Start screen = WPS should do it too IMO. This is my intuitive expectation. But, to be frank, I do not use this feature, i.e. my start screen is not set to WPS. Hence my opinion doesn't have to weigh much. We should hear from others who really use it (GodEater?). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 29.06.2009 18:13, Jonathan Gordon wrote: It shouldn't be very complicated. We already know what settings are theme settings (for the Save theme settings menu option). Changing any of those would mark a global flag as dirty. Loading a cfg from the themes menu would reset it. If dirty is set we could do something like showing the last loaded, but with a * at the end (for modified), or show a special menu entry like modified: based off theme XXX) That doesnt solve the problem where 2 themes are loaded and both work fine together... i.e on the hxxx's you could load a .cfg for the main lcd and a .cfg for the remote neither should be selected. You exploit the fact that, technically speaking, a theme ist just a .cfg file. But it's more. We have some settings that are called theme settings, as Thomas said. Only those settings would be considered when deciding whether the theme has been modified. Otherwise there is no sense in having the special menu Save theme settings (or what's the name?).
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 29.06.2009 18:13, Jonathan Gordon wrote: It shouldn't be very complicated. We already know what settings are theme settings (for the Save theme settings menu option). Changing any of those would mark a global flag as dirty. Loading a cfg from the themes menu would reset it. If dirty is set we could do something like showing the last loaded, but with a * at the end (for modified), or show a special menu entry like modified: based off theme XXX) That doesnt solve the problem where 2 themes are loaded and both work fine together... i.e on the hxxx's you could load a .cfg for the main lcd and a .cfg for the remote neither should be selected. You exploit the fact that, technically speaking, a theme ist just a .cfg file. But it's more. We have some settings that are called theme settings, as Thomas said. Only those settings would be considered when deciding whether the theme has been modified. Otherwise there is no sense in having the special menu Save theme settings (or what's the name?).
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 29.06.2009 23:43, Paul Louden wrote: Except file browsers in Rockbox don't work like this, and the main file browser still won't even after this change. Yes, file browser doesn't work like this. And I must admit that the menu entry is called Browse Theme Files which conveys that it's a browser. But still I can think that for a user, a theme is something he selects, and there is not much difference (for a normal joe user) between selecting a theme and selecting a font. But fonts are pre-selected while themes are not. I agree that it's not black and not white, and I also understand your reasoning. I just try to imagine what a user who has never seen Rockbox before and has not heard about themes, configs etc. would expect.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 29.06.2009 23:47, Thomas Martitz wrote: I imagine having the last loaded theme showed as modified with giving the user a possiblity to save as... is a very nice feature (plus that's what the major OSes also do). In that case, we should also provide such feature for all other sorts of settings (sound/recording/eq/...) -- for consistency reasons.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 29.06.2009 23:57, Jonathan Gordon wrote: Also, (to steal one of Lloreans arguments...), what is the point of hiughlighting the currently(-sorry, last selected) theme anyway? the only reason to go into that list is to *change* the theme and in that case there is never a need to know which the last theme was. But then we also don't need to pre-select the font, for example. The reasoning is the same.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 30.06.2009 00:24, Paul Louden wrote: And if a user then changes the setting back? Then the asterisk should disappear IMO. I.e. the dirtyness should be computed every time. On third-party sites there are a few theme packs containing many variants of a single theme, often each with their own .cfg. He-he, a theme *is* a .cfg :-) Consistent with what, exactly? Consistent with the fact that if you select something while in the settings, you'll have that item preselected if you visit that setting once again. Right now it's consistent with browsers If you access the theme folder using the file browser then I wouldn't expect it to be preselected. But the fact that that menu is technically implemented using the file browser code is just a coincidence which should not be clear to a regular user.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 30.06.2009 00:31, Paul Louden wrote: This is basically the point I bring up any time I bring up binsize - is it worth more than other things we could do with this space? But it's something different. Here you say: I have one good thing (a feature) and another good thing (small binary). What is better? I fully agree that we should weigh that, i.e. compare two positive numbers (=usefullness of the things). In the previous argumentation you say that the pre-selecting the theme is not a good thing at all. So there is nothing to consider at all. I.e. we compare a positive and a negative number. The result is clear in that case.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 30.06.2009 00:02, Paul Louden wrote: We now present Fonts as if it were simply a setting, rather than a file browser. This distinction is actually beneficial, because changing the font just changes one value (current font) and if that value is changed elsewhere (maybe by loading a .cfg file such as a theme) the font list *should* (I don't know if it does) update to the new currently selected one. In this way it can absolutely show the value that is in use. This would also work for themes. If a theme setting is changed (no matter how -- manually or by loading a .cfg) then we can add an asterisk to the pre-selected theme (or do some other things that have been proposed here). So we can always tell whether the current state exactly corresponds to the theme or not. But you're judging based on your own expectations. The only thing we know is that there have been very, very, very few people asking Why doesn't it remember what theme I last selected in this menu? so even people who find it unexpected haven't felt it was actually a problem worth reporting or requesting a change over. This is probably because themes are rarely changed and there are not that many of them. So even if the current theme is not pre-selected, you're still not lost. For fonts, it's not so. I agree that it's not that critical for themes, but I think it would make the user interface more consistent. Another question is whether this consistency is worth the binary size increase etc.
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 30.06.2009 00:39, Jonathan Gordon wrote: 2009/6/29 Al Le al...@gmx.de: On 30.06.2009 00:24, Paul Louden wrote: And if a user then changes the setting back? Then the asterisk should disappear IMO. I.e. the dirtyness should be computed every time. There are over 180 settings (IIRC)... if even 20 have the theme attribute that becomes a lot of added complexity for something which isnt an issue... I don't see how the complexity depends on the number of the settings marked as theme. It would be generic code (like the code for saving theme settings).
FS#10343: Resume playback even if it reached the end and stopped
Hello. I like the idea of this patch (FS#10343). I tried it out and it works for me. What do you think about including it into SVN?
Re: Center on loaded theme FS#10391 (+ set_file bugfix FS#10392)
On 28.06.2009 19:48, Jonas Häggqvist wrote: FS#10391 [...] FS#10392 Any objections to committing both of these? No objections from me.
What is the right place for discussing patches?
Hello. This is a general question which arose because of FS#10359. We had discussed something (a possible change) on the mailing list, then someone sent a patch, but the discussion goes further. Now in the form of flyspray comments and replies to them. What is the right place for it? ML or flyspray? On the one hand, discussing an existing patch should be in the corresponding FS task. But OTOH there are no threads there. So if it's going to be a real discussion (and not just some technical comments), what is the right place for it?
Re: Replaygain without a setting, and other menu cleaning.
On 21.06.2009 11:14, pondlife wrote: Yes, but only if you want to use timestretching. 80% (or so) of the time, I want to change pitch without using timestretch so as to keep decent audio quality, thus IIUC I'd need to be changing both speed and pitch identically. Yes, I could disable timestretch, but it's still many more keypresses to do what the current pitch screen does fluidly - and using Rockbox for DJ-ing means you're always against the clock. I wouldn't mind at all if the settings were changed through lists as I almost change only one at a time -- depending on why I'm changing them (I wrote about it earlier). And I agree that the pitch only needs to be changed in semitone-based steps. 1/2 semitone-steps would be fine enough IMO. We'd then have to consider the case where time stretch is disabled. Then we'd have a mismatch in how speed (which is still changed in 0.1% steps) and pitch are set. If timestretch is disabled there would be a mismatch. What setting would win then? Would we make speed adjustment steps match the pitch steps?
Re: Replaygain without a setting, and other menu cleaning.
On 19.06.2009 17:20, Dominik Riebeling wrote: I'd rather merge the two Enable Replaygain and Replaygain Type menus -- simply make it a menu which holds the options currently in Replaygain Type and add an additional Disabled. I've created a patch for this -- FS#10356. Please, review, criticize and improve!
Re: Replaygain without a setting, and other menu cleaning.
On 20.06.2009 22:42, Dominik Riebeling wrote: On Sat, Jun 20, 2009 at 3:33 PM, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Jeff Goode schrieb: That's getting away from the philosophy that the end-user's needs should be satisfied first and foremost, and it's the developer's job to decide how best to do that. It seems you mixed up Rockbox with some other commercial application. This is not the primary philosophy of Rockbox, or FOSS in general. Is that the primary goal of commercial applications? I can't remember having seen such a thing. In fact my experience tells me that OSS usually is trying to accomodate the users need more than commercial applications. Of couse that's only my experience, so anyone else might have made different experiences. I assume Thomas meant that RockBox is about the developers in the first place, not the other users. At least, it's been stated many time. But I still don't believe it entirely! :-)
Re: Pitch screen UI
On 20.06.2009 05:01, David Johnston wrote: When I modify those settings they're changing correctly in the global_settings struct. They're not, however, being saved unless I also change something through the menu system. I think you have to register some hook (or set some flag) that tells the Rockbox system that a setting (or several) has been changed and need to be saved. Menu code must do that somewhere. However I don't know what exact function you should call.
