Got it?

Not in my personal setup (if I am in the car then music is playing and the empeg is my only music source), but I guess I can see why someone might want it to work that way. Anyway, I can think of a few cheasy ways to take a guess at what state the player is in on startup (screen scraping, system load, is audio being played), but I don't know if any of them would really be a good solution.

-Mike

Well, there is a precedent for screen-scraping, as that's how hijack knows if the player menu is active. But I suspect that if the player is in standby, the display buffer probably still has "stuff" in it, it's just that the VFD isn't getting juice. Someone will correct me if I'm wrong.

But I suspect that if the player is in standby, the display buffer probably still has "stuff" in it, it's just that the VFD isn't getting juice. Someone will correct me if I'm wrong.

You are correct, sir. You can prove this by putting the player in Standby mode while the Displayserver applet has the screen up. Some visuals will still animate when the player is in standby. Kind of interesting, really.

(I haven't actually done this trick since 1.03, though, not sure if it still works.)

I think the issue here is not so much detecting standby, but rather deciding how to handle it in the context of "init keypresses".

Obviously (to me) is that a lot of us will want it to be handled differently than a "non standby" powerup state.

The other potential glitch was that the player may resume playing music before the "init keypresses" are played, but that probably won't be too big of a deal for most purposes.. or will it?

If we can figure out how we want it to behave under these circumstances, then the coding is trivial.

Cheers

The other potential glitch was that the player may resume playing music before the "init keypresses" are played, but that probably won't be too big of a deal for most purposes.. or will it?

Yeah but I think that some of these issues could be worked around... IIRC, when the player comes up, it does state_read() or somesuch which tells it whether the player was in pause or play status, what source was selected, etc... So the state_read() could just be fudged to whatever we want (play or pause, in tuner, aux, player...) So if you wanted it to start paused, you should be able to do so. That also takes care of having to send a bunch of buttons to select certain sources... Right?

For Mark or anyone who's interested, I'm attaching the results of some reverse engineering I've done which shows what I believe to be the meanings of some of the bits in empeg_state.

The Y axis denotes the hex offset from the flash base address, the X axis denotes the bit position within that byte. Because some settings go across byte boundaries, the diagram is color-coded.

Some details...

The bit labelled "shuf" is always 1 when any shuffle mode is active, and there seem to be various other bits and bytes which change based on the custom shuffle modes. I couldn't get a handle on those.. But when shuffle is off, the "shuf" bit (Offset 0x0F, bit 3) is 0, when any shuffle mode is active, that bit is 1.

Bytes 24 and 25 constitute a 16-bit sequential index into the current running order on the player. I hope to eventually use this index to grab the current FID number somehow.

Bytes 29 and 2A constitute a 16-bit number which represents the position within the current track. This might be the number of MP3 frames, or some number of milliseconds or something like that, not sure.

Numbers like balance and fader are 0 if they're in the center, negative if they're (right | rear), positive if they're (left, front). So if your balance setting is one "tick" to the left, the value in this byte is 0000001. If the balance is one tick to the right, it's 11111111.


Why did I go through all this? Well, using this information, the kernel could...
... set the volume (home, car, or both) to a predefined level on player startup, a feature that's been asked for elsewhere on the BBS
... tell the player to always (or never) boot into standby, regardless of the last state
... choose a predefined visualization, regardless of the last one selected
... choose a predefined info mode, regardless of the last one selected
... choose a predefined timecode setting

etc. etc. etc. Those are the most interesting applications I've thought of so far.

There are a LOT of bits that aren't shown, because I have no idea what they represent. The only ones I was able to find were settings I could easily change. Like, there are probably a lot of tuner-related settings that I couldn't do because I don't have a laptop to be connecting to my Empeg while it's in my car.

Anyway, I figured I'd share the fruits of my labor here. Hopefully this will aid in improvements to Hijack, and a better understanding of what info we can get from the player.

I think the issue here is not so much detecting standby, but rather deciding how to handle it in the context of "init keypresses"

OK, so if you think detecting it is doable than the obvious answer is to provide two init sequences. One for normal powerups and one for standby powerupps.

The other potential glitch was that the player may resume playing music before the "init keypresses" are played, but that probably won't be too big of a deal for most purposes.. or will it?

Again, it sounds like there are no options here. The init sequence may not happen before the player begins playing. Anybody who wants to use an init sequence will have to deal with this possibility. Unless there is a way to block the player from playing the first file? Could you block the player's read() of the state info or the first FID until after it accepts the IR presses? Sounds kind of far fetched.

-Mike

set the volume (home, car, or both) to a predefined level on player startup, a feature that's been asked for elsewhere on the BBS

Rock.

Mark Lord, you reading this? (He says, rubbing the lamp...)

See if you can figure out which bit stands for "paused", as well. I need that for something.

Thanks

>OK, so if you think detecting it is doable than the obvious answer is to provide
>two init sequences. One for normal powerups and one for standby powerupps.

Maybe. That's the simplistic approach, for sure.
Does anyone else care or have an opinion on this?

For example, the keypress macros could be enhanced to allow "standby" modifiers..

-ml

Could you please combine your notes (empeg_state area) and diagram into a single file, so we don't lose track of information?

And the volume parameter: is it a 0..100 percentage, or what?

Some of the other areas are probably for equalizer settings (all of those custom eq sets..).

Cheers

-ml

Yah, I had written down the pause bit too but forgot to include it in my diagram. Pause is right next to standby, offset 0x0C, bit 1.

I thought the EQ settings themselves were stored on the dynamic data partition, and just the identifier of the selected one was in empeg_state. I could be wrong. I might play with EQ settings and see if I can find those. As for the format of the data, like volume and such, I haven't had a chance to investigate that properly.

I do have all this stuff as an Excel file, but it's messy. I would hope this would eventually end up on the programming section of riocar.org, but I don't know how to go about getting it posted there. I wanna wait until we find out more about some of the other bits and bytes.

So do you think my approach towards startup settings would work? I was just throwing the idea out, I wasn't sure if there were any gotchas which would keep it from working...

Yeah, we might be able to alter startup settings using this approach.

I just don't remember (at the moment) whether the config.ini file can be read early enough to replace some of the startup settings before the player reads them, that's all.

Would you like a hijack menu item to display the save area contents?
I wrote it for myself a couple of days ago, and tossed it again afterwards, since I didn't think anyone would need it.

Cheers

Well what I did to reverse-engineer the settings was just a bunch of printk()'s of the hex and binary values in the state_write() function. Yeah, I think it'd be nice to have the ability to read it off the display so I can maybe get a read on what the in-car (tuner-related) settings are. It'd be nice if we could figure out what all the bits mean just for completeness. I guess you wouldn't have room on the display for binary, just hex, but that's okay. What I actually did in my kernel was write it so that if the value in a particular byte changed, it was highlighted (in ANSI color) so I could easily see which bytes were changing in between writes. If it's trivial, maybe doing the same for the VFD readout would be nice.

I just don't remember (at the moment) whether the config.ini file can be read early enough to replace some of the startup settings before the player reads them, that's all.

Well, sure you can. Think about it: Starting up the player software is one of the last things that happens during boot up. Right?

Okay, Hijack v78 includes a dynamic display of the Flash Savearea, with highlighting.

-ml

>Starting up the player software is one of the last things that happens during boot up.

Yes, but so is the reading of config.ini. For various good/bad reasons, Hijack cannot read config.ini until after the player starts up and reads config.ini, so it's just a question of which happens first: player reads flash, or hijack reads config.ini.

If things are not presently in the correct order, then a fair bit of fiddling may be needed to read config.ini earlier.

Easy enough to figure out which happens first, but it just needs doing, that's all.

Cheers

-ml

Great but has anyone seen why my long presses aren't working with my pioneer steering wheel remote

>has anyone seen why my long presses aren't working with my pioneer steering wheel remote

Care to be a little more specific about it?

Thanks

i posted a section from my int script thingy and i cannot get long presses to work with version 73

ir_translate]
00AD520A=0020DF13 ; volume up
00AD520B=0020DF17 ; volume down
00AD520C=00000008 ; Knob press/ATT
00AD5212=0020DF14 ; info/Band
00AD521A.LM=0020DF07 ; tuner/ long player source
00AD521A.LT=0020DF03 ; player/ long tuner source
00AD512A=0020DF14
00AD5240=0020DF0C ; up/cancel
00AD5242=0020DF10 ; left/left
00AD5243=0020DF11 ; right/right
00AD5241=0020DF12 ; down/menu
00AF5067=0020DF0D ; func/shuffle
00AD520D=0020DF02 ; audio/source

If you can see an goof ups

> i cannot get long presses to work with version 73
> 00AD521A.LM=0020DF07 ; tuner/ long player source
> 00AD521A.LT=0020DF03 ; player/ long tuner source

Does that particular button support long presses in hardware?

To answer, go into the Button Codes Display,
then press-and-hold the button.

If you see a code that begins with an '8' (80AD521A),
then that particular button is not suitably endowed.

-ml

AH me thinks i relise where i went wrong i thought that a long press of one button on the pioneer remote could be mapped to produce a short press of an original button on the rio remote.

I see now my Boo Boo as i thought this was to make up for the fact that most remotes don't have as many buttons as the rio remotes.

Any chance of us getting a way of doing this

AH me thinks i relise where i went wrong i thought that a long press of one button on the pioneer remote could be mapped to produce a short press of an original button on the rio remote.

Sure you can. A long press on the Pioneer can be mapped to a short press on the Rio. However there is one button on my Pioneer (CD-SR77 steering wheel remote) that doesn't play nice, I think it's the "Func" button towards the bottom. It sends very odd codes. I use the "Audio" button (next to Func) as my source button and it works fine.

I haven't tested out using the "SRC" button as the source button, but I do know it supports long presses. I use press and hold of my SRC button to toggle standby and it works okay. I posted my config.ini awhile back in this forum.

Can't see it any chance of you posting the whole bit so i can work it out as computers ain't my strong point

> 00AD521A.LM=0020DF07 ; tuner/ long player source
> 00AD521A.LT=0020DF03 ; player/ long tuner source
> 00AD512A=0020DF14
>If you can see an goof ups

Are you sure about that "00AD512A" on the third line above?
Or maybe the "00AD521A" should have been "00AD512A" instead?

Anybody got a list of the regular Pioneer remote codes?

He mark is it possible to add commands in your userland apps .

I give explanations :

i had a problem when tried to rz an anim file on my MKII .

Before to upload i used the command rw rwm.

But the transfer crashed with no ro rom command .

I'd like to ask if before to execute the command Reboot player we could program (hard coded or in config.ini file) some command like ro, rom by example.

thanks for the help here is what i came up with as my memory ain't good enough to remeber what all the buttons do but i might be adventureus and get the searching working through the steering wheel remote

[ir_translate]

af5067=ffffff
80af5067=ffffff ; ignore bogus codes from func button

ad520a.L=20df12,20df10,20df10,20df10,20df10,20df12,20df12 ; dimmer

ad521a.LM=20df07 ; player mode long press source = tuner
ad521a.LT=20df03 ; tuner mode long press source = source
ad520b.L=20df16.L ; long press vol- = hush
ad520d.L=20df01 ; long press audio = 2 tweak artist
ad5212.L=20df00 ; long press band = 1 time

ad520a=20df13 ; vol up = vol up
ad520b=20df17 ; vol down = vol down
ad520c=8 ; ATT = knob press
ad5212=20df14 ; band = info cycle
ad521a=20df15 ; source = visual cycle
ad5240=20df0c ; up = cancel
ad5242=20df10 ; left = left
ad5243=20df11 ; right = right
ad5241=20df12 ; down = menu
ad5219=20df0d ; func = shuffle toggle
ad520d=20df02 ; audio = tweak source

And mark here is attached in a easy format (i hope) and right this time

Thanks Tony.. I've now snaffled your Pioneer translates for my web pages.

-ml

>I'd like to ask if before to execute the command Reboot player
>we could program (hard coded or in config.ini file)
>some command like ro, rom by example.

Yeah, that would be useful.
I hope to add it sometime, perhaps over the holidays.

I'm kinda tied up this week with a (Linux) contract, but perhaps I'll take my laptop along on the weeklong visit to the in-laws afterwards..

Cheers