JP1 Remotes • IrpMaster, program/library for IRP rendering, released

Page 1 of 4

IrpMaster, program/library for IRP rendering, released

Posted: Sat Aug 20, 2011 4:11 am

by Barf

This is the initial release of IrpMaster, somewhat arbitrarily called
version 0.1.0.

IrpMaster renders IR signals in the IRP notation, as described in the
IRP specification. With the exception of hierarchical repetitions
(which is not quite clear if it makes sense at all), the
implementation is believed to be complete. It is a replacement of the old
Makehex program, and much more.

The program is written in Java 6, and should thus run on every
platform that supports Java 6. Optionally, the DecodeIR shared library
is invoked on platforms that support it.

In the present form, it is a command line program, and an API, that
can be called from other programs. A future GUI can be relatively
easily written.

Documentation is found in the file IrpMaster.html, contained both in
the binary and the source distribution.

I am soliciting all sort of feedback, in particular on the possibility
of a common future IRP data base. Three possibilities are discussed in
the documentation.

I hope you will find IrpMaster useful.

Bengt aka Barf

Update 2012-05-27: Separate binary distribution has been eliminated, use the IrMaster binary distribution, for Windows users Setup.exe version instead. Source available on http://www.harctoolbox.org.

Update 2012-08-24: Version 0.2.1 released,see last post (presently!) in the thread.

Update 2012-11-25: Version 0.2.2 released,see last post (presently!) in the thread.

Update 2014-02-05: Version 1.0.0 released,see last post (presently!) in the thread.

Update 2014-06-20: Version 1.0.1 released,see last post (presently!) in the thread.

Posted: Sat Aug 20, 2011 8:46 am

by The Robman

Thanks for this Bengt, I'll be sure to post some feedback once I've had a chance to play with it.

Posted: Sun Aug 21, 2011 12:48 am

by 3FG

Windows users can invoke this from a batch file. Here is a sample that gives a Pronto Hex output in two ways.
foo.bar is the output file from a IRP specification, while foo2.bar is generated from the protocol name "apple" via the IrpProtocols.ini file. The IRP specification seems to require some augmentations to the standard IRP spec; these are described in IrpMaster.html

The quotation marks around a IRP specification are necessary, because "<" and "|" have meaning in a DOS or Windows command line.

Name the following text MyFile.bat (or anything else with a .bat extension.)

Code: Select all

java -jar IrpMaster.jar -p -o foo.bar   -i "{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,C:1,F:7,PairID:8,1,-78,(16,-4,1,-173)*) {C=1-(#F+#PairID)%2,S=135} [D:0..255=238,F:0..127,PairID:0..255]" PairID=34 D=238 F=12 
java -jar IrpMaster.jar -c irpprotocols.ini -p -o foo2.bar -n Apple PairID=34 D=238 F=12

Launch the .bat file by clicking on it or by typing the name into a Command Prompt window (Accessories\Command Prompt). The latter approach allow you to see error messages (if any).

Posted: Sun Aug 21, 2011 9:37 am

by The Robman

Could you post quotes of the contents of both foo.bar and foo2.bar please, just so we're all sure we're on the same page.

Posted: Sun Aug 21, 2011 10:24 am

by Barf

The Robman wrote:Could you post quotes of the contents of both foo.bar and foo2.bar please, just so we're all sure we're on the same page.

should both be identical:

Code: Select all

Device Code: 238 Function: 12, PairID=34
0000 006C 0022 0002 015B 00AD 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0699 015B 0057 0016 0EA3

also useful is the --decodeir option that checks the outcome with DecodeIR.

Posted: Sun Oct 02, 2011 1:15 pm

by Barf

Hey guys, what is this?

The IRP-Notation is one of the cornerstones of this project. Graham wrote a great specification, and there was quite some constructive discussion. Up until now, there have been no complete and open-sourced implementation, only the obsolete Makehex. And when I do it -- almost complete silence (except for some "abstractly encouraging" words from Rob). A recent thread more or less implicitly suggests that Makehex is all what is ever needed...

Anyone who cares? Are we working towards the same goal?

Looking for a GUI? Then say so, in another projec have one almost finished:

...and building one from scratch is no big deal either. But since noone asks for it...

Looking for a way to call from C? Have it almost finished, but since no-one seems to care...

Looking for documentation? It is included. API programming example? Included.

Looking for command line usage examples: Ok, here are some. (In all cases, the user types the first line (here starting with a $-sign, which is not to be typed in!).

Just generate a code in Pronto format (taking irp-definition from IrpProtocols.ini):

Code: Select all

$ java -jar dist/IrpMaster.jar  -c data/IrpProtocols.ini  -p  rc5 12 34
Device Code: 12 Function: 34
0000 0073 0000 000A 0020 0020 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0040 0040 0CC8

Generate an output file like Makehex, containing all rc5-codes in raw format

Code: Select all

$ java -jar dist/IrpMaster.jar  -c data/IrpProtocols.ini  -r  --out rc5.hex   rc5 "*" "*"

Recovering an IRP-Form from the data base:

Code: Select all

$ java -jar dist/IrpMaster.jar  -c data/IrpProtocols.ini  nec1         
{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78,(16,-4,1,-173)*) [D:0..255,S:0..255=255-D,F:0..255]

Trying an individual IRP-Form, first time deliberatly incorrect

Code: Select all

$ java -jar dist/IrpMaster.jar  -i "{36k,msb,889}<1,-1|-1,1>((1:1,~F:1:6,T:1,D:5,F:6,^114m)+T=1-T)[T@:0..1=0,D:0..31,F:0..127]" 12 34
line 1:56 mismatched input 'T' expecting ')'
ERROR: IRP parse error: 
{36k,msb,889}<1,-1|-1,1>((1:1,~F:1:6,T:1,D:5,F:6,^114m)+T=1-T)[T@:0..1=0,D:0..31,F:0..127]
                                                        ^

Note that the arrow marks the location of the syntax error.
Trying an individual IRP-Form, now correct, and send it to DecodeIR:

Code: Select all

java -jar dist/IrpMaster.jar  -i "{36k,msb,889}<1,-1|-1,1>((1:1,~F:1:6,T:1,D:5,F:6,^114m)+,T=1-T)[T@:0..1=0,D:0..31,F:0..127]" -p --decodeir 12 34
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Device Code: 12 Function: 34
0000 0073 0000 000A 0020 0020 0040 0020 0020 0040 0020 0020 0040 0020 0020 0040 0040 0020 0020 0020 0020 0040 0040 0CC8
DecodeIR result: protocol = RC5, device = 12, obc = 34, misc = T=0

Testing DecodeIR for a number of signals:

Code: Select all

java -jar dist/IrpMaster.jar  -c data/IrpProtocols.ini --decodeir  denon-k 0 "*" 4095
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: success
DecodeIR result: protocol = 48-NEC1, device = 84, subdevice = 50, obc = 0, misc = E=255

(the first 15 succeded, the last one not).

Causing DecodeIR to crash

Code: Select all

$ java -jar dist/IrpMaster.jar  -c data/IrpProtocols.ini --decodeir rc5x 31 0 0 1
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
DecodeIR result: #
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fe70709b1c7, pid=21631, tid=140630348285696
#
# JRE version: 6.0_20-b20
# Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.9.7
# Distribution: Dummy Product (x86_64), package suse-1.2.1-x86_64
# Problematic frame:
# C  [libDecodeIR.so.2.43+0xe1c7]  _ZN6Signal6tryGapEv+0x48d9
#
# An error report file with more information is saved as:
# /home/bengt/harc/IrpMaster/hs_err_pid21631.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted

Calling DecodeIR directly from a proto signal:

Code: Select all

$ java -jar dist/IrpMaster.jar  --decodeir --ccf 0000 0067 0000 0022 0168 00b4 0017 0017 0017 0017 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0044 0017 0044 0017 0044 0017 0017 0017 0044 0017 0017 0017 0044 0017 0017 0017 0017 0017 0017 0017 0044 0017 0044 0017 0044 0017 0017 0017 0017 0017 0017 0017 0044 0017 0044 0017 0017 0017 0017 0017 0017 0017 0044 0017 0044 0017 0044 0017 06c2
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
protocol = Pioneer, device = 168, obc = 28

Anything else that is missing, or that you guys desire?

Posted: Sun Oct 02, 2011 2:37 pm

by vickyg2003

Okay Bengt, I downloaded the binary zip file, but what do I do with it? Clicking on the jar doesn't do anything.

I have used makehex gui that Dave (mdavej) wrote to put a front end on friendly makehex, but I can't figure out how to run IRPmaster.

From your screen shots, I would think there must be a user screen somewhere but its doesn't want to start on my machine.

Edit: Oh I see, its a command line jar file.

Posted: Sun Oct 02, 2011 5:27 pm

by 3FG

Barf,
I have used IrpMaster some for automated checking of DecodeIR. It works well to check if there is some particular subset of possible IR signals that may be decoded incorrectly. As far as I know, only a person modifying or evaluating DecodeIR would have this use case. At the moment, I am probably the only user who a need for this capability. Futhermore, combinatorial testing is not a particularly important part of testing DecodeIR; instead testing the behavior when it is presented a malformed learn is the hard part.

I have not yet encountered a situation where IrpMaster can render a IR signal, but for which MakeHex in combination with an irp file cannot. Of course, we can write an instance of an IR signal in IRP notation which an irp file can't reproduce, and so a program like IRPMaster could allow more flexibility than MakeHex. However, and not surprisingly, the current implementation of IrpMaster doesn't fully support all possible IRP notations.

IrpMaster, in its present command line format, is very hard for me to use. Yet, I have a lot of experience over the years with CLIs. Leaving out the IBM 360s, Cyber175s, DEC PDPs, etc. (before 1980s) most of my usage has been in DOS, OS2 or Windows. An error in the command line input to IrpMaster generates an error message that usually doesn't provide even a hint to the problem. I strongly suspect that most users have less capability than I to work with it, and most won't be running Linux, which appears to your OS of choice.

mdavej wrote a GUI front end for MakeHex, and lots of people use it. It works well.

So at the moment, there is no upside for a user to switch from irp files/MakeHex to IrpMaster/IRP notation.

A good UI might change that. Probably even better would be the combination of IrpMaster along with the capability to decode unknown IR signals to a legal IRP notation. That would allow users to learn a set of signals, and then translate that to a well-formed set, without requiring the aid from an IR expert. mathdon has made some progress with the latter part, but it isn't yet applicable to most signals.

Posted: Tue Oct 04, 2011 12:06 pm

by Barf

@Rob(?): thanx for making sticky!

@vicky: The screenshot was from unpublished work in progress; to show that I can (and am!) programming GUIs too. I will do it slightly differently though. As you have probably found out by now, you need to open a command line interpreter, often called "dosbox" on windows and "Terminal" on Linux and Mac. The Internet is full of guides. Start by checking your java version with

Code: Select all

java -version

@3FG:

I have not yet encountered a situation where IrpMaster can render a IR signal, but for which MakeHex in combination with an irp file cannot.

So why is it that Makehex comes with (to my knowledge) around 60 irp-files, while there are around 100 protocols? I am not saying that it cannot be done (I have better things to do that to investigate the limits of Makehex), but obviously it has not been done, at least not published. Instead, IrpProtocols.ini contains over 100 protocols, in my development version there are 106.

However, and not surprisingly, the current implementation of IrpMaster doesn't fully support all possible IRP notations.

Wooah, that is a bold statement! IrpMaster supports the IRP notation as documented by Graham, with several extensions. The only exception is hierarchical repetitions (this is documented and discussed in the documentation), but you are probably not talking about that. However, the current DecodeIIR.html contains a lot of "junk" that is not proper IRP notation, ranging from obvious typos, to omissions (often denoted by "???"), violation of the grammatical rules (like multi-letter variable names (OK, as an extension IrpMaster grooks that)), and in several cases a purely informal, verbal "description". You do not expect an IRP-parsing program to accept that, do you? Neither do you claim that Makehex will grok it. I am not saying that there are no bugs in IrpMaster, but I am not aware of any legal IRP that IrpMaster will reject, or misbehave on. (Again, not counting hierarchical repetition.) I solicit bug reports, but I consider statements like that above to be non-constructive and unfriendly. Until you have filed a bug report, I claim that your unproved claim is simply factually wrong.

IrpMaster, in its present command line format, is very hard for me to use. Yet, I have a lot of experience over the years with CLIs. Leaving out the IBM 360s, Cyber175s, DEC PDPs, etc. (before 1980s) most of my usage has been in DOS, OS2 or Windows. An error in the command line input to IrpMaster generates an error message that usually doesn't provide even a hint to the problem. I strongly suspect that most users have less capability than I to work with it, and most won't be running Linux, which appears to your OS of choice.

I explicitly stated that a future GUI is possible, so that the current state is no necessarily final. Yes, there can sometimes be complicated command lines that are rejected, problem is that it contains so much information. Try the debugging option 1 as the first argument, it sometimes gives more verbose error messages. Like

Code: Select all

$ java IrpMaster.jar -d 1 <rest of arguments>

Secondly, you may like to try to install cygwin on your windows, it has a MUCH BETTER shell than windows.

Personally, I work very efficiently from a (good) command line environment. For a bad example, consider the original Makehex.exe. There you cannot from the commandline say what you want to do, but must edit a text file!

So at the moment, there is no upside for a user to switch from irp files/MakeHex to IrpMaster/IRP notation.

I am not sure about what you mean by "a user", but for the project and the community it would be a great win. Having one language for describing and another for implementing is simply bad software engineering. It is like writing a book on C with runnable examples in Fortran. As I wrote previously, the IRP notations in DecodeIR.html are of low quality. Having them to be parseable would help to keep errors out. Finally, as a specification of IR protocols, the notation in DecodeIR.html is simply insufficient, since it does not document the valid domain of the parameters, which parameters are dependent and which the user may/must set is not at all easy to extract, and parameters with a natural memory between invocations (like toggles) are not stated as such. There is also (as opposed to the old IRP notation) no default values for parameters. The IRP-notation as in Graham's documentation does not address these issues, but the extension I have suggested (see IrpMaster.html) does, and provides a documentation readable both by humans and programs.

Posted: Tue Oct 04, 2011 5:02 pm

by mathdon

3FG wrote:Probably even better would be the combination of IrpMaster along with the capability to decode unknown IR signals to a legal IRP notation. That would allow users to learn a set of signals, and then translate that to a well-formed set, without requiring the aid from an IR expert. mathdon has made some progress with the latter part, but it isn't yet applicable to most signals.

My first attempt in IR.exe and IRScope to decode unknown IR signals into IRP notation met with almost total lack of interest. With one notable exception (ElizabethD) the few comments I received ranged from indifference at the upper end to hostility at the lower one. This did not encourage me to continue the development.

Like Barf, I feel that IRP notation lies at the heart of JP1. It is, or should be, the glue that joins together the different aspects of protocol decoding and protocol building, yet any mention of it seems anathema. This is why I did not attempt to improve the IRP representations in DecodeIR.html when I was working on DecodeIR.dll, as I felt it was simply not worth the effort it would take.

Posted: Tue Oct 04, 2011 5:31 pm

by vickyg2003

mathdon wrote: My first attempt in IR.exe and IRScope to decode unknown IR signals into IRP notation met with almost total lack of interest. With one notable exception (ElizabethD) the few comments I received ranged from indifference at the upper end to hostility at the lower one. This did not encourage me to continue the development.

Gee, it must have been me that was hostile. I'm sorry that it comes across like that. I did lobby to have it relocated when it appeared in IR. While I find the IRP helpful, I still mutter every time I look at a learn in IR, because the IRP form is in the non-scrollable area and the stuff I need to see is scrolled to where I can't see it all at once. But I certainly didn't mean to sound hostile. I adapted. Sorry to sound so b****y.

Posted: Tue Oct 04, 2011 10:35 pm

by 3FG

Hi barf,
I guess I was way too terse. I like the IrpMaster program, and as I said, I use it. Also, I think there are some real possiblities to make use of the parser in additional applications. Furthermore, I agree that some extensions to the existing IRP specification would be useful, and I suppose the least controversial of these would be permitting multi-letter mixed-case variable names.

I was instead responding to why I included IRP files for the protocols recently added to DecodeIR. Put simply it's because MakeHex and the accomanying GUI is much easier to use, IMO, than IrpMaster in a command line version. The primary users of MakeHex, and potential users of IrpMaster hang out at RemoteCentral. I can't in good faith implicitly recommend that they switch to a CLI-based solution which has "complicated command lines". And I'm certainly not going to suggest that they load cygwin! (FWIW, I'm used to DOS/OS2/Windows CLIs, and cygwin--which I have, and am obliged to use for MinGW-- is not "much better" for me. I'm accustomed to something else.)

Regarding my "bold statement", it isn't bold at all. I'm not sure what "hierarchical repetitions" are, but perhaps this refers to the Variations described in Section 12 of the IRP spec. I've tried to make new additions to DecodeIR.html be in correct and complete IRP form, and I attempted to use IrpMaster as a check for a legal expression. Consider Zaptor, as described in DecodeIR.html 2.43:

Code: Select all

{36k,330,msb}<-1,1|1,-1>[T=0] [T=0] [T=1] (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}

So far as I know, the use of Variations is the only way to correctly describe Zaptor. For consistency, I want to use the same Variation form to describe the closely related Amino protocol:

Code: Select all

{56.0k,268,msb}<-1,1|1,-1>[T=1] [T=0] (7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m)+ {C =(D:4+4*T+9+F:4+F:4:4+15)&15}

IrpMaster doesn't accept these forms. I don't consider this to be a bug at all; rather it is a missing feature.

Part of the issue here is that IRP is a notation for describing abstract IR protocols. Pronto Hex is a method of writing a particular IR signal. It is quite possible to use Pronto Hex to describe a signal that Zaptor boxes will recognize and respond to. But Pronto Hex doesn't have the capability of describing a Zaptor signal which persists for an indefinite number of repeats, so programs based on IRP notation would seem to need additional parameters to generate a usable signal. There is an additional practical issue for Pronto Hex. Many universal remotes accept Pronto, but add their own notions of how many repeats are to be sent. A fair amount of MakeHex activity centers around modifying a "correct" representation into one which will work with a particular remote model. IRP is much better suited to describing correct and general signals, than to describing a bastardized one.

Posted: Wed Oct 05, 2011 1:39 pm

by Barf

Hi Graham,

mathdon wrote:
3FG wrote:Probably even better would be the combination of IrpMaster along with the capability to decode unknown IR signals to a legal IRP notation. That would allow users to learn a set of signals, and then translate that to a well-formed set, without requiring the aid from an IR expert. mathdon has made some progress with the latter part, but it isn't yet applicable to most signals.
My first attempt in IR.exe and IRScope to decode unknown IR signals into IRP notation met with almost total lack of interest. With one notable exception (ElizabethD) the few comments I received ranged from indifference at the upper end to hostility at the lower one. This did not encourage me to continue the development.

Hmm, I always had the impression that you were a highly celebrated member of the community, but of course it probably does not apply to all issues. The "automatic recognition" sits in ExchangeIR.dll, right? Is the 0.08 version still the current? Is there any API-documentation more than the comments in the code? I may come up with something

Thanx for GPL-ing it!!

Like Barf, I feel that IRP notation lies at the heart of JP1. It is, or should be, the glue that joins together the different aspects of protocol decoding and protocol building, yet any mention of it seems anathema.

Agreed, but still that does not put it in the realm of "users". Like Latin is the scientific language in medicin, yet the physicians do not try to talk Latin to patients. There are, in order, Logitec users, IR/RM/RMIR-(normal) users, advanced users, and experts. The advanced users know that an IRP is a "program" to be rendered to a raw format (like Pronto) by a program, just as a MIDI files is rendered to a wave file, or a C program us compiled to an object file, but they do not understand it. The "experts" can read and write IRPs. It is a matter of identifying the target group. If we try to teach IPR to normal users, IMHO we will end up disappointed. For example, the discussion here is aimed at experts, advanced users also allowed.

This is why I did not attempt to improve the IRP representations in DecodeIR.html when I was working on DecodeIR.dll, as I felt it was simply not worth the effort it would take.

Sorry to hear that. Here is room for improvements. Frankly. I do not consider the response to my postings the last month to exactly soliciting my help...

But finally, you are one of the persons, possibly THE person, that I am most interested of getting feedback from. Did I implement everything correctly? What is your opinion on the extensions? I have a slightly different model for persistent variables. Your opinion is valuable and solicited. Improvements? Suggestions? I have not yet received any substantial feedback, yet you post in my thread your dissatisfaction with feedback on your work. No criticism intended, but it feels ... strange.

BTW, I am a happy user of your 7781-Extender since several years!

Posted: Wed Oct 05, 2011 1:44 pm

by Barf

Hi Vicky,

While I find the IRP helpful, I still mutter every time I look at a learn in IR, because the IRP form is in the non-scrollable area and the stuff I need to see is scrolled to where I can't see it all at once

IrpMaster can generate a graphic representation of an IRP, like this. Do you see any usage of this feature?

(Actually, it is a feature of the ANTLR parser system, I just turned it on.)

Posted: Wed Oct 05, 2011 2:25 pm

by Barf

Hi 3FG,

I'm not sure what "hierarchical repetitions" are,

hierarchical repetitions are, not surprisingly, a hierarchy of repetitions, i.e. repetitions that contain other repetitions. Like {...}(...(...)+ ...)+. This issue is discussed in the documentation; the bottom line is that there is no know use case for it, and it is questionable if it makes more sense than a grammatically correct nonsensical sentence. Variations are implemented however.

and I attempted to use IrpMaster as a check for a legal expression. Consider Zaptor, as described in DecodeIR.html 2.43:
Code: Select all
{36k,330,msb}<-1,1|1,-1>[T=0] [T=0] [T=1] (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}

It is true that IrpMaster rejects it, but it is because it is invalid IRP! See the specification. IrpMaster does the right thing. Now, lets fix the syntax:

Code: Select all

$ java -jar dist/IrpMaster.jar  --decodeir -p -i "{36k,330,msb}<-1,1|1,-1>([T=0] [T=0] [T=1], (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m))+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}"   E=12 34 56 78
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
WARNING: Parameter specs are missing from protocol. Runtime errors due to unassigned variables are possile. Also silent truncation of parameters can occur. Further messages on parameters will be suppressed.
Device Code: 34.56 Function: 78, E=12
WARNING: When computing the Pronto representation, a (non-empty) ending sequence was ignored
0000 0073 0000 001A 005F 0047 0018 000C 000C 000C 0018 0018 000C 000C 000C 000C 0018 0018 000C 000C 000C 000C 0018 000C 000C 000C 000C 0018 000C 000C 000C 000C 000C 000C 0018 0018 000C 000C 0018 000C 000C 000C 000C 0018 0018 000C 000C 0018 000C 000C 0018 000C 000C 0018 0018 0A74
DecodeIR result: protocol = Zaptor-36, device = 34, subdevice = 56, obc = 78, misc = E = 12

'Nuff said? Same stuff goes for the second example; incorrect as it stands, fixed it runs correctly.

I previously wrote

As I wrote previously, the IRP notations in DecodeIR.html are of low quality. Having them to be parseable would help to keep errors out.

You have very vividly shown how correct this is.

But I also like to raise the issue why you did not report the "bug" when you "found" it, only when I forced you to back up the statement of incomplete implementation? (Features that are claimed to be implemented, but are not, I call "bugs".)

So far as I know, the use of Variations is the only way to correctly describe Zaptor. For consistency, I want to use the same Variation form to describe the closely related

Slightly off topic, a variation can always be rewritten using considerable duplications.

Part of the issue here is that IRP is a notation for describing abstract IR protocols. Pronto Hex is a method of writing a particular IR signal. It is quite possible to use Pronto Hex to describe a signal that Zaptor boxes will recognize and respond to. But Pronto Hex doesn't have the capability of describing a Zaptor signal which persists for an indefinite number of repeats, so programs based on IRP notation would seem to need additional parameters to generate a usable signal. There is an additional practical issue for Pronto Hex. Many universal remotes accept Pronto, but add their own notions of how many repeats are to be sent. A fair amount of MakeHex activity centers around modifying a "correct" representation into one which will work with a particular remote model. IRP is much better suited to describing correct and general signals, than to describing a bastardized one.

Let me suggest that you say "parametrized protocol" instead of "abstract protocol" and "non-parametrized" or "raw" instead of "a particular" signal. Probably everyone in this forum agrees on your general message. A Pronto signal can contain an intro signal, and exactly one repetition, that the "device" decides on how many times it is sent. (The message a few lines earlier "WARNING: When computing the Pronto representation, a (non-empty) ending sequence was ignored" above means that Pronto representation cannot represent an ending signal.)

Now it is my turn to make a bold statement:

Writing a program/library like IrpMaster is a much harder task that to write a GUI for such a program. While IrpMaster consists of around 6000 line of java and it took months to write. A GUI would be, I estimate, 1000-2000 lines, most of which can be automatically generated by an IDE like Eclipse or Netbeans, and it would take days.

And, repeating myself, a GUI might show up in the future.