Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Page 1 of 2 1 2 >
Topic Options
#228758 - 29/07/2004 01:40 [emphatic] Wish List
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Please post any new feature requests or general wishes for emphatic in this thread.
_________________________
- Tony C
my empeg stuff

Top
#228759 - 29/07/2004 04:43 Re: [emphatic] Wish List [Re: tonyc]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#228760 - 29/07/2004 17:53 Re: [emphatic] Wish List [Re: tfabris]
mcomb
pooh-bah

Registered: 31/08/1999
Posts: 1649
Loc: San Carlos, CA
Quote:
It just doesn't get any better.

Hmm, well I'd like to see emphatic use less CPU, scroll smoother (when overlaid on a visual), and start automatically rather than requiring you to select it from the hijack menu. Thats not to say it isn't pretty damn cool as is.

-Mike
_________________________
EmpMenuX - ext3 filesystem - Empeg iTunes integration

Top
#228761 - 29/07/2004 18:00 Re: [emphatic] Wish List [Re: mcomb]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
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.
_________________________
- Tony C
my empeg stuff

Top
#228762 - 29/07/2004 18:12 Re: [emphatic] Wish List [Re: mcomb]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
Quote:
scroll smoother
scroll more smoothly.

Sorry. I'm on a kick today for some reason.
_________________________
Bitt Faulk

Top
#228763 - 29/07/2004 18:53 Re: [emphatic] Wish List [Re: tonyc]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Quote:
Try turning off the "burnin" effect in the XML file. That uses a TON of CPU.


Yeah, but it looks SO COOL.

Speaking of which, if anyone has got access to a good fast algorithm for doing that trick (bitmap A overlaid atop bitmap B, draw a black outline around all non-transparent pixels in bitmap A), please share it.

When TonyC was developing it, we discussed the brute-force method he was using to do that trick and I was sure there had to be a faster way to get the job done that wouldn't require so many if/then tests. Unfortunately my feeble little brain couldn't come up with any alternatives, nor could I find an example to convince him that a faster algorithm must exist somewhere. But in my heart of hearts, I just KNOW there's gotta be a faster way to do it.

Tony, wanna post a brief description of your current method?
_________________________
Tony Fabris

Top
#228764 - 29/07/2004 19:21 Re: [emphatic] Wish List [Re: tfabris]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Quote:

Tony, wanna post a brief description of your current method?


Okay. I'm merging the foreground (text) with the background (player screen.) It's basically 4 nested for() loops, the innermost two of which can short-circuit if we decide that the current pixel we'll be working on needs to be "burned in" (set to black.)

The loops are, basically:

for each row in the text (foreground) bitmap
for each column in the text (foreground) bitmap
for (one column to the left, this column, one column to the right)
for (one row above, this row, one row below)

The innermost two make up 9 total iterations per pixel in the image, but we don't do anything with the middle pixel. Within these loops, the algorithm is basically "if any one of the eight surrounding pixels in the foreground is not black, make this pixel in the background black, and if we do that, short-circuit the rest of the loops." So best-case is 4096 full loop iterations, worst-case is 32,768 (4096 * 8.)

If anyone can think of a simpler way, by all means share it (and feel free to send a patch.)


Edited by tonyc (29/07/2004 19:23)
_________________________
- Tony C
my empeg stuff

Top
#228765 - 29/07/2004 19:29 Re: [emphatic] Wish List [Re: tonyc]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Relevant source code attached.


Attachments
227749-burnin.txt (260 downloads)

_________________________
- Tony C
my empeg stuff

Top
#228766 - 29/07/2004 20:14 Re: [emphatic] Wish List [Re: tonyc]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#228767 - 29/07/2004 20:52 Re: [emphatic] Wish List [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Quote:
As for starting automatically, I believe that belongs in the Hijack wish list, not mine.

Hijack v403: ;@MENUEXEC menu_label command args optional_ampersand



Edited by mlord (29/07/2004 20:52)

Top
#228768 - 29/07/2004 21:17 Re: [emphatic] Wish List [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Quote:
Quote:
As for starting automatically, I believe that belongs in the Hijack wish list, not mine.

Hijack v403: ;@MENUEXEC menu_label command args optional_ampersand



Cool. Is there any way to have the apps automatically foreground as if it was selected from the menu? That's kinda what I was looking for.
_________________________
- Tony C
my empeg stuff

Top
#228769 - 29/07/2004 22:34 Re: [emphatic] Wish List [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
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..

Top
#228770 - 29/07/2004 23:08 Hijack v405: new TAKEOVER ioctl for apps [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
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

Top
#228771 - 29/07/2004 23:11 Re: Hijack v406: bugfix for TAKEOVER ioctl [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Hijack v406 will be out Real Soon Now, fixing a slight logic error on the new TAKEOVER ioctl.

-ml

Top
#228772 - 29/07/2004 23:36 Re: Hijack v406: bugfix for TAKEOVER ioctl [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
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.
_________________________
- Tony C
my empeg stuff

Top
#228773 - 29/07/2004 23:41 Re: Hijack v406: bugfix for TAKEOVER ioctl [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
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


Edited by mlord (29/07/2004 23:54)

Top
#228774 - 29/07/2004 23:55 Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
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

Top
#228775 - 29/07/2004 23:58 Re: Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Okay. v407 is now up on the server.

-ml

Top
#228776 - 30/07/2004 00:13 Re: Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
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?
_________________________
- Tony C
my empeg stuff

Top
#228777 - 30/07/2004 00:21 Re: Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
I think I can fix TAKEOVER so that a WAITMENU(NULL) works correctly -- v408 shortly.

Top
#228778 - 30/07/2004 00:27 Hijack v408. [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Fixed.


Edited by mlord (30/07/2004 00:32)

Top
#228779 - 30/07/2004 00:33 Re: Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
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

_________________________
- Tony C
my empeg stuff

Top
#228780 - 30/07/2004 00:38 Re: [emphatic] Wish List [Re: tonyc]
mcomb
pooh-bah

Registered: 31/08/1999
Posts: 1649
Loc: San Carlos, CA
Quote:
Less CPU and smooth scrolling go hand in hand, don't they? How are those different issues?

In practice they may be, but I wasn't sure if the scrolling smoothness was strictly due to CPU load or some other limited resource (how quickly the screen can be refreshed or how quickly a non-realtime process can grab control of it as examples).

The complaint about CPU load was more in reference to how emphatic seems to slow down the player. Trying to skip a track with emphatic running (with burnin on at least) and visuals going causes a couple seconds of dropped audio on my player.

These may not be things that are possible to fix, but the thread title is "Wish List"

-Mike
_________________________
EmpMenuX - ext3 filesystem - Empeg iTunes integration

Top
#228781 - 30/07/2004 00:48 Re: Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: tonyc]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Just do a WAITMENU(NULL) before the first WAITMENU(non-NULL).

-ml

Top
#228782 - 30/07/2004 01:13 Re: Hijack v407: EMPEG_HIJACK_WAIT_FOR_PLAYER [Re: mlord]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Quote:
Just do a WAITMENU(NULL) before the first WAITMENU(non-NULL).

-ml


Perfect! As if it needed restating, you are the man.
_________________________
- Tony C
my empeg stuff

Top
#228783 - 30/07/2004 20:56 Re: [emphatic] Wish List [Re: tonyc]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA

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.
_________________________
Tony Fabris

Top
#228784 - 30/07/2004 21:07 Re: [emphatic] Wish List [Re: tonyc]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#228785 - 02/08/2004 01:11 Re: [emphatic] Wish List [Re: tonyc]
newguy1
enthusiast

Registered: 26/01/2002
Posts: 278
Loc: Massachusetts,USA
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
_________________________
MIKE 80Gb RIO

Top
#228786 - 02/08/2004 01:58 Re: [emphatic] Wish List [Re: newguy1]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Quote:
Is it possible to mark a track and apply a value other than marked?

Yes. Well, sort of. There's only one bit set aside for "marked" in the dyndata partition, but I could write to another unused byte there and interpret the value for different marked flags.
Quote:
Also the ability to see the new mark meaning in emplode or jemplode

This is the problem, and what kept me from implementing multiple mark flags when I first thought of your idea. I have no way to get these special mark flags over to emplode or jEmplode. I think it'd require a change to the empeg sync protocol to get it over there... So wouldn't be very useful to just have them on the empeg.
_________________________
- Tony C
my empeg stuff

Top
#228787 - 02/08/2004 04:19 Re: [emphatic] Wish List [Re: tonyc]
genixia
Carpal Tunnel

Registered: 08/02/2002
Posts: 3411
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.


Attachments
228040-burn_demo.png (254 downloads)



Edited by genixia (02/08/2004 05:22)
_________________________
Mk2a 60GB Blue. Serial 030102962 sig.mp3: File Format not Valid.

Top
Page 1 of 2 1 2 >