All Projects

This issue affects the standard 3.6 build for an E280 (fresh install via rbutil) but also affects sim and target for E280 with current trunk.

To replicate,

Settings→

Manage Settings->
  Save .cfg file

There is a single page with the default keyboard, but pressing the dedicated page-flip key (REC in this case) results in a second page with a smaller font / odd characters.

This also seems to happen where there is a custom keyboard layout with several pages.

In tests in the sim, this only seems to happen when processed via the page_flip action key; invoking page flips programatically in response to *another* key does not result in this behaviour.

When I check the version number on my F40, it’s is displayed only briefly and in a small font, and find myself needing to do it twice to get it.

I realise that this is an infrequent need, but any of: waiting for a keypress before displaying the scrolling credits; delaying for a bit longer; making the font on the version number bigger , would all help.

If anyone considers this, or has questions, please also conside  FS#7582  - used in concert, I think these two feature requests would result in a *lot* of flexibility as far as ad-hoc searching, sorting and filtering results is concerned

Currently specifying a hierarchy for identifying tracks involves combinations such as

genre → track

I’d like to suggest that the tags currently available for use in navigating in this way are augmented by pseudo-tags in the form keyword_artist, keyword_album etc.

The entries generated by these pseudo-tags are lists of words generated from the underlying tag in question (a “word” being space-delimited). Selecting one of these words presents of a list of any entries featuring that word.

As an example, take the following tracks/genres:

“Are Friends Electric” - “Electronic” “Waiting for Cousteau” - “Ambient Electronic” “Let Me Entertain You” - “Rock Pop” “The Honeydripper” - “Jazz” “Ace of Spades” - “Hard Rock” “Albedo 0.39” - “Ambient Electronic” “Main Sequence” - “Electronic Jazz” “Chameleon” - “Ambient Jazz”

Using genre → artist in the standard view results in this for the first level:

“Ambient Electronic” “Ambient Jazz” “Electronic” “Electronic Jazz” “Hard Rock” “Rock Pop”

Selecting “Ambient Electronic” results in:

“Albedo 0.39” “Waiting for Cousteau”

By comparison, using keyword_genre, the first list results in:

“Ambient” “Electronic” “Jazz” “Hard” “Pop” “Rock”

Selecting “Electronic” results in:

“Albedo 0.39” “Are Friends Electric” “Main Sequence” “Waiting for Cousteau”

and selecting “Jazz” results in:

“The Honeydripper” “Main Sequence” “Chameleon”

1) The requirement for manually entering fixed/dynamic search terms would be reduced dramatically - much easier to select from a list of words that already exist than to manually enter and “fish” with a search term.

2) Although I think this adds flexibility by itself, combining with  FS#7582  would enable a very simple but powerful system for searching and categorising tracks. Selecting any “Ambient Jazz” becomes a simple as searching for “Ambient” and then “Jazz”.

Adding a suitable keyword to a chosen ID3 tag effectively adds an ad-hoc user-definable dimension to categorisation - instruments, moods, conductors etc.

It would be easy to envisage, for instance, adding keyword terms such as “60bpm”, “100bpm”, “150bpm” to a set of tracks and allowing the user to retreive music sutiable for the gym or relaxation etc.

3) At first blush this seems like it may result in very long lists and be demanding in terms of resources, but I don’t think this is the case - if anything extracting keywords should shorten the potential list for reasonable sample sizes.

I’ll try to extract my own tagging information and process the text with uniq to see what the balance is.

4) Clearly there may be issues in defining a “word”. As a starting point, I’d suggest space delimited, case insensitive, and with punctuation stripped out.

When using the “standard” set of grouping/filters for navigating the ID3 database, in addition to the results list, we have access to “specialised” entries, <All Tracks> and <Random>; these are applied to the current subset of tracks identified by any database browsing that has taken place so far.

I’d like to request a 3rd specialised entry, <Custom>. This would present a set of custom filters, defined in the same manner as the current custom tagnavi conf entries.

1) The custom filters would be defined in a configuration file with a fixed name and location (custom_filter.conf or similar), and the *same* set of definitions would be available by accessing the <custom> specialised menu entry whenever it was displayed near the top of a results list.

2) The custom filters accessed in this way would be applied to the current subset of tracks *already* identified by whatever tagnavi browsing/filtering has taken place

3) The result list obtained by selecting any filter defined in the custom file would also contain a specialised <Custom> entry. Selecting this entry would effectively allow filters to be applied from the custom menu in any order and to an arbitrary depth (other technical constraints notwithstanding)

I think this feature effectively means arbitrarily powerful sets of on-the-fly filters with a small, simple custom definition file, and a bit of recursion.

This is inspired by the Rio Karma behaviour.

IF the volume is currently set to Maximum
AND the player has been explicitly powered off (as opposed to power-down on a timeout)
THEN reduce the volume when the player is powered up again.

The logic behind this is that maximum volume tends to be used when connecting to car transmitter / cassette adaptor / line-in on a stereo.

If the power has been explicitly turned off, there’s a decent chance that the player is being moved.

Dropping the volume when powering on in these circumstances reduces the risk that you’ll knock your head off when you plug in your headphones and forgotten that the volume is cranked right up.

This should not be applied on auto power-off, as this would imply some temporary pause as opposed to a change of use.

Gigabeat F40
r13516 -070529

“Settings”→

"General"->
  "Display"->
    "Scrolling"->
      "Scroll Speed"

The sample text does not scroll when first entering the screen or changing the speed.

Cf. “Scroll Step Size” which does.

This may be due to the length of the test text in each example.

“Scroll Speed” displays “Scroll Speed Setting Example” and “Scroll Step Size” displays “Scroll Step Size Setting Example Text”

Hard to tell if the test for “Scroll Speed” doesn’t scroll because it’s a bug, or doesn’t scroll because it doesn’t need to due to the display size of this target.

Perhaps a super long test string is in order?

How about allowing the virtual keyboard to be rotated through 90 degrees clockwise on the Gigabeat (or other players with portrait style displays). This may make use of custom fonts for the virtual keyboard more practical.

This is possible to a certain degree:

1) Add multiple keywords to each genre:
“Classical” “Classical; Rock” “Soft; Rock” “Electronic” “Electronic; Rock”

2) Add a custom entry in tagnavi for each of the predetermined genre keywords:

“Classical” “Rock” “Soft” “Electronic”

Each entry resolves to a search of the genre tag for the keyword in question.

To search by multiple keywords, nest these keyword ordered menus to as many levels as required. May result in largish config files.

To make this process easier, would it be possible to add a keyword entry that automatically split the Genre and presented a list of keywords in this way? This would mean less “manual” intervention when organizing/selecting music to suit a particular mood.

Genre was the tag that sprung to mind for me, but I’d guess if it’s possible for Genre it should be extensible to any tag, perhaps excluding “noise” words, those containing numbers/punctuation etc.