features 1.1

Would you be able to post the list of features which V1.1 will have?

Well, I think they've already said a bunch of the features on the BBS already. They probably don't want to leak any more information (it would spoil the surprise). But here's an idea. Let's use this thread for everyone to gather up and list all of the 1.1 features they remember seeing reported on the BBS already. (Alpha team members please note: I can think of at least one feature that we were told was planned for 1.1 that has not yet been mentioned on the BBS. Don't list things here unless you know for sure they were already reported on the BBS.)

Okay, I'll start:

- Shuffle functions moved to another thread so it doesn't pause when shuffling large playlists.
- New audio decoding engine, allowing proper FF/REW in VBR files.
- WMA file support.
- Bookmarking.
- Search by playlist.
- Additional "Insert" mode in searching (instead of just replace and append).
- New Emplode with searching support.
- Wendy Filter (the exact details of this feature are not yet known, but we have a basic idea).
- Weighted shuffle, allowing Mk2 owners to hear mostly songs they haven't heard in a while. Mk1 owners don't have a clock, but it'll keep track of the number of times a song has been played, so they can at least hear the songs that have been played a fewer number of times than the others (similar, but different).
- If you are shuffling the whole player, un-shuffling will drop you back into that song's album (provided you've set your playlists up correctly to allow this, with your artist/album trees first in the list).
- Solution for world peace, the end to disease and hunger, and the secret to immortality. (Oh, darn, that was the feature they didn't want us to leak. My bad.)

Anyone else remember anything besides these?

___________
Tony Fabris

Anyone else remember anything besides these?

- Dual balance, loudness and beeps personalities for in the car and at home.

Borislav

In reply to:

---

- If you are shuffling the whole player, un-shuffling will drop you back into that song's album (provided you've set your playlists up correctly to allow this, with your artist/album trees first in the list).

---

...I thought 1.01 already did this?
-mark

MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

I thought 1.01 already did this?

Nope. Try it out sometime. It's still hit-and-miss.

___________
Tony Fabris

-a comprehensible PIN system, involving either a PIN search in emplode or a list in emplode of which songs have which PIN. Also a correction for 2 songs with the same PIN (which correction they went with is unknown)

DiGNAN

...I actually use it all the time; I think the difference is that I only have (usually) 1 copy of any given song.. Actualy alot of times if I'm in shuffle mode and I hear a techno song that I like, I unshuffle it so that the mix continues - I've never had problems with that..
-mark

MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

There are numerous postings about new/improved visuals.

Walter
-------------------------------------
Reg:1934/Mk1:158-6Blue/Mk2:380-12Blue

We saw a lot of new, and also old-but-improved visuals at the empeg owner's meet in Amersfoort. Some of the new visuals are truly excellent. Since they have been publically demoed, I am sure Rob wouldn't mind me describing a few I can recall (which also reminds me - I still have to write the report for the day! Another job for this weekend):

- several clock visuals. Some are static, and one is coupled to the music to make it active.
- a visual where a large (downloadable!) bitmap image is "windowed" in the display area, and bounces around according to the violence of the track you're playing
- a couple of truly excellent "trippy" visuals
- many tweaked and tuned originals. The sensitivity of the graphics to music is greatly improved - a good tweak.

Note that, what we saw was pre-release, so what we saw is not guaranteed to be in any coming release.

Rob did point out that there was not likely to be a great deal of change to the visuals set - but before you start to get all disappointed and start moaning about it, don't forget - 1.1 is a release which has a great deal of change under the covers (statistics, new decoder, etc.) and the graphics will in fact be all new in spite of the fact they look the same. The reason for this is that Toby is laying the groundwork to make the graphics open, so there are in fact major underlying infrastructure changes in place that means the next following release will be the one to watch for. Watch this space!

One of the few remaining Mk1 owners... #00015

I think the difference is that I only have (usually) 1 copy of any given song.

Right, the problem only happens if you have more than one copy of a given song: One in the album playlist, and the others in "mood" playlists or some other kind of playlist. If you only have one copy of a given song, then unshuffling will always drop you back into that song's playlist and there's no issue.

___________
Tony Fabris

a visual where a large (downloadable!) bitmap image is "windowed" in the display area

Something tells me this next release will require that I make changes to my logo editor. Sigh...

___________
Tony Fabris

I believe it was mentioned that there would be a feature to "mark" a track (this is different from bookmarking), so that when you went back into Emplode you could pull up a list of "marked" tracks. This is so that if you find a track skips or was encoded poorly or for any other reason that you would want to remember to make some change to a specific track, you could do so later with ease instead of .. "hrmm... damn, what was that track that glitched....".

here's one of the treads on it, but i believe there were others...


|| loren.cox
|| 080000446

Edited by loren on 18/11/00 01:58 PM.

I don't know if this has been mentioned here yet, but I sent a request for it and they told me it's be in 1.1: optionally display the artist and track title for a few seconds at the start of each new song, even if text info is off.

Cool, just like Geiss

DiGNAN

Anyone know if the visualization/codec plugin API will be present in 1.1? I'm interested in starting to write new visuals!

Let's use this thread for everyone to gather up and list all of the 1.1 features they remember seeing reported on the BBS already.

.WAV file support

tanstaafl.



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

Yep, that's in there too - saw it at Amersfoord

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 6GB blue)

In reply to:

---

Mk1 owners don't have a clock, but it'll keep track of the number of times a song has been played, so they can at least hear the songs that have been played a fewer number of times than the others (similar, but different).

---

Theoriticially the MK1 could still keep track of the number of hours since the song was last herd though, since it does keep time when it's powered. And from my experiences with my MK1, the time started from where it was left off when it gets power back, and not reset.

In reply to:

---

Theoriticially the MK1 could still keep track of the number of hours since the song was last herd though, since it does keep time when it's powered. And from my experiences with my MK1, the time started from where it was left off when it gets power back, and not reset.

---

Technically, but I doubt they'd actually code that in:)
-mark

MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

I was thinking about this, and I thought of a way that would allow both player models to do this (know which songs were most recently played) without needing a clock.

The player could keep a permanent "counter" that simply incremented with each song played. This counter would be saved to the hard disk along with all the other bits of the player state. Each time a song was played, this counter would increment and add itself to the database entry for that song.

The weighted shuffle algorithm could then simply sort based on this counter value. In fact, the code for that would be simpler than trying to interpret a time/date value.

The counter wouldn't even have to be a very large integer. A 32-bit long integer should be more than enough, allowing the counter to reach 2,147,483,647 before the database would wrap around. Assuming a 5-minute average song, you can only play 10,5120 songs in a year if the player plays nonstop. By my math, it would take 20,428 years to roll the counter over.

Empeg guys, thoughts on this?

___________
Tony Fabris

Yeah thats already done. Theres a shuffle mode for least recent and another for least frequent.

Rob

The player could keep a permanent "counter" that simply incremented with each song played. (snip) The weighted shuffle algorithm could then simply sort based on this counter value.

This is already implemented, but it's not a great solution. Consider an empeg all of which you've heard about 100 times -- then synchronise a new song on. You'll hear that song 100 times before it bothers playing any of the others.

As another poster said, even though the Mark 1's "real time clock" isn't real time (the time is remembered when the power's off, but doesn't advance), it's still good enough for biasing random shuffle with. In fact, as it records the length of time the empeg's been switched on for, it's arguably better than wall time for biasing random shuffle with.

Peter

Technically, but I doubt they'd actually code that in:)

Was that a challenge I heard there?

Peter

In reply to:

---

Was that a challenge I heard there?

---

welp; challenges tend to quickly become x.x1 releases on here:)
-mark



MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

By the way, Rob, could you give us a rough ideas of the parameters for the LFP and LRP shuffles? Does a song that's been played twice have half the chance of a song that's been played once? Or is it that after a song has been played it's guaranteed not to be heard for N more songs/minutes? Is there a minimum size of playlist that will force these algorithms to play the same sequence of songs over and over again?

Curiosity is going to kill me one day, but I'll have fun in the meantime...

Save the whales. Feed the hungry. Free the mallocs.

I have no idea - no doubt Peter will enlighten us in the morning.

I do know that the routines still maintain a strong random factor.

Rob

A 32-bit long integer should be more than enough, allowing the counter to reach 2,147,483,647 before the database would wrap around. Assuming a 5-minute average song, you can only play 10,5120 songs in a year if the player plays nonstop. By my math, it would take 20,428 years to roll the counter over

Ah, Tony, you knew I couldn't leave this one alone, didn't you.

First, I think that a 32 bit integer would allow you 4,294,967,295 numbers (assuming we don't count zero as one of the set, that is...). At least, that's what 2^32 comes out to. 2,147,483,647 is 2^16. But maybe I don't understand integer mapping all that well, and a 32 bit integer really only gives you 2^16 numbers?

However, a much more serious problem is that you neglected to factor in the leap years. By my rough calculations, you would actually only get 20,415 years by setting your average year equal to 365.25 days. Of course, this does not take into account the leap year exceptions at 100 years, 400 years, and 1000 years, which would add about another half year to the total.

So, given the fact that we would get 14 fewer years than you calculated, do you think that a 32 bit integer would be enough? (That's 14 fewer because you rounded down from 20,428.8, should have rounded up to 20,429).

Of course, if the 32 bit integer really does give 4,294,967,295 numbers, then the whole question becomes moot, doesn't it?

tanstaafl.



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

First, I think that a 32 bit integer would allow you 4,294,967,295 numbers (assuming we don't count zero as one of the set, that is...). At least, that's what 2^32 comes out to. 2,147,483,647 is 2^16. But maybe I don't understand integer mapping all that well, and a 32 bit integer really only gives you 2^16 numbers?

Urm... 2^32 is 4,294,967,296; 2^16 is 65,536; 2,147,483,647 is 2^31 - 1. An unsigned 32-bit integer gives you 2^32 possible values (including 0), a signed 32-bit integer gives you 2^32 - 1 positive values. In this algorithm there is no reason to use a signed integer or not to use 0, so you get 2^32 possible values.

Of course, this does not take into account the leap year exceptions at 100 years, 400 years, and 1000 years

There is no exception at 1000 years.

If we are going to be pedantic...

Borislav

2^16 is 65,536

Oops, my mistake. I meant to say 2^31, not 2^16.

There is no exception at 1000 years.

Really? I thought there was.

[pause] Well, I just did a little bit of internet research, and you are right. [/pause]

I stand corrected, and thank you for that information!

If we are going to be pedantic...

One of the joys of my life!

tanstaafl.


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

I don't know how your wives put up with you guys. Yeesh! =]


|| loren.cox
|| 080000446

I don't know how your wives put up with you guys. Yeesh! =]

I haven't found one that can cope with me yet.

Borislav

First, I think that a 32 bit integer would allow you 4,294,967,295 numbers

Yes, if it's unsigned. Otherwise we lose one bit to indicate positive or negative. It's possible to use unsigned integers, but as a programmer you have to be careful to make sure that all your declarations are correct and that your function calls are designed to accept unsigned values. If you don't, you get strange bugs that come up and bite you in the arse later. For the purpose of my example, I thought it would be best to assume a signed integer because that was easier.

___________
Tony Fabris

This is already implemented, but it's not a great solution. Consider an empeg all of which you've heard about 100 times -- then synchronise a new song on. You'll hear that song 100 times before it bothers playing any of the others.

Perhaps I wasn't making myself clear. You're assuming that I was talking about a "number of times this song has been played" counter, which would indeed produce the undesired result you just cited. But that's not what I meant.

I meant a "what sequence have the songs been played in" counter. This would be a single, unique, static value that was global to the entire unit. Sort of like the odometer on your car. Each time a song was played, this "odometer" value would be incremented. Each song would get that odometer value recorded with it as soon as it was played. Every song on the unit would have a unique odometer value (once it had been played at least once). As soon as a song was played, all the other songs with lower odometer values would suddenly take a higher weight for the next shuffle. A newly-synched song would indeed come up first in the shuffle, but it would only play once before it was weighted to the back of the shuffle again.

Thinking in more detail about the implementation, you would probably have to seed the value of all new songs with the highest possible number. Either that or seed them with 0 and have the counter count down towards 0. Either way.

___________
Tony Fabris

In reply to:

---

I meant a "what sequence have the songs been played in" counter. This would be a single, unique, static value that was global to the entire unit. Sort of like the odometer on your car. Each time a song was played, this "odometer" value would be incremented. Each song would get that odometer value recorded with it as soon as it was played. Every song on the unit would have a unique odometer value (once it had been played at least once). As soon as a song was played, all the other songs with lower odometer values would suddenly take a higher weight for the next shuffle. A newly-synched song would indeed come up first in the shuffle, but it would only play once before it was weighted to the back of the shuffle again.

---

That's a very good idea tony; if for no other reason then the geekiness statistical value of it...
-mark

MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

I meant a "what sequence have the songs been played in" counter.

Ah, good thinking Batman, yes, that does make more sense. But as a way of implementing "least recently played" on Mark 1 it's no easier than using Mark 1's unreal-time clock.

Peter

But as a way of implementing "least recently played" on Mark 1 it's no easier than using Mark 1's unreal-time clock.

Ah, OK. Makes sense. So, are you planning on implementing the biased shuffle based on the Mark1's unreal-time clock?

___________
Tony Fabris

Ah, good thinking Batman, yes, that does make more sense. But as a way of implementing "least recently played" on Mark 1 it's no easier than using Mark 1's unreal-time clock.

Tony's algorithm does have the advantage that it won't stop working in 2038.

Borislav

Tony's algorithm does have the advantage that it won't stop working in 2038.

Heh, yeah, but mine has that "year 22,000" bug we'll have to worry about...

Damn, I'm glad I'll be retired by 2038. Y2K didn't scare me, but when the C library breaks in 2038, things are going to get ugly for IT folks.

___________
Tony Fabris

Anyone mind explaining that 2038 one to me? I haven't heard of it.

DiGNAN

Anyone mind explaining that 2038 one to me? I haven't heard of it.

If I recall correctly, that's when the ANSI C "date" function breaks.

It's the "real" Y2K bug, and it's going to require a lot of work to retrofit, a lot more than anything we saw going on last year.

___________
Tony Fabris

Anyone mind explaining that 2038 one to me? I haven't heard of it.

If I recall correctly, that's when the ANSI C "date" function breaks.

The UNIX time system call returns the time since the Epoch (00:00:00 UTC, January 1, 1970), measured in seconds. On 32-bit systems it uses a signed 32-bit integer type for the return value, this overflows in 2038.

It's the "real" Y2K bug, and it's going to require a lot of work to retrofit, a lot more than anything we saw going on last year.

We should be fine as long as everybody is using 64-bit systems by then (if it wasn't for wintel, we would be already).

Borislav

I always thought that changing time_t to a 64 bit number would have been a good thing to do at the same time that glibc2 was released. You pretty much had to recompile everything anyway! I thought it would be kind of cool to say in the leadup to 2000 that your system could handle dates up to the year 4 billion AD (roughly).

Does anyone know a good reason why this shouldn't have been done?

Richard.

I always thought that changing time_t to a 64 bit number would have been a good thing to do at the same time that glibc2 was released.

I don't own a copy of the C standard so I can't quote chapter and verse, but it goes roughly like this: time_t is an integral type and should therefore fit in a long or unsigned long. So if you make time_t 64 bit, you have to also make long 64 bit. And 64 bit arithmetic on 32 bit architectures is rather slow (gcc is especially bad at this). The new C standard adds long long and implementation-defined extended types so it wouldn't have that problem, but it'd be a while before that's widely implemented.

Borislav

and i just wanted this post to list the feature list in 1.1!

glad i didn't ask anything complex

____________________
Murray 06000047