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

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

Heh, I love this board...

Has anyone worked out the mean number of posts required for a thread to go off-topic? .


Roger - not necessarily speaking for empeg

Has anyone worked out the mean number of posts required for a thread to go off-topic?

Great, now you are going to start off on an in-depth (off-topic) discussion of what the difference between mean, average and median are...

__
Unit serial number 47 (was 330 in the queue)...

Arrrrgghhh!!!!

__
Unit serial number 47 (was 330 in the queue)...

About 2?

____________________
Murray 06000047

Has anyone worked out the mean number of posts required for a thread to go off-topic?

But have you ever noticed that the further off-topic a thread gets, the more entertaining it becomes? We have such a great bunch of people on this board that even the off-topic posts are worthwhile.

tanstaafl.

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

Of course, the 2038 problem doesn't account for the gobs of "date window" hacks done on legacy systems to get around the y2k mess.

Of course, the 2038 problem doesn't account for the gobs of "date window" hacks done on legacy systems to get around the y2k mess.

Good point. And those would be worse than y2k since they'll happen at unpredictable times so nobody will be prepared. Fun.

I seem to remember somebody trying to patent the "date window" hack. Pity that's most likely unenforcable, otherwise it'll be a neat way to use a screwed up legal system to prevent people from patching bad software with even worse kludges.

Borislav

No because before we find that out the offtopic list go offtopic again



Mark
wait for mk III with a USB Host/slave
(USB->GPS)(USB->Bluetooth)(USB->You name it)

Back on topic...

what about a time remaining feature ??
Or am I blind and missed it in this thread?

what about a time remaining feature ? Or am I blind and missed it in this thread?

Hmm, Now I'm trying to remember whether that has been promised on the BBS or not. I know that all the necessary stuff has been added to the system to implement such a display (length of song is now stored in the database, new decoding engine accurately reports VBR time), but I can't remember whether or not they said a countdown timer would actually be in 1.1 or not.

___________
Tony Fabris

And behind closed doors, the debate rages on.....

I can remember seeing that feature on the empeg-day in amersfoort.

Frank van Gestel

Yep, that feature has been implemented. For tracks already on the player (at the time of upgrading to 1.1) it will be necessary to run a scanning routine to work out the track length - and this is going to take quite a while for a large database. Roger was looking into an option to update the tags on a subset of tracks each time you sync, so in time the whole database would be up to date. Tracks with old tags will play fine, but you won't be able to get the time remaining display.

Rob

Too cool. What kind of time requirement are we looking at for a database of 20gig? (its a nice round number)
And thanks for my extra docking sleds Rob, the last one arrived today. Now I can Empeg-ise my future car, and try to create a home dock with an old Compaq 466 chassis!

Thanks!

Roger was looking into an option to update the tags on a subset of tracks each time you sync

This will be cool. Even if you did it as a single message box in Emplode asking you if you wanted to update the entire database (yes/no), that would still be cool. I know that I'd definitely opt to do it all at once if I could (I'd want the countdown timer to be immediately available in all my songs right away).

___________
Tony Fabris