Please post any new feature requests or general wishes for emphatic in this thread.

My only wish at the moment is to have every song in my collection SYLT-tagged. And with the ease of the new SYLT plugin and LRCDB, that's something that could theoretically happen now.

A long time ago, I said that my head would explode if I saw scrolling lyrics on the empeg screen. Well, I'm well past the Go Boom stage, but I still just sit back and think "how cool is this?" every time I see it. Of course having Toby's visuals blended behind those lyrics is grounds for complete spontaneous combustion.

I can't imagine anything more geek-perfect than this. It just doesn't get any better. Excellent work, man.

Less CPU and smooth scrolling go hand in hand, don't they? How are those different issues? Try turning off the "burnin" effect in the XML file. That uses a TON of CPU. If you're still not happy with scroll speed, then it won't get any better, because the player gets CPU when it wants it. Without the burnin effect, CPU usage for me is typically 5% or less, even with visuals in the background.

As for starting automatically, I believe that belongs in the Hijack wish list, not mine.

Relevant source code attached.

Ah, right, I remember now. Cool.

My thinking was that you're looping the WORST on things that never get set to black. In other words, your algorithm uses up more CPU the less text there is in the foreground layer. One word by itself on the screen uses up more CPU than a dense paragraph of text.

Since the text is usually fewer pixels than the bacground, my thinking was that it'd make more sense to do it the other way round, not doing an inner loop until you hit some lit text in the foreground layer.

There's gotta be a way where you scan through the pixels looking for the lit text in the foreground layer, and only THEN do your little circle around that pixel looking for transparent pixels and marking the black spots onto the background layer where the foreground is NOT lit. The trick is coming up with a simple system whereby you can short-circuit that inner loop the most efficiently so that you're not re-blacking stuff that's already been blacked. Looking at the problem from that angle, I keep telling myself there's gotta be a way to do that efficiently and shortcut a lot of the brute force work.

Or, perhaps there's a totally lateral-thinking way of getting the same effect without having to iterate through every single pixel. That'd be the real win, and there's so many examples of this kind of thing in other fields (edge-finding algorithms in paint programs, chroma-key applications in digital video), that there's gotta be some prior art which shows how to do it. There's just gotta be. I have no idea where, but hopefully someone else here on the board would know.

Hijack doesn't attempt to deal with handing the screen to the apps right now -- can the app instead simply grab the screen at startup? Oh, wait.. we don't have an ioctl for that..

Gimme a few more minutes..

Okay, Hijack v405 is out.

The only change is a new untested ioctl() call that apps can use to immediately takeover the display/buttons, as if they'd just been selected from a menu, but without the need to bind to the menu (in fact, crazy things could happen if they DID bind to the menu first.. or not.. haven't thought about it much).
Code:

---

if (0 == ioctl(fd, EMPEG_HIJACK_TAKEOVER, NULL)) {
      // success, we now own the display
} else {
      // probably got EINTR, or some other error
}

---

The practical use of this new ioctl is in combination with the v403 ;@MENUEXEC feature, so that ;@MENUEXEC can be used to select/activate the app from scratch, and the app then invokes EMPEG_HIJACK_TAKEOVER to foreground itself on startup.

If another app already has the display (in use), then EMPEG_HIJACK_TAKEOVER will block until the first app releases the display.

Cheers

Hijack v406 will be out Real Soon Now, fixing a slight logic error on the new TAKEOVER ioctl.

-ml

While you're in a giving mood, care to give me an ioctl which blocks until the player's finished starting up? Or can you detect that? (By start up, I mean it's gone through the "reading databases" and all that stuff.)

Problem is, my app starts up and calls TAKEOVER (which works great in v406, BTW) and wants to change info modes, but the player isn't ready to accept button presses yet. My other alternative is sleeping for some period of time, but that's hokey.

Well, internally Hijack has a concept of "player started", but I don't recall how it treats poweron->standby.

I'll stick a waitq and ioctl onto it for you, and you can play with it.

EMPEG_HIJACK_WAIT_FOR_PLAYER

Cheers

Another new ioctl() call for use from apps. This one pauses the app until the player is deemed "started" by Hijack. No effect if player was already up and running.

-ml

Okay. v407 is now up on the server.

-ml

WAIT_FOR_PLAYER works very well.

I'm a little confused about using TAKEOVER though. It works, but if I quit my app (call WAITMENU with NULL) my program exits, but the screen is frozen (i.e. the player buffer doesn't go back to the foreground.) I think I understand why (I didn't originally call WAITMENU to bind to the menu to begin with.) Any way around this? Maybe some operation that's the inverse of TAKEOVER and explicitly hands control back to the player or the hijack menu? I guess my problem is I'd like to TAKEOVER in the beginning, but I'd like to give the user the option to close my app temporarily (leaving it running and available in the Hijack menu) which I presently accomplish using the WAITMENU ioctl. Can these two play nicely together?

I think I can fix TAKEOVER so that a WAITMENU(NULL) works correctly -- v408 shortly.

Fixed.

Any way to fix it so that I can start with TAKEOVER but then bind to the menu? i.e. logic like this (apologies for slacker pseudocode syntax)

Code:

---

WAIT_FOR_PLAYER
TAKEOVER

while (!quit)
{
  while (!hide)
  {
    


  }
  WAITMENU(menulabels)  // to bind to the hijack menu
} 
WAITMENU(NULL)  // to quit

---

Just do a WAITMENU(NULL) before the first WAITMENU(non-NULL).

-ml

Couple of unrelated wishes...

------ Emphatic wish: -------

Have some sort of a file, most likely XML, which you do NOT supply in the emphatic distribution, which can contain overrides to the current XML file. In this file, I could place my own personal customizations that are above and beyond the default settings supplied with the "factory" distribution.

For instance, if I want to customize one of the visual modes, or change the exit_visual and exit_info settings, currently I must do so by editing the main "emphatic.xml" file directly.

This means that if you do a new release of emphatic with new visual modes in the main XML file, then I must merge my changes into your new file before placing it on the player.

But if I had my own override file, and it contained ONLY the things I wanted to be different from your XML file, then updates of the original XML wouldn't be a pain to install.

Please forgive me if this feature already exists and I just missed it.


------ LrcDB wish: --------

A link I can click on that would let me see a single list containing all the songs I have submitted.

Again, if this exists already and I just missed it, my apologies.

Oh, Tony, while watching a lyric scroll by, I had an epiphany about the CPU usage with the burnin feature.

Are you recalculating the burnin pixels for every frame?

The text doesn't change nearly as many times per second as the visual does. If the burnin pixels and/or text were somehow stored in a third buffer (perhaps using an intermediate pixel value as the value for transparancy), and just the buffer-overlay-onto-background operation happened every frame, then you'd only need to rewrite the buffer when the foreground layer changed (say, when the user presses a button, or when the time index counter rolls over and you draw a time, etc.).

This means the burnin code would eat a lot less CPU. It would still make a stutter when it *did* run, it just wouldn't happen every frame any more.

Is it possible to mark a track and apply a value other than marked? Similar to how the song rating feature works,select mark and then choose 1,2,3 a,b,c or whatever to mean different things.Such as A=lyric errors, B=encoding errors,C=delete track

Also the ability to see the new mark meaning in emplode or jemplode

Hmm...You could try the following;

Create 2 copies of the text buffer.
Shift copy A 1 pixel right and add it pixelwise to B.
A down and add to B,
A Left, add to B.
A Left, add to B
A Up, add to B
A Up, add to B
A Right, add to B
A Right, add to B.

8 * 4096 = 32768 integer additions per screen (fast). Anything non-zero in B is to be burned, so that adds 4096 simple compares per screen.

Hmm. Quick gimp mock up, achieved by manually following the above process with multiple offset layers in 'lighten' mode.



Note that I inverted the original to show the contrast. In reality the mask ends up inverted against the background image and the original stays non-inverted. I suppose I could have imported a visual background and done it right, but I couldn't be bothered.