Heres a suggestion I posted in a different thread but I think it deserves its own thread to try and promote some discusion.
If you have read this suggestion earlier then ignore this one.
But for others, see if this makes any sense.

With all this wonderful IR hackery available to us now the use of (hexidecimal) button codes makes it hard to remember what hex string does what function and/or means what button on the IR remote or on the 'Player' itself.

So, how about this idea:
Allow symbolic button names in the Ir translation (as well as existing hex button codes as now)?

I would envisage that we allow users to define symbolic button names and assign its button code somewhere in config.ini.

This table of symbolic names is read in and remembered when config.ini is read.
However the information is used as a straight TOKEN replacement in the IR mapping section in the same file.

[i.e. the symbolic button codes are used much like #defines etc are used in C code and are then 'processed' out when the C program is compiled.

Suggest example of symbolic button codes:

[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,ENDOFCOMMAND
PAUSE.L=MUTEON
PAUSE.CL=vkgkgkg


I believe something like this will
makes ir (and soon, Stalk) maps:
(a) very much more readable and
(b) allows each user to redefine what external command/button causes a thing to happen without having to change everything in the maps.

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

In order to make it easy for the Hijack kernel to parse and process these symbolic names I suggest that we impose some naming rules on the Symbolic button names
such as:
They 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 initial read of the IR commands [probably during the initial parsing of the config.ini], the Kernel replaces each symbolic keyname with its symbolic value as a once off exercise & then proceed to work with the maps as now.

It can then forget about the symbolic maps until next time the system is restarted as this information won't be needed.

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 whatever is easiest.

Symbolic keynames that are not used anywhere in any maps merely add length to the config.ini - but do server a useful documentation purpose if nothing else.

Any comments?

I believe something like this will makes ir (and soon, Stalk) maps: (a) very much more readable

As far as readablility, why not just use comments after your commands? Copied this from one of mark's posts:

[ir_translate]
000006.LC=b9461C,ffffffff ; Long bottom player switch to tuner
000006.LTC=b9461E,ffffffff ; Long bottom tuner switch to player

That way it's in plain english, not a couple words run together. JMO but it seems like a lot of work for something that people setup once and then leave.

Tom

Well.. it would let people publish a database of remote translation files containing the Empeg codes and their functions. You could then map those "Remote Functions" to the Empeg Function you want it to control however you like. Having a translation layer allows people to figure out where on the remote the code comes from without having to to the reverse engineering themselves, or playing around with the remote.

I would also point out that in that post, mark stated it should be:

[ir_translate] 

000006.LTC=b9461E,ffffffff ; Long bottom tuner switch to player

000006.LC=b9461C,ffffffff ; Long bottom player switch to tuner

You can make the same argument why does C support #define then - why not just use the constants as and when you see fit?
[This quite plainly is not how most C Programmers see things - from my experience some tend to extend #define to abstract things to almost absurd levels, thus making some code harder to read than if it wasn't done that way, but I digress...].

Even with comments a Symbolic IR translation map will be much easier to read than one done with the old Hex values and comments and as Yang pointed out it allows people to swap maps - even for different IR controllers without having to reverse engineer the previous persons work and then re-engineer it for their remote].

Potentially if I like button A on my Rio Remote to the X and you like button B to do X, then all I have to do is change what symbolic' Button 'X' is defined as (from A to B) and the maps will work as intended.

Of course this is a trivial example but the rationale is still valid.

>>I believe something like this will makes ir (and soon, Stalk) maps: >>(a) very much more readable

I agree that nice names would be very handy, especially if they were "built-in" -- they'd make ir_translate simpler to deal with.

But it's not that hard to deal with right now (comments make it much nicer than without comments), and kernel space is at a big premium (not everyone has a 16MB Mk2a player..).

So, easy as it would be to do, I'm not going to add code (or data) for it right now.

Instead, how about applying some skills to a web-based IR-Translation entry tool, that uses symbols, and generates/uploads an edited config.ini to the player? Nice user interfaces for static data generation are far better suited to an offline GUI than to the tight memory constraints within the player.

If this is done as a web-based app, using HTML/JavaScript/Java, then the pages and data can be stored and served from the player itself, without consuming any critical resources.

I'll go back into my corner, now..

Has anyone tried putting JEmplode onto an Empeg player, and accessing it via a web-browser? It's Java, so it might actually work..

???

JEmplode would require a JVM to run on and I don't know if there is a JVM available for the ARM platform for the Empeg - someone who knows could correct me.

Re: comments on Symbolic names and a 'offline' tool to manage config.ini - in theory it sounds like a nice idea - the problem is that any solution I create would be in VB for Windows only. Someone else will then likely do something else for Java [ala JEmplode] and someone else again may well come up with some command line tool to do it another way.
And suddenly we have 3 tools doing the same thing and without making the readability of config.ini 1 iota better.

Let me state right now - I fully understand how valuable Kernel memory is.

My suggestion is that the symbolic map table remembered only until the subsituations have been done on the real ir maps in a straight text match and replace type arrangement.

I assume the symbolic map is stored in a malloc'ed block (or whatever the kernel has for this) and then once the token replacements have been done, this block of information is free()'d and forgotten about til next boot.
It takes up no more memory once token substitution has occured than maps using raw Hex codes as now - but its a lot more human readable and therefore (a) less prone to mistakes and errors and (b) can easily be remapped.

That way the only cost is a small block of memory [8KB max] and ONLY during the initial first 1 off parse of the ir_map section in config.ini.

I don't think you need to put Built-ins (i.e. standard symbolic keynames) in the Kernel - they can be defined in the Symbolic names section in config.ini (& we could include a full list of them so folks can cut & paste the full list into their config.ini's if needed) and since only those symbolic names that are actual are reference in any map are ever used in a match & replace routine it doesn't matter, except for a small amount of CPU to read in and store for a short period the symbolic names and value pairs and some memory to store them until the match & replace routine is done.

Also note - I'm offering you a Sony Stalk control and the loan of a tuner if needed to complete the Stalk stuff as well - thats how badly I want this feature and the Stalk stuff.

It would be almost trivial to do a preprocessor for the config.ini in perl.. I think I'll try some stuff out tonight and post what I get. It'll be really non-intelligent though.. basicly syntax (as I predict right now) would be:

#[variable name]=[value][CR]

and any line containing [variable name] will have it replaced with [value], and those #lines are stripped.

Applets run on a JVM on the client. All the empeg would have to do is deliver the data that is the Java classfiles/bytecode. Of course, that would require that it work as an applet, which I doubt it would do for various reasons, but it might. Haven't tried. Just wanted to make sure other people didn't try based on your claim.

Looking at the code, it doesn't look like it's an applet, but they're not hard to modify to do so.

(1) The JVM is built-into your browser -- Java is for the client side (MacOS,Linux,BSD,Solaris,MSWin), not the server (Empeg). It's just that HTTP provides a very convenient way of always having the client available, in the same way that the VNC Java client works.

(2) I figure perhaps a KB of code to parse symbols.. pain for no (technical) gain. And the value is really limited without a built-in symbol table (which could be read in or mmap'd from disk, I suppose).

(3) If you (or somebody else) want to coordinate and arrange for a Stalk control to appear in my mailbox, then go for it. If one arrives, I'll look at getting it to work. Actually, I'd kinda like to extract the code for "previous visual" from it for use in regular-remote remappings.. along with all of the other codes, of course.

Cheers

Ok.. wrote a quick and dirty preprocessor for you number6..
#var=value

any instance of 'var' will be replaced with 'value' in non '#' prefixed lines, and only after the first '='.

Edit: using your example:

#MUTEON=xxxxxx

#MUTEOFF=yyyyyy

#EMPEGPAUSE=zzzzzz

#EMPEGTUNER=ttttttt

#EMPEGPLAYER=pppppp

#MYREMOTETUNER=mmmmmmm

#MYREMOTEPLAYER=nnnnnnnnn

#ENDOFCOMMAND=ffffffff



MYREMOTETUNER=EMPEGTUNER

MYREMOTEPLAYER=EMPEGPLAYER,dddddd,ENDOFCOMMAND

PAUSE.L=MUTEON

PAUSE.CL=vkgkgkg

would yield:

MYREMOTETUNER=ttttttt

MYREMOTEPLAYER=pppppp,dddddd,ffffffff

PAUSE.L=xxxxxx

PAUSE.CL=vkgkgkg