Rob,

Would you be able to post the list of features which V1.1 will have? Even if it is only the things we have guessed already, it would be a great help. Sort of a pre-release teaser!

____________________
Murray 06000047

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

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)

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

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