I was wondering if it is possible to program hijack to recognize a signal from the mute line causing a switch to aux. (for cell phones, onstar etc.)?

Yes, it's possible, but the Empeg player software already "knows" how to mute from that input.. what are you proposing it do differently, and why?

Cheers

Thanks for the response mlord. Sorry I didn't make it clear. Instead of simply muting the unit I would like the unit to automatically switch to aux. mode when a signal is sent to the mute wire. Then one could send signals from onstar, cell phones etc. thru the aux. inputs. In otherwords a signal from a cell phone or onstar convertor box etc. would instead of muting the empeg would switch it to aux., allowing the phone or other device to automatically play thru the empeg-amp-speakers...

Ditto on this. I'd love to have a speakerphone for the car that when the mute line goes on, switches to aux in and engages the microphone :-D

Calvin

Maybe a way to handle this would be to have Mark's kernel be able to trap and report a 'mute input signal present' as a fake 'button code', that way we would then map it using the IR maps so that the user can decide what happens.

e.g. if I want to pause the current source then switch to the Aux in channel I can do that [and unmute that output].

Some other folks might just want to switch channels with no muting and someone else might want to switch the Preset # X on the Tuner module.

If its done via the IR maps then everyone can have it done to there liking.

the only thing is:

1. Can we map the Mute input signal to a fake button [and of course map the fake button press into a mute signal input player software in case someone needs to be able to fake the 'Mute input' via a IR remote [or eventually (nudge,nudge) a Sony Stalk Controller] button code.

2. Can we stop the mute input getting to the player software unless we want it to?

3. Does Mark have the time and inclination to put this functionality into the kernel?

Yes, all of this is possible for the MUTE signal.

It is easily intercepted in empeg_power.c, and we could inject a button code for it if we want.

Cheers

That would be soooooo nice.

:-D Please please? :-D

I could attach a *real* physical button to this line?? WHOO HOO!!!!! :-D Mark, can you make it so we can "program" this button? Assign functionality??? Like "Next Visual" -- then i can mount the button that triggers the mute line to flip visuals. maybe put the button on the passenger side...

Or maybe, the button can be used as a "Shift" button to multiply functionality for the existing buttons?

Wow, or maybe I can hook up the door-opened switches to it, so the music will mute when the door opens..

Or maybe hook it up to detect when the convertible top is up or down, and adjust loudness settings to compensate.......

OR... OR!! oh gosh, so many possibilities. ;-D

Calvin

Ok, thats useful to know Mark.

I guess then we need to get some feedback from rtundo & enternalsun if a hack like this [with some IR mapping in config.ini] would answer their requirements for this idea.

Personally I think it will answer most potential users requirements in a flexible and user customisable way.

It would be good if the fake button code for 'mute input' was 2 way - i.e. if we receive this code it means that the mute input was triggered [and was then not passed to the player].

If we 'send' this fake button code (via the ir trans feature of config.ini) then it means that the mute input signal needs to be passed to the player software [as happens now].

I don't know if the polarity of the mute signal (what you set in emplode for whether 0v means mute of +12V means mute) is handled by the player itself or by the empeg_power.c code.

Once we ge the Sony Stalk stuff in the IR trans so its mappable ala IR codes are now, then users could map a button on their remotes or Sony stalks to 'Cell phone input'if they wish, so when the car-phone rings the empeg switches to the cellphone input automatically.

If we want to manually trigger it ourselves [e.g. for dialling out?] from a button we can do that too.

And if I want Button X to do this and someone wants button Y then thats no problem either.

Okay, already implemented and released: v128 (an hour ago, but the BBS crashed in the interim..).

[hijack]
extmute_on=xxxxxxxx
extmute_offf=yyyyyyyy


[ir_translate]
xxxxxxxx.H=ppppppppp
yyyyyyyy.H=wwwwwwwww
xxxxxxxx=zzzzzzzzz,qqqqqqqqq,tttttttt
yyyyyyyy=wwwwwwww.L,llllllll

If you don't want the mute being sent to the player software, just disable it with the checkbox in Emplode (or edit config.ini).

If you DO want the mute sent under some conditions, just include a MUTE button in the ir_translation. You can also use the .S (shift) state to "remember" a mode setting..

-ml

It would be good if the fake button code for 'mute input' was 2 way

I would propose having two buttons, one for mute on and one for mute off. If you want it to only do it when pressed, then only 'program' the mute on. It would also allow you to more easily use contact switches that break the connection when pressed.

I was going to post my post an hour ago but I got distracted.


I have a secondary request.

With all this wonderful IR hackery available to us now the use of button codes makes it hard to remember what hex string does what.

So, how about allowing symbolic button names in the Ir translation?
I would envisage that you can define symbolic button name and assign its button code somehwere in config.ini.
This table of symbolic names is read in and remembered.
[e.g.]

[Symbolicnames]

MUTEON=xxxxxx

MUTEOFF=yyyyyy

EMPEGPAUSE=zzzzzz

EMPEGTUNER=ttttttt

EMPEGPLAYER=pppppp

MYREMOTETUNER=mmmmmmm

MYREMOTEPLAYER=nnnnnnnnn

ENDOFCOMMAND=ffffffff

In the IR mappings section we can then say

MYREMOTETUNER=EMPEGTUNER

MYREMOTEPLAYER=EMPEGPLAYER,dddddd,EMDOFCOMMAND

PAUSE.L=MUTEON

PAUSE.CL=vkgkgkg

This makes maps (a) very much more readable and
(b) allows me to redefine what external command causes a thing to happen without having to change everything.

Only the symbolic IR code value needs to change, the rest of the map stays constant.

Symbolic button names cannot have fullstops or other 'special' characters in them [unless your parser is easily able to handle it]

So for instance this would would not be allowed:

[symbolicnames]
LONGTUNER=xxxxx.L

[irmappings]

LONGTUNER.C=EMPEGTUNER.L

As it would be adding a '.C' modifier to the '.L' modifier already active against that button due to the symbolic value.

During the 'evaluation' of the IR commands [probably during the initial parsing of the config.ini, you replace each symbolic keyname with its symbolic value - then proceed to work with the maps as now.
Maps that reference symbolic keys not present could have a message logged to the serial port (as now) and then any commands using that symbolic button name could either be ignored completely, or only the symbolic code (if a multiple code command) could be ignored.

Oh yes and can I have by 5pm today.

Thanks mlord (and number6), what can I say? Your the best. For me personally, this will l make my onstar and phone MUCH easier to use.