i just had an epiphany driving to work today. i usually use the "mark track" feature to get rid of a really bad song on my empeg. today, i was doing doing menu x3 random and encountered a song that i HAD to put in my favorites. now, i was just wishing that i could've marked it, but it might be mistaken as something i want to delete. multiple marking meanings has been talked about before. now here's the solution i thought of, which should be fairly easy to implement. it will give you two "lists", independent of one another. all you're gonna need is to modify the kernel a bit <glares at mlord> and have two drives.

the answer would be dynamic partition remapping. the /dev/hdc3 partition is unused. why not be able to 1) be able to make an exact copy of /dev/hda3 to it, then 2) let the kernel be able to toggle which dynamic partition to read/write to by redirection.

this is the functionality i see. in hijack, i see two menu options of 1) clone current dynamic partition and 2) toggle dynamic partition. so at the end of the day, open up emplode and look at all the marked files and do whatever you need to do with them... then use hijack to toggle the dynamic partition... and then reload emplode, and get the other marked track list. could be also useful for basically doubling the amount of saved settings that the player is capable of.

or an even more ambitious project is to use a spare program partition (hda2 or c2) and split it into 8 (sctratch=2mb, xtraprogs=16mb if i recall correctly) and be able to keep 9 different lists.

so, good idea bad idea?

That seems like quite a hack to gain some functionality, but not the best functionality. What I want is to hit the "mark" button multiple times, and have different strings come up, and then have the software store which string I settled on. Thus, I'd have "deleet, rerip, add to happy playlist, add to other playlist" and such. All of this is doable in hijack, except that you can't save FID/string ID pairs.

Mark at one point expressed intrest in finding a way for userland apps to write to the disk while in car mode. Though he probably has much better ideas, I suspect the general idea is another dynamic data partition (or file) that has checksumming for every write and reboot, and special calls to write to it without remounting the disks. I have no idea if he ever plans to implement this, and I think it's safe to say it's one thing that only Mark will attempt.

The other option in purseing multiple mark fuctionality outside of the player is to hijack the plays counter. In theory, we know the data format of the dynamic partition, and it's an int that most people don't care too much about. The userland program would have to write the value and checksum, and it would require a kernel hack to disable updating of the plays counter. A nice side benefit of this would be the ability to sort based on how tracks were marked.

Matthew

Why not hijack only a couple of bits from the plays counter - given its a 16 or 32 bit int, its unlikely the upper most bits are ever going to be used - there isn't enough time left in your life to play even the shortest track 2^31 times

Reason: minimum song length is 6 or so seconds or plays count won't update, so (2^31 * 6) / (3600 / 24 / 365.25) = number of years of continuous plays a 32 bit int play counter allows. A 16 bit number will only allow 54 or so hours of continous plays before it overflows though. 32 bit value is a lot of years [over 100] and NO one oculd play the same long that long - your Empeg would have died due to power supply failure, hard disk cable, malfunction or lack of lubrication in the hard disks bearings long before then.


Anyway, if we used a couple or even 3 or 4 bits from plays counter as a "mark type", then whenever you marked the track, the marked flag is set, AND those bits on the plays counter are set to the "mark type" you selected from the [Hijack implemented] pop-up mark menu that appears whenever it detects the mark button is pressed, before it lets the player see the mark button code, you have to respond to the pop-up Mark type menu - and if you go cancel, hijack eats the button code to stop the player getting it].

And Yes - Non-empeg folks can read and write the dynamic data partition - they're doing it now - check other posts on this BBS for code on how to do it.
All you'd do is AND the current Play counter with the "mark reason code" bit mask, to get the porevious reason code if there was, one then replace it with the new reason code and update the plays counter on disk. Done.

Now worst case, this trick will make your plays counter quite a large number once you mark a track [with a (non-std) Mark code, but I'm betting that the guys made the plays counter only show the bottom few e.g. 4? digits of the number, so to all intents and purposes your play counter would stay the same *on-screen*. Or worst case, you turn the plays counter off.

Now, back at home, you can attach to the Empeg and using Emplode or Jemplode, can see all the marked tracks AND the marked types in the huge play counts.

Wouldn't take too much magic in Jemplode to turn those play counts in Marked reason codes either so you could sort the display by Reason code value etc.

And Yes - Non-empeg folks can read and write the dynamic data partition - they're doing it now - check other posts on this BBS for code on how to do it.

Yeah, emphatic has code to read from it, but I'm a little tentative about doing any more with it than I already am, since 3.0 is in alpha stages, and peter has been made it very clear that the dynamic data partition's format will likely be changing quite drastically. Anyone who wants to do any mucking with it now (*especially* if it involves writing) might be better served waiting for 3.0. Which might end up having its own multiple marking function (dunno, haven't followed the 3.0 wish list very closely.)

I think that instead of multiple mark functionality, we need to see what we can do about multiple Mark functionality. I say we try for 6 Marks. One to go climbing, spend time with SWMBO, etc. One to build docks. One to do LED installs, and any other custom empeg hacks. And a team of 3 Marks to work on Hijack. Multiple Marks might be a tough feature to implement, but I hear those Raelians are making progress on cloning, and they live in Canada, so who knows, maybe we'll have Multiple Marks in time for v3.0 final.

might be better served waiting for 3.0

Also bear in mind that the first public release of v3.0 probably won't introduce all of the changes in this area. There'll be more to come after that.

In other words, for the first few rounds of v3.0 releases, the dynamic data partition layout is likely to be a moving target.

Multiple-mark functionality is on my wishlist, so it might get put in at some point. First, though, we need to thrash out what the new dynamic data partition is going to look like, before we start coding a bunch of stuff up.

Hmm. Me thinks that 8 Marks would be a better target.

Firstly, that allows 1 Mark to earn money and to get hassled by security every time he flies. (Which would happen even more since he admitted cutting his finger with a certain implement, but I think they're maxing him out already).
And since we'd then have 7 Marks, we'd somehow need to keep tabs on which Mark we would be talking to/about. The minimum amount of storage that could do that is 3 bits. So we might as well add another Mark to gain the most efficiency from those bits.

The minimum amount of storage that could do that is 3 bits.

Look -- one of me is already too much. Just ask my wife.

And since we'd then have 7 Marks, we'd somehow need to keep tabs on which Mark we would be talking to/about. The minimum amount of storage that could do that is 3 bits. So we might as well add another Mark to gain the most efficiency from those bits.

I'm glad someone else out there is as bored as I am today.

Edit: And, right on cue, Bitt arrives.