JP1 Remotes

Well, I finally got this thing done enough to actually release it as a beta. It's called MakeLearned, and it's a Java program that generates learned codes, right now only in Pronto format (so it's essentially MakeHex). The big difference is that it uses the current IRP format that John Fine is using in the DecodeIR.dll documentation.

Here the download link:
http://www.hifi-remote.com/sony/MakeLearned_b1.zip

Double click the .jar file to start the program, it's a very basic GUI. I included as many protocols as I could find enough info on, and some that are experimental and may or may not produce correct output.

Hopefully people who have a Pronto can confirm that the thing actually produces good code. I've mostly been putting the output through DecodeIR.dll to test it. Also, if anybody wants to give me protocols to add or can give me corrections to any protocols, that would help a lot.

Rob Humphreys

It's great. I already recommended it in a couple threads at RC. But of course there are a few little changes that would make it a lot nicer:

1) Default values: In NEC1 I want to be able to leave subdevice blank. There should be some syntax in the IRP file that says the default value of S = 255- D used only when the user doesn't specify S.

2) When you have specified only one function, there ought to be a button to store the Pronto Hex directly into the clipboard, in the right format for pasting into ProntoEdit or similar.

3) When you have specified a range of functions, there ought to be a button to store the whole output directly into the clipboard in the right format for pasting into IrPanels. Have you tested with IrPanels? It is really picky about format. I don't think your output is quite right for IrPanels. That's a program that really needs someone to rewrite it. But until someone does, it's the most common next step after using MakeHex.

4) Can you do better at releasing the output file after writing? I had to close MakeLearned before Windows would let anything else touch output.txt

5) How about allowing hex numbers input with 0x prefix, so I could put in device 0x7e instead of 126 when reading codes from the Yamaha pdf files.

I would like to coordinate with you to reduce the amount of variation and drift in the new IRP language. Some things in your readme I'm concerned about are:

> The first part has to be specified as {freq,unit,MSB} in that order. Putting
> k after a number will multiply it by 1000. MSB, or MSB and unit, may be
> left off, and it will default to LSB and a unit of 1. For some reason this
> isn't consistent in many examples of IRP format I found.

Not consistent with what examples?

What does unit do in your version? In IRP language as I defined it, any value that becomes a duration without having a k or u suffix gets multiplied by unit at the point it becomes a duration. The u (meaning microsecond) is used to suffix those durations that you don't want multiplied. As I used the new IRP notation, I discovered that cases could be complex enough that it was hard to be precise about when/whether a number becomes a duration.

> I added a 'p' modifier to the IRP format, putting this after a number means
> that the number is in IR pulses, i.e. it multiplies it by ( 1e6 / freq ).

I like that idea and should adopt it into my use of IRP notation.

> You can't use something like x:y:z in an expression.

Any particular reason you didn't like that construct? I find it very helpful for various situations where bit fields are scattered around an IR signal and/or strangely grouped for check byte computation.

Regarding the suggestions:

1) Default values: In NEC1 I want to be able to leave subdevice blank. There should be some syntax in the IRP file that says the default value of S = 255- D used only when the user doesn't specify S.

I can add a default= line or something like that in the protocol file. I just need to add a spot in one of the classes to save the expression. If the input is blank it will check the default.

2) When you have specified only one function, there ought to be a button to store the Pronto Hex directly into the clipboard, in the right format for pasting into ProntoEdit or similar.

I'll see about this; I've never done something like this in Java before, so I'll have to look through the API.

3) When you have specified a range of functions, there ought to be a button to store the whole output directly into the clipboard in the right format for pasting into IrPanels. Have you tested with IrPanels? It is really picky about format. I don't think your output is quite right for IrPanels. That's a program that really needs someone to rewrite it. But until someone does, it's the most common next step after using MakeHex.

I've never used IRPanels. I'll look into this.

4) Can you do better at releasing the output file after writing? I had to close MakeLearned before Windows would let anything else touch output.txt

Bug. The close function is in a try block with a bunch of other stuff, so if it generates an exception anywhere in the block it doesn't close. This is what the 'finally' part of that syntax is for.

5) How about allowing hex numbers input with 0x prefix, so I could put in device 0x7e instead of 126 when reading codes from the Yamaha pdf files.

Easy enough to do.

The reason that x:y:z isn't in the expression syntax is that it would make the parser more complex. I haven't touched that part of the code in about 6 months (it was basically the first thing I wrote). I'll see what I can do about this. You can use it when specifying something to be transmitted, e.g. ,D:4:2, would work, and so would ,(D^F):4:2, but ,(D:4:2):4, would not.

The inconsistencies in the {} section refers to the DecodeIR.dll documentation, where parts are arbitrarily omitted, and sometimes the unit and msb are reversed in order. In here you have to be consistent about it.

Basically, in the () part, any part that is simply a number with no suffix is multiplied by the unit and treated as a duration. A k suffix multiplies it by 1000 and the unit. A u suffix treats it as is. An m suffix multiplies it by 1000. Finally, the p suffix works as I described it in the readme. That's it.

The p suffix is incredibly useful for specifying certain things, especially odd units, which are often some nice number of pulses, like 16, 24, or 32.

Anyway, I'll try to get the next version of the beta out soon to fix the file close bug. Notepad ignores that stuff completely, which is why I didn't come across it before.

Rob Humphreys

Here's the next version:
http://www.hifi-remote.com/sony/MakeLearned_b2.zip

It includes the fixes and suggestions John Fine mentioned, except for the IRPanels stuff. I did this quickly, as I won't be able to work on it over the next week, so there's a good chance of bugs.

Rob Humphreys

I can't get this version to work at all. Every attempt gives the error
"Invalid variable -- Device: x -- Invalid text in input"

(with x replaced by whatever the device number was).

I'm not in a big rush to have this. I'm just reporting my results, and assuming you are away from this project for a while, warning other users to try the earlier version instead of this one.

Try it again. I fixed that bug as well as another that probably wouldn't have come up unless you made a custom IRP (none of the ones in there would have caused the problem).

Great, but when you paste into IrTool (for testing MakeLearned) or into ProntoEdit etc. for real use, those programs don't accept the title line of the signal, such as:

Device: 4 Function: 5

When you copy a single Pronto Hex string to the clipboard it should be just the Pronto hex, not the Pronto Hex with title line.

That is part of why I thought copy to clipboard for IrPanels would be different from copy to clipboard for ordinary uses (IrPanels requires those title lines and is picky about what is on them).

If you release the Java source code, I may find it easier to make minor tweaks by just editing the Java code. I'm not yet comfortable enough in Java to add a significant GUI feature to a Java application, but I find small changes pretty easy.