FM layout

[josephcs]

Can FM layout be changed in future versions?

Music Player >> rocks! Uses theme images and the layout depends on the respective theme.
FM >> A black screen with text at the top left corner.. This can be changed to something like the normal music player..

FM Station naming is really a wonderful concept..! That thing should be appreciated.. 

[AlexP]

Can FM layout be changed in future versions?

Of course, somebody just needs to do the work....

[josephcs]

Can FM layout be changed in future versions?

Of course, somebody just needs to do the work....

The text can be aligned Center with a little bit extra line spacing between the lines, so that the screen is somehow covered..

[AlexP]

There is no point doing a half-arsed job IMO - if somebody is going to take the time to do it I'd like to see a WFMS (While FM Screen) - especially for newer targets such as the gigabeat S that can do RDS.

[Mr Whippy]

How about retro style display?

http://www.tonyhartmusic.co.uk/store/general/hifi/images/sontun.jpg

[Chronon]

I believe that a big part of BigBambi's suggestion is that if someone does this right this screen should be customizable in similar fashion to the WPS.

[AlexP]

Exactly

[JdGordon]

im slowly working on getting to a WPS-like fm screen (and have been for many many months )

one (minor-ish) problem is what sort of tag system do we want to use? do we reuse the same tags from the wps and try to map things sensibly? (i.e track title -> station preset name or something), or do we ignore that and just add new tags for fm? the first seems nicer because it means you could use 1 .wps file for both screens, but it might not be easy to do the mappings.

I'd like to think ill eventually get wps fm done, but like i said, ive been working on it for months (i think first attempt was dec 06 :p ) maybe for release 3.4

[AlexP]

I think trying to remap could get confusing - I'd prefer new tags and I don't think we will actually need too many new tags.  Many are going to be the same (battery, clock etc), leaving things like station preset name, frequency, mono/stereo, mode - I'm struggling to think of many more.

[cool_walking_]

I don't really use the radio, but I agree with BigBambi.  Having a token mean two different things feels messy.

[Chronon]

Plus, to reuse an existing .wps file you have to make decisions about how to treat the various tags that won't be supported in the FMPS/RPS.  Tags that print text need to be treated as a LF while those that display images should be ignored entirely.  This seems to get a bit tricky since conditional tags need to be treated differently depending on the content of the different conditions.  From a novice programmer's standpoint, it seems simpler and cleaner to just define new tags to provide functionality that differs from the WPS.

[Llorean]

The problem with different tags (and ostensibly a separate .wps file) is that you'll most likely then either need a complicated method for sharing images between them, or be storing many images twice.

FM really only has four applicable fields if I'm thinking clearly -
Frequency
Station name
RDS
Preset Number

Then you could do something like this: frequency could be "track title", "station" could be artist, "RDS" could be album, and "Preset number" could be playlist position, fairly easily. This is a bit 'dumb' but it means probably 98% of existing WPSes would effectively display for FM as is.

Otherwise you end up needing either a "radio" conditional for the WPS, so that one WPS can contain separate radio code (perhaps replacement viewports) or you need to come up with a way to 'share' as much as possible between two .wps (well a .wps and a .wrs) files so that memory use is kept down.

[AlexP]

I don't see why it has to be that complicated to share images - you have at the moment mytheme.wps and a directory mytheme with all the images in.  Why not just have in addition mytheme.wrs, and both the wps and the wrs can use the images in the mytheme directory?  The only downside is that you would be duplicating some code between the two for e.g. volume and battery.

I would add mono/stereo to your list of tags, and also expand RDS - there are various fields within RDS that one may or may not wish to show.

[Llorean]

That shares the image files, but you'd still end up having to keep track of them somehow. I can't imagine that the current method wastes space by remembering the filename once the WPS is tokenized and buffered, let alone if a different WPS is loaded, then they change back, etc. Separating them into two files means you need a fair bit of complexity to keep images from existing in memory twice.

[JdGordon]

My preferred method is to have a radio conditional, but I dont fiddle with .wps' so thats probably not the preffered way for people that do.

I'm currently working on a patch which completely changes the way RAM is managed in the WPS which could potentially use no extra RAM if an image is shared between both wps type screens, but anyway, I dont think thats an issue... if the radio gets wps'ed then one way or another we will make images work.