For one of my Empeg programming endeavors I'd like to obtain the FID number of the currently playing song. The empeg state block has the current position within the playlist, but it's my understanding the playlist data itself is kept on the scratch partition... When I asked for some assistance on how to obtain the current song's FID, I was told to wait until v2.0x because the format of the scratch partition was going to change significantly. Well, 2.0x is out now and I'd like any information that will be helpful in letting a user application determine the FID of the currently playing song.

If there's an easier way to get the FID than scouring the root partition, I'm all ears. I wasn't able to find anything resembling a FID in the state block.

Thanks much.

No responses? Come on, there's got to be a way to do this...

I'm sure they'll respond when they've got time. They're a bit busy at the moment, I think.

I'm sure they are, I just didn't want this thread to disappear off the radar. I have done some work on a lyrics scroller and the missing link is the ability to get the current song's info (FID at least). The timecode is in the state block, so that part is a bit easier.

What would be really useful would be if a number of bits of info (timecode, FID, ID3 Tag values, etc.) were placed in the /procs tables so that you could always use the facilities provided by the OS to discover what the player is doing without having to interrupt the player. It would also reduce the player's burden (no special startup commands, serial output, etc.).

Yup, that would be just grand... Though once you have the FID, you can get the ID3 tags by just reading the corresponding ASCII fid. The timecode is available by reading /dev/empeg_state or something like that, it's one of those things that's written to the state block in flash every second. But the current FID, to my knowledge, isn't...

The only related things I could see written to the flash were the playlist number (possibly the playlist's FID, but I think it's just some internal number in the database) and the position within that playlist (which song you're in within that playlist.) I haven't found a creative way to gather the FID from these bits of info, so I think some reading of the dynamic partition would be necessary unless there were a nice pretty way to get the FID, as you have suggested.

A lot of people are out at the moment (holiday, sickness, whatever). We had a grand total of two programmers today, not counting Hugo and Mike (they don't count do they?). So the BBS probably comes a little way down the list at the moment, sorry.

Rob

(they don't count do they?)

Sure they can. Only to ten, but sure they can.

. Only to ten, but sure they can.

All the way to twenty if they remove their shoes and socks...



tanstaafl.

Please don't encourage Mike and Hugo to remove their shoes and socks in the office.

Rob

You mean they *don't wear sandles ?

Can't you just put him back in his box

Hrm at least with all this silly talk my thread is staying on top... Sadly, nobody's taken a stab at a solution.

Mmm.. you're correct in that the empeg_state does not store the FID of the current track. Bummer.
In an ideal world, the empeg folks will add this info to /proc/whatever for us someday. But don't hold your breath waiting for them to do us this freebie, and we cannot easily do it our selves since the player code is closed source..

Ironically enough, if we had the FID, and a way to "Feed" a FID back into the player software, this would be all we'd need extra to replace the player menu system entirely with our own menus (that scroll vertically instead of the clever but clumsy horizontal scrolling the player uses..).

The only "clever" idea I have so far is to just "intercept" the calls to "open()" and have code recognize when FIDs are opened/closed, since the FID is part of the pathname. This could be stuck into a hacked (or hijack'd) kernel without much trouble, and made available via /proc, ioctl(), and the vitals display. The only trouble is that the player buffers ahead, reading the next track(s) while playing the current selection.. but I wonder *when* the close() gets called for a track.. ?

-ml

Yeah for my uses (a lyrics scroller) I'd need to know what FID is open and *now playing* not when it's opened for buffering, etc. Awhile back, and in response to a somewhat different question, Hugo gave me some hints about how this would be done, but he said the hda3 structure was changing for 2.0. Well, since 2.0 is here I thought we could re-open this issue.

The way I see it, unless they decide to give us a nice /proc like solution, the next best solution is to read the empeg_state block and get the curren't song's index within the current playlist (I know which offset it's in). Then find that index in the /dev/hda3 partition, and hope the FID is buried in there somewhere.

It's amazing what you have to do to get a little hexidecimal number...

Very very very originally, the player did have vertical menus; horizontal are better, given the controls (or so we decided after playing with both quite a lot).

fd's are cached, there may be a number open at a time with no particular way I can think off (offhand) to work out which is the actual one in use.

I suspect a named pipe or similar is the best way to get the info out of the player, but I'll let Mike comment on that!

Hugo

So what you're saying is that there seems to be no way of figuring out which FID is playing except that the player knows, and *could* provide that info to /proc or somesuch (if Mike felt like throwing us a bone)... But would the method I've described work? Are the FID numbers stored on the dynamic partition somewhere?

I suspect that empeg_state now stores an offset into the current playlist, which is stored on hda3. I'm more kernel-level though, so I can't tell you the exact relation between the two...

Hugo

Yah it certainly does store an offset, I've found that. I was just wondering if that playlist data on hda3 contained the FID number. I guess I'll have to wait until Mike can comment on it or something. Not a problem, I've got other projects cooking these days, but the lyrics scroller might be the most interesting to the most people, based on some discussions in the past.

Yes, it definitely contains the fid, I just don't know what else might be in there. There is a running order and a playlist; I suspect the offset is into the running order, which indexes into the playlist. Lots of indirection ;)

Hugo

Hey indirection is a wonderful thing. I just need to figure out how to dereference it all!

A little earlier I dumped the entire hda3 partition to a file and tried to scan it for things that looked like fids, but had no luck, so I will eagerly await Mike's return to the BBS.

Would you have a problem with Mike or someone else sharing the structure of hda3 with us?

>Very very very originally, the player did have vertical menus;
>horizontal are better, given the controls (or so we decided after playing with both quite a lot).

Yeah, the horizontal menus are Ok. but the human eye just doesn't work that well for horizontally scrolling playlists... way too much distraction to have any sort of continuity to the visual text.

Vertically scrolled playlists are MUCH easier for human eyes to sift through.. everything lines up evenly on the left, and the eye can rapidly scan the entries above/below.. That's why hijack uses vertical scrolling for it's menus, as well.

Cheers

Very very very originally, the player did have vertical menus; horizontal are better, given the controls (or so we decided after playing with both quite a lot).

I like the horizontal menu system. I don’t believe it should move to a vertical one.

However I do find some things annoying about it. It seems like the length of the scrolling animation is hard coded. If you press right many times (or spin the knob a bunch) I feel like I have to wait for the menu to catch up to make sure I haven’t passed what I’m looking for. This effect is magnified for longer menu titles.

A possible quick fix would be to drop the menu animations if more then a couple left/right button presses are “queued” up, and quickly skip right before targeted title, and then animate from there. Did that make sense?

I like the speed of the hijack menu system. Does anyone else feel this way or am I just being picky?

Tom

Hi.

I do have a problem with the current menu display implementation. I have many playlists that have a name that doesn't fit on the screen, and I only get to see the middle part of the name. Doesn't help much when having a couple of playlist all named "Kuschelrock Spezial Edition - (whatever)" and only seeing "schelrock Spezial E" or something like that.
Also, I think navigating lists is a lot easier when they are displayed vertically (one entry below the other). I do see the problem of this being a little contradicted by the way the buttons work now (left goes left and right goes right). But anyway, it wouldn't be all that difficult for the user to use the righht button for down and the left for up, would it?
In other words: Under normal circumstances, the horizontal menu is great, but for playlist navigation, I would prefer a vertical one for sure. A config.ini option for that would be great.

cu,
sven

I don't think vertically-scrolling playlists would give you but maybe 4 or 5 more characters than you get with the current horizontal structure. I just browsed my playlist menu to a song called "Several Species of Small Furry Animals Gathered Together in a Cave and Grooving With a Pict". The Empeg chops it off and displays it at "Several Species of Small Fur...". So if we had vertical scrolling playlists, they could maybe extend it to Furry Anim... before you hit the width of the display. Not much of a win.

The real limitation here is not the direction in which it scrolls, but the fact that we've only got 128 pixels to play with. The player is already smart enough to use the small 5 pixel font when a playlist/song is too long, that's about all it can do.

The thing I think vertical scrolling would be helpful in would be seeing more than one playlist ahead or behind of the one that's currently selected. The 5 point font fits 5 lines on the display. So if it was done right you could have the currently selected playlist, two before, and two after. This would make browsing a little easier. It'd probably look something like the Category selection screen in my trivia game, though I'm sure it would refresh much faster and look more polished.

The real limitation here is not the direction in which it scrolls, but the fact that we've only got 128 pixels to play with. The player is already smart enough to use the small 5 pixel font when a playlist/song is too long, that's about all it can do.

Umm, no... With a vertically scrolling playlist you can also horizontally scroll the currently selected item if it's too long to display. That would let you see its full text.

I wrote a wish item about this already (maybe not in its own message unfortunately), along with a wish to show the artist name next to the track name in the Now&Next info display.

I do agree with Sven however. A custom option in the ini or otherwise set in emplode's player options. This is significant enough that I would not want to forcibly saddle everyone with it.

Bruno

Er... I guess... But you'd have to use the knob to do the horizontal scrolling, as the vertical scrolling would be done with the left/right buttons.. I think that'd be very unwieldy, I'd rather just make my playlist names shorter so I don't have to futz around with scrolling long playlist names.

Just look at the automatic scrolling of long entries in the Track Info screen. Everyone begged for that, and then almost immediately people began blasting it, saying it "bounced back and forth" too much, etc. Some people wanted it to keep scrolling and wrapping in the same direction, others wanted the back-and-forth to go slower, etc.

Adding the ability to do either vertical or horizontal playlist selection JUST so people with really long playlist names can see them all, seems like a lot of work for little gain. Remember, playlists are being de-emphasized as the primary means for searching and adding to a playlist or running order.. Soup views are going to make a lot of peoples' playlists unnecessary. And the search screens already do vertical scrolling, though they don't allow you to scroll horizontally to see the full names of long entries. Having two different ways to select playlists doubles the time they need to spend testing them, and if they add any new tweaks to the playlist seletction process, they need to add those tweaks to two different sections of the code. Boo.

I guess I'm opposed to this because I fail to see why you can't just use shorter, possibly abbreviated playlist names. Solutions to common problems don't always require a software fix... I would rather see their Empeg time, which seems to be very little these days, devoted to something other than scrolling a few long playlists to the left and right.

It already *does* drop frames, but I think it will still animate the "stopping". I can spin my dial in the artists menu and jump many more items than get displayed.

The hijack menu seems faster due to it bypassing the 8 frame fifo used to sync audio/video in the player (8/38th of a second). John did do some work on changing the way this worked, which did make the player feel more responsive, but I don't think it made it into 2.0

Hugo

I don't think mike necessarily reads the bbs much at the moment; you may need to email him.

No problem with telling you the general format, but it may change at any time without notice.

Hugo

Er... I guess... But you'd have to use the knob to do the horizontal scrolling,

Maybe I should have said *automatic* horizontal scrolling. The same type we have now in the 2.0 software.

There is no need for an entirely new methodology. The vertical capabilities already exist, they're just not being used as much or as well as they can be.

Making playlist names shorter doesn't buy you anything and isn't practical except for some generic top-levels anyway. I will not shorten the name of a band nor the name of an album under any circumstances.

Soup views and playlists are the same thing as far as this topic goes. This is a display and presentation issue, not an issue of field types. Presenting any soup information on one line in a horizontal fashion will lead to the exact same limitations.

Vertical scrolling allows you to see more than just the selection (track name, album name, artist name, whatever) - that's of major importance.

I don't find it enjoyable to scroll through an enormous list of bands horizontally. I also don't find it natural to look at tracks listed horizontally. Menus are fine, I'm used to a horizontal layout from using a Windowed operating system for 16 years. I'd even be fine with the top-most level being horizontal.

But I'd like vertical for navigating contents below the very top. And I'd like the ability to quickly jump up to the top of the list with one press as well (useful for when looking at a huge view). Not to mention some type of scroll acceleration when holding down the next button.

Anyway, I'm sure when soup views come online you'll see people SCREAMING for vertical scrolling. I don't see anyone having a nice time horizontally scrolling through a list of "ALL TRACKS" for instance.

Bruno

Who has said that soup views will be horizontal scrolling? I've seen nothing to suggest that...

If soup views are different than navigating playlists, then you'll have yet another mixture of paradigms to confuse things.

I certainly hope they're not horizontal. At the same time playlists are now, and should always be, useful. Soup views can be used to filter down your selection, but they can't provide for the refinements and non-logical possibilities that playlists provide.

I wanted to avoid asking for features like this until at least the next beta is out. Generally I think betas should be about knocking out bugs - new features should already be crammed in before something goes beta. :)

Bruno