IrpMaster, program/library for IRP rendering, released

[mathdon]

Hi Graham, ... 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!

Sorry, Barf, it's a question of time and priorities. At present my time is being spent on developing Protocol Builder facilities in RMIR. I find it easiest to concentrate on one thing at once, so I'm afraid I haven't looked at IrpMaster yet. Glad you like my extender.

[3FG]

Barf,
Yes, I wrote the IRP incorrectly. The reason I didn't submit a bug report is that I didn't think it was a bug. Variations are not mentioned in the documentation (not that it needs to be), and I didn't pick up your intent to implement all of IRP minus the hierarchical repetitions. The document describes hierarchical reps in the context of button down, button held, and button released, which is the situation the variations in my faulty IRP are trying to express. So I believed that hierarchical reps (which aren't mentioned in the IRP spec) referred to variations, and thus believed that variations weren't implemented.

However, my error illustrates the point I have been trying to make: the combination of writing IRP notation for input into IrpMaster is too difficult for me. I believe that it will be too difficult for many others.

I'll continute to use IrpMaster, because it has real value for me.

[vickyg2003]

Hi Vicky,
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.)

I find the diagram to actually be more difficult to understand than plain IRP, but then perhaps I don't have the correct background to analyze and understand it. Just because I don't see how this would help users understand signals doesn't mean anything. This whole IRP thing never came naturally to me. I was always in awe when newbies used to talk IRP with John Fine and yet I had been reading the forum for years trying to make sense of the timing numbers and IRP and was still clueless. When I had my epiphany, and could finally understand what Rob and John were talking about, I wrote a document to help others gain a basic understanding. My document is more of an IRP for dummies, for people like me who are struggling with the whole infrared subject. Being able to read IRP is a huge help in understanding what signals look like, but I still can't write IRP, even after years of struggle. My document is not as technical as Graham's guide to IRP. I read Graham's technical spec often, but I'm still struggling with comprehension.

[Barf]

Sorry, Barf, it's a question of time and priorities. At present my time is being spent on developing Protocol Builder facilities in RMIR. I find it easiest to concentrate on one thing at once, so I'm afraid I haven't looked at IrpMaster yet. Glad you like my extender.

Ok, there is of course no way not to respect your priorities, but possibly appealing to a sense of interest in an issues you more-or-less stated one and a half year ago. Without your specification, IrpMaster almost surely would not exist. Don't worry about debugging or bug reports, just reading the documentation and writing down what comes on your mind would be of great value.

I find the diagram to actually be more difficult to understand than plain IRP, but then perhaps I don't have the correct background to analyze and understand it.

Ok, so lets not pursue that path any further. The diagram is a parse diagram, that computer scientist like. It is just a waste product of the parser anyhow.

This whole IRP thing never came naturally to me. I was always in awe when newbies used to talk IRP with John Fine and yet I had been reading the forum for years trying to make sense of the timing numbers and IRP and was still clueless. When I had my epiphany, and could finally understand what Rob and John were talking about, I wrote a document to help others gain a basic understanding. My document is more of an IRP for dummies, for people like me who are struggling with the whole infrared subject. Being able to read IRP is a huge help in understanding what signals look like, but I still can't write IRP, even after years of struggle.

As I wrote previously, IRP is hard, and it is because it covers a difficult subject, and solves a difficult problem. You should never expect a difficult problem to have a simple solution. "Teaching IRP to the masses" is neither necessary nor desirable, and will only lead to disappointment. IMHO, there is not much more need for "IRP for dummies" than for "Functional analysis for dummies". (I sincerely apologize and regret if you find this discouraging, Vicky.)

Variations are not mentioned in the documentation (not that it needs to be), and I didn't pick up your intent to implement all of IRP minus the hierarchical repetitions. The document describes hierarchical reps in the context of button down, button held, and button released, which is the situation the variations in my faulty IRP are trying to express. So I believed that hierarchical reps (which aren't mentioned in the IRP spec) referred to variations, and thus believed that variations weren't implemented.

Ok, My problem is that I have a scientific consciousness, if something is not complete, I will not call it complete either, even if the missing piece has no practical importance whatsoever, as in this case. Instead it leads to misunderstandings, If you have constructive suggestion on improving the documentation, I would be grateful.

However, my error illustrates the point I have been trying to make: the combination of writing IRP notation for input into IrpMaster is too difficult for me. I believe that it will be too difficult for many others.

IRP is hard. How can anything dealing with "curses" like

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}

be considered easy? With or without GUI. But what I do not buy is that cutting-n-pasting a "curse" like the above into a GUI like in a screenshot in a previous posing of mine is easy, while cutting-n-pasting it to a command line interpreter is hard. It can also be pointed out that giving the IRP on the command line (the -i option) is not the normal case; the normal case being using a configuration file and calling the protocol by its name. Still, can be done! And it can be published in web forums like this, without resorting to those pesky screen shots.

I'll continute to use IrpMaster, because it has real value for me.

Great. I look forward to your constructive suggestions, criticism, and (yes!) bug reports.

[vickyg2003]

This whole IRP thing never came naturally to me. I was always in awe when newbies used to talk IRP with John Fine and yet I had been reading the forum for years trying to make sense of the timing numbers and IRP and was still clueless. When I had my epiphany, and could finally understand what Rob and John were talking about, I wrote a document to help others gain a basic understanding. My document is more of an IRP for dummies, for people like me who are struggling with the whole infrared subject. Being able to read IRP is a huge help in understanding what signals look like, but I still can't write IRP, even after years of struggle.

As I wrote previously, IRP is hard, and it is because it covers a difficult subject, and solves a difficult problem. You should never expect a difficult problem to have a simple solution. "Teaching IRP to the masses" is neither necessary nor desirable, and will only lead to disappointment. IMHO, there is not much more need for "IRP for dummies" than for "Functional analysis for dummies". (I sincerely apologize and regret if you find this discouraging, Vicky.)

Interesting. When I was trying to get Graham to move the RAW Irp form to another portion of the screen in IR, my argument was much the same. I thought that seeing the IRP on the learn screen made the screen less than friendly for the newbie and should have been an "advanced Menu" item, the way the raw timings are. However I do think having IRP knowledge is something that should be available to anyone here who wants to know.

I sure am glad that Rob and John didn't feel that educating the "masses" in IRP to be unnecessary and disappointing. They may have felt it was hopeless at times, but they didn't give up on me and I appreciate the effort.

[Barf]

I just uploaded a new version. Only user visible feature is that Graham Dixon's automatic protocol analyzer, originally a part of his ExchangeIR library, (see this) and included in the latest versions of IrScope, is supported through use of the --analyze flag, just as the --decodeir flag. There are some more API-functions that I needed myself, in particular for IrMaster (Yes, the name of that program differs from the present one by only one letter! )

I have changed the location of the sources, from tools/programs to misc/Program sources since I suspect that is Rob's intention. Souce download.

Keep IrpMaster-ing and IRP mastering!

[bevhoward]

I am very interested in this tool.

In the simplest form, I would like the ability to have a simple html file running on a "personal web server" computer close enough to the media equipment so that when a link in the html file was clicked, that link would call something such as your tool to issue a specific command from the computer's ir dongle.

On the server, the link should be able to call the api along with an argument to generate a specific ir command.

With this capability any device with a simple web browser connected to the personal server would be able to issue ir commands needing no local software to do so.

fwiw, I have thirty years experience with FoxPro and it would be (relatively) simple for me to write a windows application that would generate html files containing small screen layouts with command links drawing from IR commands stored in local files. It would also be possible to allow the users to choose their specific devices and generate html pages tailored for their devices.

More importantly, once the templates are generated, anyone with basic html editing capabilities could further customize the html pages to meet their own needs.

Please contact me if this approach is at all interesting to you.

Beverly Howard
Bev@BevHoward.com

[Barf]

Hi Bev,

there are some approaches to controlling IR-equipment through a web browser already: There is Openremote which contains a web-services based server (tomcat e.g.) which can send IR commands using e.g. GlobalCache (although the configuration is awkward). The user sends commands either through a web interface or a ipad/ipod/android/you-name-it-interface. Then there is Eventghost, a general purpose home/windows-automation tool, being able to send IR commands through e.g. GlobalCache or USB-UIRT, and containing a web-server for accepting user commands. Girder is essentially a commercial counterpart to Eventghost. And then there is or course LIRC. In the first three cases, the programs, or their configurations, contains the rendered IR signals, most often in Pronto format. Most things you suggested should be possible to do with one of these tools. It is is or course not as elegant as being able to render them just-in-time from e.g. a protocol-name/devicenumber/commandnumber-description. The commands are entered either pre-rendered from some source, or, anacronistically, recorded ("learned") from existing remotes. From a practical point of view, this "beaty spot" should probably not be exaggerated, at least not as long as the signals are "clean". (LIRC has its own format, often considered to be unusable, see this however.)

I intend to integrate IrpMaster into OpenRemote as soon as I get some free time. Also the next version of IrpMaster/IrMaster will support LIRC directly; both sending commands to a (patched) LIRC server (on the TCP port) and generating configuration files for LIRC from an interval of command numbers. (It is in principle finished, I have just not had the time to release it yet.)

BTW, you may like to check out my other IR-related open.source project, Harctoolbox.

[bevhoward]

Thanks for all of the links and information... a bit overwhelming since the last few times I made similar requests, I found little to nothing.

I will look at all of these and expect I will be back for more info and discussions.

Thanks again... and, please stay tuned.

Beverly Howard

[bevhoward]

While I have not waded through all of the links you gave me, I have read enough to learn a lot.

All of the options, except Barf's, have their own baggage load and design approaches that add complexity that I think can be avoided.

In looking at your app, I wondered if you knew about
http://www.byremote.com.au/HIP/Default.htm

I have tinkered with this software a few years back, but, my primary concern with it was that there was no way (at least apparent to me) to import and easily handle a number of remotes and all of their commands.

This software does allow capturing, viewing, saving and rebroadcasting ir commands but I never got to drilling down enough to find out how to implement it's commands from another program.

I have to also admit I am intimidated by JAR files... I tried, unsuccessfully, to learn Java a little over a decade and have had mixed success with the JAR utility available here.

At the moment, my main goal is to try and learn how to issue command lines to your software from a local IIS (formally personal web server) page. If I am not too dumb and too old to do that, I think 90% of the quest will have been met.

Thanks again. Any tips (not already in this thread) on a dummy downloading your JAR files and executing them? Looks like I have Java 6 update 7 on the XPPro machine I will be experimenting on.

Thanks in advance,
Beverly

[Barf]

I have not looked into the HIP-Tool; however I read the web page. I get the impression that Eventghost can do everything that tool can do, and more. Most importantly, Eventghost is -- as opposed to the HIP -- free software (with source code), technically GPL.

All of the options, except Barf's, have their own baggage load and design approaches that add complexity that I think can be avoided.

I am a bit puzzled by that statement.

I have to also admit I am intimidated by JAR files... I tried, unsuccessfully, to learn Java a little over a decade and have had mixed success with the JAR utility available here.

jar-files are, as the name suggests (Java ARchive), nothing but a sort of archives, similar to zip-files. There is nothing intimidating about that. Anything in the instructions that was unclear or could be improved?

At the moment, my main goal is to try and learn how to issue command lines to your software from a local IIS (formally personal web server) page.

If I strip out tool names from your request, it seems (on the basis of your previous posts) that you want a web server that sends commands to an IR dongle (MCE?) causing it to send IR signals to your equipment. Eventghost should be suitable for this; it has a www-server and should support the dongle. You can use Ir(p)master offline to generate your configuration files. Eventghost also has its own active community and forum.

Any tips (not already in this thread) on a dummy downloading your JAR files and executing them?

You might like to use IprMaster in the form of IrMaster, you may find it to be easier.

[bevhoward]

I may be missing something, but, is it possible to execute your tool from a command line in order to issue an ir command to a local ir dongle?

for example;

<executable> /send <remote_name>, <key_command>

...assuming your tool has a data reference to the commands used by that remote.

Beverly Howard

[Barf]

IrpMaster's goal is the rendering of IR signals in IRP-notation. Therefore the answer is "no". For the same reason, it does not know "remote_name" or "key_command" either.

[xnappo]

I may be missing something, but, is it possible to execute your tool from a command line in order to issue an ir command to a local ir dongle?

for example;

<executable> /send <remote_name>, <key_command>

...assuming your tool has a data reference to the commands used by that remote.

Beverly Howard

Hate to be repetitive Bev, but the tool that does want you want is EventGhost. Yes it can also do more, but it is open source, has a great user community and is easy to use...

xnappo

[bevhoward]

thanks... will check EventGhost and see if I might make some progress.

The posts were not wasted... prompted me to learn a good bit.

Beverly Howard