Hi there.

At the moment we basically have two play modes:
sequential and shuffle.

I would like to see the ability to add your own play modes.

This could be done in a fairly simple way, I imagine.

Consider this implementation proposal:

There is a directory somewhere (let's call it "playmodes")
where the savvy empeg user can put files.

The player UI looks in this directory and instead of offering
an menu option
shuffle -> on/off
it offers a menu option
playmode -> sequential / shuffle / file1 / file2 / file3 ...
where file1,2,3 are the files found in the playmode directory.

If one of the filex modes is selected, then when the player needs
to decide which tune to play next, it simply runs
"filex currentplaylist currenttune"
(here currentplaylist and currenttune are the fids of these objects).

filex is a program (or script or whatever) that outputs the
fid of the tune to play next.

The advantages of this method are:
- very low cost for empeg to implement, as you can rely on third party
developers (and the users) to implement the actual playmodes
- allows great flexibility
- no UI convenience penalty, if people don't want to use this feature

I would be really happy to have this feature as described above.

Of course, there are some things that would make it nicer, but
they're nowhere near as important as the bits above.

For instance
- I don't mind having to parse the database myself
in order to get the values of specific tags, but it would
be nice to have some API to do that for me.
- It would be nice to be able to script playmodes, rather than
having to compile a program, but this would need the player
to understand the script language. You probably wouldn't want to
bloat the player with that.

Doesn't anyone else think this would be extremely cool?

Richard.

What sort of playmode scripts did you have in mind?

Perhaps I have a really limited imagination, but it seems to me that anything other than shuffle play could be accomplished by a properly organized sequential playlist. What else were you thinking of?

If you're serious about coding up your own playmodes, aren't the Empeg kernel sources already available if you wanted to modify them? (I could be wrong about that?)



-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

Here's an example of a playmode somebody might write.

If we are currently playing tune1, which, according to the
tags in the database, was on album1, by artist1 of style1,
then there is a
30% chance the next track will be the next tune on album1
20% chance it will be another tune on album1
15% chance it will be a tune on another album by artist1
10% chance it will be by another artist, of style1
and (what am I left with?)
25% chance it will be completely random

These choices could all be within the current playlist.

Richard.

Re: coding our own playmodes at the moment

To my knowledge, currently empeg does not want to make the source
available to the player, because this is what they are good at, and
so this is how they make their money. That's fair enough.

However, that means that if someone wants to implement these playmodes, they
have to implement the whole player from the ground up. This means
(I think) the mp3 decoder, the UI, the visuals, the EQ behaviour (I know
this is dear to your heart, Tony), the smarts which make sure we
use the hard drive as little as possible (I think),
basically the whole shebang.

Any such implementation is almost certainly doomed to be a very
poor cousin to the existing player overall, even if it is
superior in one tiny facet (e.g. new playmodes).

Basically what I'm after is a way to extend the player functionality,
without taking anything away from it, or from the guys at empeg.
It would be cool to be able to add new menu items, or new
visuals, or new song selection routines to the existing stuff,
but to do that properly that would require assorted hooks in the player,
some library routines to make things easier and other things that
could be high cost to do right.

My proposal above was designed to be as easy as possible for empeg
to add, without threatening their intellectual property in any way.

It would be really hard to come up with a good playmode of similar
complexity to the one I detailed earlier, that could be generic
enough to distribute as part of the player. I don't even want
to think about the UI (good UI design is HARD).

The point is, I would never expect empeg to cater to my every little
whim by distributing umpteen different playmodes, but it would be
comparatively easy to let me do the catering.

Richard.

I love the "pluggable tune ordering" suggestion, and the idea could be extended to other portions of the Empeg interface, as well. It is one way that Empeg could easier leverage the benefits of an open source development model without jeopardizing their extremely valuable intellectual property.

My use for a custom tune-ordering algorithm? My wife and I have set up a playlist which we use when we are driving around together. It consists of 240 of her tracks, and 240 of my tracks. She and I have, unfortunately, highly divergent musical tastes. We use, of course, the shuffle algorithm on that playlist, and it works well. But we'd really like to be able to play one of mine (randomly selected), one of hers (randomly selected), and so on...

Corby
SN#320, 6-Gig Blue

Interesting. You've both given good examples of some pretty complex playlist behavior, above and beyond the concept of shuffle play. I hadn't thought of stuff like that before.

The obvious issue is that your suggestions are so unique and user-specific that you'd need some kind of end-user scripting or API interface to cover all the possible bases (just as you suggest). The irony is that it would just be simpler to add this kind of functionality directly to the playlist code rather than attempting to write a script languange or API interface for third parties.

As I understand it, though, the source code for the Empeg is either currently available or they intend to make it available soon. It is possible that I'm wrong about that. But I could swear that I read that they don't intend to keep the source code a secret. There are certain licensed elements that they don't own and therefore can't release (such as the XAudio stuff), but the basic playlist and playback code is supposed to eventually be open-source, if not already. I quote their web site:

People have asked about making the unit more open. At the start, we don't have the manpower to offer this sort of thing, but it is planned to release a setup which will allow logins, and be configured with gas and gcc for users to develop their own software on the unit. However, there will be no support for this - you have to be serious about it, and happy with Linux and software development in general for this to appeal to you. In the worst case, you can always reinstall the default software - the boot code is protected, so you shouldn't end up with a dead unit.

The unit's UI is written in Python, allowing Python-esque users to add features and giving great flexibility in the way the unit works.

Rjlov, your assertation that the player code "is where they make their money" doesn't sound quite accurate to me. As I see it, the unit's hardware design is what makes it the most unique. The code is great, don't get me wrong. No other consumer device even comes close to having a user interface at all, let alone having one as cool as the Empeg's. But I think that making their player code open source could only help their sales rather than hurt them. The ability for a hacker to do things like change the playlist behavior (in the ways you suggest) could only make the unit more popular.

Rob, Hugo, Mike... Clear this up please... What's the status of the Empeg source again?


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

..this has been discussed in detail before; Empeg feels that the hardware is easily replaceable, and that their main advantage is the code; therefore they have no plans to make the player software open sourced.
-mark

...proud to have one of the first Mark I units

Uh, we went through this whole "open source" debate earlier. Hugo and the others have made it pretty clear that they view themselves as a software company, not a hardware company.

As excited as I would be about the prospect of having all the Empeg source code published, they are making absolutely the right business decision to keep the source code to themselves, and license it under very controlled conditions. Otherwise, they would be extremely vulnerable to consumer electronics giants that use their code to make competing products cheaply and more efficiently.

Corby
SN#320, 6-Gig Blue

Oh.

I stand corrected.

Too bad.


-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

Hi there.

> The unit's UI is written in Python, allowing Python-esque users to add
> features and giving great flexibility in the way the unit works.

Yeah, I've been hanging out waiting for this. empeg have made noises
that they will eventually publish some sort of API for us to use.

I think we all realise that designing a good generic API that you
are happy publishing to everyone is not something you can do overnight.

That's why my original suggestion was for a quick and dirty (but still very useful)
adaptation that we can use until such time as a nice clean API becomes available.

Richard

Just out of interest, Hugo's comment on this subject is here

Geoff
---- -------
Reg No. 554, s/n 00064 - It's mine I tell you.... all mine :)

So now we all know empegs position on releasing their source code,
if we didn't know before.

Does anyone at empeg care to comment on the probability of implementing
something like my original suggestion at the start of this thread?
Yes? No? Maybe?

Please?

Richard.

Tony --

Follow the thread that Geoff mentions in the following post, read it all from first post to last -- it is absolutely one of the best threads on this whole bbs. There is a lot of thought-provoking opinion there.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

One major problem with implementing something like that (apart from memory constraints) is that the playlist is generated and saved when the playlist is selected. We need to look further ahead than the next tune in order for the caching to work properly, and to ensure that playlists carry on properly after power off/on again.

The memory issue is all to do with keeping the disk spun down - we mlock into memory so that unix doesn't try and access the disk when we're not expecting it.

Hugo

Thanks, Geoff and tanstaafl. I read through that thread. I now understand Hugo's stance on the issue, and I agree with him.

It seems as though I was confusing "open source" with "open API and developer tools". Empeg has plans to do the latter, but not the former. Personally, having the latter sounds just as good to me. The question that opened this thread (about adding on new play modes) could be accomplished via an API. I'm looking forward to the day that we see third-party add-ons for the Empeg Car.



-- Tony Fabris -- Empeg #144 --
Caution: Do not look into laser with remaining good eye.

> The memory issue is all to do with keeping the disk spun down - we mlock into > memory so that unix doesn't try and access the disk when we're not
> expecting it.

Yeah, for the implementation I described to work, you'd have to reduce the
amount of memory used for caching stuff. You'd probably also have to
impose limits on the size in memory of the "next track" executables.

> the playlist is generated and saved when the playlist is
> selected. We need to look further ahead than the next tune in order for the
> caching to work properly, and to ensure that playlists carry on properly after
> power off/on again.

The problems this generates for my suggested implementation include:
-1 A playmode could generate a playlist of infinite length
-2 It could take a significant amount of time to generate the internal playlist

Both of these can be solved in a reasonably straightforward manner, but I
can't know the complexity of their implementation within the current
player framework.

You only need to know the very first track to start playing music.
Calculation of the rest of the playlist can be done while playing.
This takes care of problem 2 above.

The problem of an infinite length playlist is a little trickier.
You could always implement a sort of sliding window around the current
track, but that would impose a limit on the number of "previous track"
commands you can execute. I wouldn't see this as a huge problem.

In this case, you would just use the "next track" executable to generate
your internal playlist of finite length. When you were approaching the
end of it, you could generate another internal playlist.

This addresses problem 1 above, but it's a bit of kludge, I guess.

Are there other problems I've missed?

Richard.