Okay, everyone keeps saying how they would like certain things on a per-song basis.

For example, a per-song EQ setting. Or a per-song visual setting. That sort of thing.

Well I just realized that Hijack could probably do these things with very little trouble. I know, easy for me to say, I don't have to code it. But hear me out...

Here's how I envision it working:

The comments field of the MP3 is filled out. For example, for per-song EQ, I would put the following string in the comments field:

Hijack:Set_My_EQ_to_5

Then, when this song comes along, assuming Hijack has notify:1 enabled for it, it knows the FID of the song, and can read the comment field data from that FID. If it sees the string "Hijack:" as the first chars of the Comment field, then:

It looks for a config.ini section named what your comment says, like this:

[Hijack]
Set_My_EQ_to_5=<<Button commands here to hold down equalizer button then press 5>>

Similar things can be done for a per-song visual.

Now, before you say "but it would be hard to fill out the comment tags of every song", have you done a "select all" in the "All Tracks" soup view lately? You could first add the "Set_My_EQ_to_1" command on every tune, then go in and set your EQs for the ones you want as an exception to the rule. Takes about 30 seconds to set all the tracks as a group, and not much longer to select albums you'd want to EQ differently.

But the beauty of this is its flexibility. You could do a whole lot with a feature like this, it seems to me. How else could something like this be used? Any ideas?

i like it.. now lets see if we can convince mark to like to too what do you say tony?

Mmm....

Then, if the OBD-II project gets going, when the Wallflowers "One Headlight" kicks in, a signal will be sent to the serial connector to the engine management system that would kill power to one (selectable?) headlight.... Mmmm....

Or, during Sammy Haggars "Can't Drive 55!", the cruise control would be activated to set your car to a (selectable?) speed over 55mph. Mmm...

Or, I'll stop now!

Good idea Tony!

Thinking about it some more:

What if you want to do more than one macro for a given song? That gets tricky. Do-able, but tricky to set up.

And also... most of this stuff (the EQ thing for instance) would make certain screens flash on each song change, which could get irritating.

I for one use the comments field on just about every song already. :-( So overloading this into the comments field isn't something I'd look forward to, even though I agree with the functionality request itself.

Calvin

Right. I agree that the "comments" field isn't the perfect place for such a feature.

Hmmm. The *1 files can be overloaded with new fields, right? These fields don't show up in the Empeg database, but if Hijack were able to read the corresponding *1 file each time a new song came up, then you could use these extra fields anyway.

We'd need a tool that allowed us to easily add new fields to the *1 files. Jemplode, perhaps?

Better!

Calvin

I've always thought there should be a number of 'user' fields in emplode and being a database, this shouldn't be hard to implement.

Could the macro function respond to existing fields? If you could specify macros to fire off for 'all', 'genre', 'source', 'artist', 'track' in that order, so the more specific macro is run that'd be pretty functional

[EQ macro]
Source="All"=Preset2 ;or whatever
Artist="Bad Religion"=Preset8
Track="Polka your eyes out"=Preset15 ;you get the idea

probably a clumsy layout for the config.ini.

I think the ultimate in flexibility would be if you prefix the comment with "#!" and it would treat the rest of the comment as a unix command and execute it. Then you can just write shell scripts to do whatever you want and Hijack doesn't have to have a whole new macro language.

You could use your shell script to do things like:
- swap .xml files to give the web interface a different look
- send any sequence of buttons via: echo "GET /?button=visual" | telnet 127.0.0.1 80
(guessing on syntax, not in hijack faq yet)
- send commands to other network devices in your car (for the true geek!)

How about on-the-fly compression? Perhaps the volume adjustment/compression routine could be enabled/disabled on a given file?

I don't like this for one simple reason, and it's that a bunch of button commands would be flying by and appearing on the player's UI. Per-song visuals would have to either hit your visual button a predefined (and possibly large) number of times, or navigate through the visuals menu which would look really really ugly. I mean, Hijack can figure out what visual you are currently in by looking at the state block, but it can't tell the player to go to a specific visual without either cycling throgh them or selecting them in the UI. Seeing the EQ screen fly by would be lame, as well.

The only non-bothersome solution is a full-blown API into the player, or a whole lot of fake IR codes that Hijack could send which would do special things like switch to specific EQ's or visuals without going into the UI.

I even get annoyed when the Info modes switch really quick with the "restore visuals" functionality.. I can't imagine tolerating the rapid-fire button presses involved in switching to specific visuals, etc.

[topic switch]

Actually, does anyone remember the original Settings patch? I seem to remember it fixed the restore visuals without rapidly switching info modes... Was that a Borislav invention or someone else? How was it written so that it didn't need to cycle through them?

How about if the first command is to blank the screen, then "do what it's gotta do" and then unblank the screen?

...These fields don't show up in the Empeg database ...

Uhmmm .... I'm not so sure that's true. Are the *1 files a consequence of database/playlists/tags or is it the otherway around? If the *1 files _are_ a consequence of database/playlists then anything overloaded into the *1 files would be lost on a sync (think 'Rebuilding database'). If database/playlists are a consequence of *1 files, then the overloaded stuff in *1 files would find it's way into database/playlists. I guessing here, but I think that there would need to be an addition to tags, so that an appropriate label for the new (overloaded) field would be available. Would overloading a new field in database/playlist/tags confuse the current player/emplode/emptool stuff? Hmmm ....
FWIW: I recently discovered that my player's database had duplicate field entries in the database file. In this case it was seemingly harmless, in that it was the codec field which was duplicated. To fix it, I just wrote a small program to read in the old database/playlists files and write out new database/playlist/*1 files (minus the duplicates, of course). I think i'll try adding a couple of fields to my db and see what the player does with them (hopefully nothing).

If I understand it correctly, the database is built from the *1 fid files, not the other way around. The database only uses the tags that it's hard-coded to use (Artist, Album, Year, etc.) and ignores any extra ones. The purpose of this (as I understand it) is so that as you up and downgrade to different versions of the player software without losing all of the *1 tag data. You can also create your own tag fields in emptool if you like (again, as I understand it).

Well, I just tested out this idea. I'll probably pay dearly for it (ie, reload everything) ...
but I just modified tags, and forcibly set new tags 'eq' and 'visual' to a value of '1'; which, at this point,
the value shouldn't matter, really. Sync'd with emptool, and; so far, no ill effects observed. No apparent easter eggs either.

2405 39b0 Intelligence\ Dream:
type = tune
artist = Synaesthesia
LastPlayed = 1014327290
length = 12902998
PlayCount = 98
SkippedCount = 0
title = Intelligence Dream
bitrate = vs181
codec = mp3
duration = 567229
genre = Rock
offset = 0
samplerate = 44100
source = Ephemeral
year = 1997
tracknr = 3
eq = 1
visual = 1

One noteworthy side effect of doing it this way, is that playlists can have eq and visual settings. For whatever that's worth. Of course, adding the tags, does absolutely nothing, but I think it demonstrates that some sort of extension can be done. Whether it's a hijack thing, or ...

The ability to extend the *1 tags was never a doubt in my mind.

The only reason I asked for the feature in "comments" was because I wanted to be able to set the tags up in Emplode. But if something easy like Jemplode were modified to add the custom tags, then I'd be into it.

I don't like this for one simple reason, and it's that a bunch of button commands would be flying by and appearing on the player's UI.

Just because you don't like it doesn't mean the rest of us should be deprived of a feature. If you don't like it, don't use it... it's optional.

I agree it's not the most elegant solution, but we don't have an API into the player so this would be one possible workaround.

There's a plugin for WinAMP that creates a web page with details on what's playing right now. With a simple shell script, you'd be able to do the same thing for the empeg. Then write a frame wrapper around a couple of those and you have a web page that shows what each mp3 player in your house is playing.

The possibilities are endless when you can script stuff per song!

Who's depriving anyone of a feature?

I was just commenting on the fact that there are issues with this kind of feature, and suggesting that it might be more beneficial to ask the Empeg team for an API, and let Mark work on other more useful features for Hijack. I see this feature as not nearly as useful as other things that could be put in, particularly in the player's interface to user applications. I'll fully admit that I'm biased to that because I'm developing stuff for the Empeg myself. But it's my right to chime in on the features people suggest and give my opinion. This is a discussion forum, right?

Your web page idea is already easily done.. If you're talking about a web page on your PC reading what's playing on the Empeg and showing the info, all that is available via Hijack right now. Browse to http://x.x.x.x/proc/empeg_notify on your player and do some Perl magic. No "per song scripting" necessary.

Don't write me off as a party pooper here, I would not cry my eyes out if Mark whipped this feature up, but I just thought it wasn't a huge win, and the real solution is a player API. That's all.