Support and General Use > User Interface and Voice
Unable to customize menu 3.13 on (SanDisk Sansa) Clip+
[Saint]:
--- Quote from: gomezz on October 27, 2014, 06:36:24 AM ---
--- Quote from: gevaerts on October 27, 2014, 06:33:33 AM ---in software release terminology it tends to mean "changes often".
--- End quote ---
Not in the software release terminology with which I have been familiar my whole working life.
--- End quote ---
We define the terminology clearly on the main page.
--- Quote from: gomezz on October 27, 2014, 06:36:24 AM ---
--- Quote ---Rockbox Development Builds
These builds are provided fresh after every source code change. If builds are not currently showing, wait 5-10 minutes and then refresh the page.
Since these builds are generated from actively developed source, at times they may be buggy or even unusable. We appreciate your feedback on any issues you may encounter.
For a stable build, download the latest stable release.
--- End quote ---
What am I supposed to make of that then? ???
--- End quote ---
I'll give you that.
This presents some non-small area of confusion, granted. Perhaps adding further to the confusion in this case is that we're not talking about the differences between stable/unstable/unusable in this instance, but rather (or perhaps as well as) release/development.
The targets with a stable release are also expected to be largely functional in the development builds, the fact that it is a development snapshot doesn't detract from the fact that the port achieved a status of stable. Once one is aware of what we mean when we use the terms stable/unstable/unusable, it becomes quite a bit clearer. Sure, it is possible that a development build will unearth some new bug, that is always a risk, but a development snapshot is also going to include some two years worth of additional bug fixes and any bugs unearthed are usually dealt with rather swiftly.
Much more swiftly than, say, the release cycle. Which at this point, as you may well be aware, has ground to a halt.
The fact that we haven't released in ages isn't due to us not being able to offer a stable release, it more of a communication and community breakdown, but that is a topic for another long winded post I believe.
I hope I have made things somewhat clearer, it should fall into place when one has an understanding of our port classifications (stable/unstable/unusable) and what they mean, but if I've just managed to dig up more questions I'm happy to take a stab at answering those too.
[Saint]
gomezz:
Thanks for that considered response. I appreciate better now how things are done here being very much a newcomer to the Rockbox world.
gordonmcdowell:
I'll look at recent (stable) builds. Thanks. I'm not really worried about a student trying to re-enable the radio... will deal with that if it comes up rather than presuming it will be an issue... it does not seem like disabling radio hardware is a feature most people would want.
Um... but I do have a more generic issue for Clip+ hardware. I don't want to try resolve it on this thread, but I am wondering how RockBox coders would perceive a "bounty".
I use the Clip+ to capture audio for a documentary. The timing is off a bit... I need to speed up the audio to 100.04% when editing for a steady sync. (And that value is an approximation!)
That could be addressed by either fixing the timing... maybe not possible... or simply altering the meta-data on the WAV so that the Hz is an accurate number... it seems most editing packages will then interpret the audio correctly.
Is offering a bounty a socially ok approach? I should I just throw a small amount of money at RockBox and hope someone will deal with it? I mean if it could result in a new, "stable" build for Clip+ which includes newer features AND addresses this problem then the school is helped and I'm helped... but I don't want to offend anyone by going the bounty way... but I don't want to donate money hoping it will be addressed only to find it ignored and then thing to myself ("darn I wish I'd tried the bounty approach").
So is bounty socially acceptable? (And I don't see a mechanism... is the idea I just post the wish-list to Support forum, and if anyone names a price I can consider the generic PayPal Donate button as a way of unofficially getting-it-done?)
saratoga:
--- Quote from: gordonmcdowell on November 14, 2014, 10:55:05 AM ---I use the Clip+ to capture audio for a documentary. The timing is off a bit... I need to speed up the audio to 100.04% when editing for a steady sync. (And that value is an approximation!)
--- End quote ---
Thats normal. Unless you use the same clock for audio and video they will not line up exactly, and the difference will change over time.
gordonmcdowell:
It does not change over time... and it is consistent across the 50-or-so Clip+ I've used since using them for this purpose. Maybe there's some fluctuation down at the smaller decimal values, but I've never had a better fix than by adjusting rate to 100.04% in the editing package (Premiere Pro CC... for many revisions... and this also happens in Sony Vegas). And I've ordered from 3 different refurbished-vendors on 3 different years.
Maybe it won't be perfect, maybe it will drift a tiny bit on top of this issue... some a tiny bit faster some a tiny bit slower. But there's a substantial timing problem there that I'm certain is consistent in the hardware, bigger than the small drift you might be predicting.
And... I see the 1.4.0 installer now allows me to automatically install a fresh (non-"stable") build! That's great but loading a tweaked config.cfg file seems to have no impact on menu, even though I'm using the latest dev build, edb0c6c-141.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version