mathdon wrote:
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.
vicky2003 wrote: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.
vicky2003 wrote: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.)
3FG wrote: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.
3FG wrote: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.
3FG wrote: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.
