3.0 wishlist (wendy, info screen, codecs)

Since we're now definitively past 2.0 final, I thought it might be time to bring up new features and enhancements we'd like to see for 3.0.

My big ones are these (I've brought them up before, but I'll reiterate):

1. I'd like to see wendy filters filter out playlists that have been emptied of tracks by the filter. That is, if the entirety of Frankenchrist has been foltered out by the ``Granny in car'' filter, I'd like to see it remove the Frankenchrist playlist. In fact, if all of the Dead Kennedys sub-playlists are emptied (by the ``Mary Jo Kopechne in car'' filter, for example), I'd like to see it remove that, as well. To be more precise, if a playlist is a relative root node that has no leaf nodes that are tracks, then the root node should be removed from display.
2. Configurable info screen. I'd like to be able to configure the info screen to display whatever data I want to see. Configuring this on the empeg itself is probably not feasible, so setting it up at emplode-time would be fine. I've proposed a syntax before, but that's not a requirement by any means.
3. More codecs. I want to be able to play Ogg, and you've suggested that this is definitely a feature I'll see. But I might want to play flacs, too. Or something that hasn't been invented yet. It would be nice for there to be a documented plugin API so that the player can be extended by people other than you guys. It's not that I'm complaning about the development time you guys are taking. It has more to do with the fact that SonicBlue is going out of business and I don't want to see player development totally stall (whether it happens now or in the future). It's conceivable that we could write our own player if that were to happen, but I'd rather leverage the infrastructure you've already created.

Some of it's probably too late, as I'm sure you're well on your way with 3.0, but keep them in mind if it's not too late.

I've proposed a syntax before, but that's not a requirement by any means.

Where? If it's good, can I steal it for use with emphatic's own custom info mode functionality? I'm not in love with the existing syntax right now but couldn't think of anything better.

The reason I stated it that way was so that I wouldn't have to go find it.

Hang on.

Greetings!

I would like to see:

a) multilevel sorting in emplode. Example: sort by artist, then by album, then by track number.

b) API for coding / adding new visuals

c) built in backup / restore software

d) file chaining (store the FID of a file that will always be played after the current file, for use in songs that flow together, but you want to keep coded / ripped individually. Examples in use: Pink Floyd - Brain Damage -> Eclipse)

Here you go: Mutable Track Info

It's not the greatest thing ever, but I think it covers most eventualities for us.

Thanks. Neat approach. Not quite flexible enough for what emphatic is doing, but maybe with some modifications... hmm.

If I had any idea that this was a high probability feature for an early 3.0 alpha, I might not bother, though. The real place for custom info modes is the player, and not emphatic.

You know what I'd like to see? Some of the new features that are currently built into Hijack being moved to the official player software or to the stock kernel. Features that were added to Hijack because they weren't present in the player. Examples:

- Bass and Treble controls.

- LED button hack support.

- Preset volume level on boot (very recently added to Hijack, now I can't live without it).

- Disable filesystem check on sync.

- IR translations.

- And, of course, automatic gain control (voladj).

Actually, it might be better to keep most such things out of the player software. If we can (and have) done them already ourselves, it's better to keep them that way, simply because we'll retain the source and keep them up to date.

Features embedded in the closed-source player app are closed forever, and when the company finally chokes (3 days or 3 decades from now), we lose any ability to ever tweak them again.. Some might say, well just revert back to our old implementation then.. but by then, perhaps the old won't work anymore due to other changes..

You guys are bringing up some good ones.

1. I like Paul's suggestion of "multiple sorting" in emplode. The 2.00 final has something close to what I want (to sort by title with playlists always up top) but it does it by artist.

2. I'd like support for audio plug-ins such as crossfade or dynamic range compression (I'd be just as happy having these built in).

3. Moving HiJack stuff to the player software (would be nice having Bass and Treble next to Volume and Loudness) is a good idea too.

4. Auto-EQ (word is that development may have started).

I see your point.

Some of those things would be best implemented in the kernel anyway...

Although I have to say that Bass/Treble should be right there in the player where Balance/Fader are...

And if the guys are kind enough to let us configure the Bass and Treble settings via config.ini we should be good no?

Maybe a feature request (and this is beyond my technical know-how) would to allow something like HiJack seed itself into the player menus? So if you have HiJack installed, suddenly you get more opions in Settings? Or we could even (once HiJack is installed) have the audio related stuff appear with one tap of the volume knob?

I'm not sure if I'm really explaining myself right because I don't know what would be required to make the player software more "HiJack friendly". My first thought was to have HiJack completely replace the player's UI so that we could make it mimic the player software but just add features, but I'm guessing that would make the kernal pretty darn big!

To be more "Hijack friendly", we need the player software to:

(1) have virtual buttons for every menu selection on every menu
(2) have a way for Hijack to track the exact player state (menus and all).

-ml

Since this has become the official unofficial Wish List Thread for 3.0, I have two words: Cross fader. That's the one feature I want above all others.

And if the guys are kind enough to let us configure the Bass and Treble settings via config.ini we should be good no?

Not sure what you mean by this statement. Do you mean, let us configure the order and appearance of the bass/treble/balance/fader/beeps/loudness windows? Yeah, that would be nice.

I'd like to see a method of hooking some hijack functionality into the player menus, although I'd agree that there is a lot of hijack that it would make no sense to do so.
I'd suggest that if we implemented suitable ioctls for such functionality (eg Bass/Treble) then the empeg guys would be inclined to use them, leaving the underlying implementation within the kernel. Obviously this would mandate a hijack kernel to be included in the .upgrade packages, but this is something that I think should happen anyway.

Tony, not really. I was refering to the frequency and Q that is adjusted with the Bass and Treble (if for some reason we would want to change it later).

How's this for a wish: rearchitect the player software so that the framework can be opensource but all the menu items/decoders/etc are closed/proprietary. Then 3rd parties could build their own plugins for the framework, and so could SonicBlue. And if SonicBlue ever goes away the community would just have to rewrite the proprietary bits.

Won't happen of course since there's not enough of an upside for SB. But if no one asks, it definitely won't happen.

--pj

I was refering to the frequency and Q that is adjusted with the Bass and Treble (if for some reason we would want to change it later).

Ah, cool. I'd like that too. And while they're at it, they could allow us to adjust the parameters of the loudness control, too.

Use the source Luke.

The current bass/treble F/Q parameters are configurable. But it's difficult to do so since I never completely reverse engineered the DSP coefficients, just enough to make it work. But if you set EQ_DEBUG = 1 in empeg_mixer.c then when you adjust bands 9/10 in the players EQ (with bass/treble disabled) then you will see the coefficients on the serial port. IIRC, the first word will be the frequency and can be plugged straight into config.ini (Don't forget to prefix with '0x'). The second word is Q and dB combined. Make sure that dB = 0 when you take this reading. Then you want to take the high 16 bits of that word, postfix 00 to it, and plug it in to config.ini. eg if the word is 0x1234, you want to use 0x1200. config.ini labels are in hijack.c.

But hopefully this is all going away soon, to be replaced by the all singing and dancing DSP-based implementation. This should allow the f cutoff points to be adjustable, possibly also allowing the choice of 1st/2nd order filters. Who knows? First I have to iron out some bugs in my sinewave code.

c) built in backup / restore software


Wow! What a great idea. I wish I'd thought of that one!

tanstaafl.

I did look into building rsyncd into Hijack, but it's just too complex (and therefore LARGE).


-ml

(3) Bind new options and menus to the player menus, in a similar way that Hijack provides for its own menus at present. That is, ability for Hijack user-space applications to seamlessly extend the players' menu structure?

This is a change I'd like to see (I'm not running 2.0 yet, but I believe this wasn't change for the final release): if a playlist has "select x songs from playlist" and "repeat playlist" then the player should reselect new songs when the repeat occurs.

Something I've asked for before (and have seen others ask for as well): the ability to call up the last 5 playlists selected. It wouldn't have to be complicated enough to track the insert, deleted, etc. tweaks one has made to the running order, but simply remember which playlists were chosen (like holdding down the "down" button does now for the last playlist selected). I can't tell you the number of times I've wanted to call up a playlist I was listening to recently and had to go D, R, R, R, R, R, R, D, R, R, D (or some such “contra” like code) to get to it.

But if nothing else happens, crossfading would be the one feature I'd want.

In reply to:

---

b) API for coding / adding new visuals

---

I think this could make all sorts of things - like emphatic - more straightforward, as emphatic would not need to be an overlay, but just a source for info to feed to the visuals module.

Like it