JP1 Remotes

I put together a little GUI for John Fine's MakeHex to make it a little easier to deal with IRP files.

Please post any comments or suggestions.

LINK

EDIT: This tool leaves all your original IRP files intact. All changes are made to temporary copies.

Seems pretty cool, appears to work as advertised.

Hi Dave, I need to download MakeHex to work with the IRScope, so thought I'd try your program too. Since I don't understand MakeHex, I'm having trobule understanding what MakeProntoHex is going to do, or how to enter data.
Is there a ReadMe?

vickyg2003 wrote:Hi Dave, I need to download MakeHex to work with the IRScope, so thought I'd try your program too. Since I don't understand MakeHex, I'm having trobule understanding what MakeProntoHex is going to do, or how to enter data.

It took me a few looks at the GUI to figure out all that a, b, c, d stuff even though it is explained right there below.

You specify the device either a or a.b by filling in one or both of the Device fields.

You specify a single function a or a.b or you specify a range of function a through c or a.b through c.d by deciding which of those four fields to fill in.

If the selected IRP has define statements at the top (imply some user option) those show up in the define portion of the GUI. If the IRP has Define statements elsewhere, implying a computed intermediate value, those seem to be properly left out of the GUI.

Is anyone else confused by the Accept button? I am. I understand that after you change Device or Function etc., you need to press Accept before Make Hex. But I don't understand the point of having two buttons. Why doesn't the Make Hex button do the whole job?

My GUI assumes you already understand makehex, so I rely on John's readme for that. There is a Help menu option that has a brief how-to and a link to his readme. The static text is just a format reminder. If you have any ideas, I'd be glad to add more to my help screen.

I wanted to keep it a 2 step process so you can preview your IRP changes to make sure they're correct, especially since the function fields are a little complicated. Direct editing is a 1 step process since you can see your changes as you make them.

I guess I could update the IRP automatically with each change the user types in, but you could get some weird intermediate results. For example, if you enter the end ranges first and leave the beginning blank, my code ignores them.

I'd be interested to see some other opinions.

To be perfectly honest, I still don't understand the "a.b through c.d" option myself, so I made no attempt to explain it in my help window

mdavej wrote:I guess I could update the IRP automatically with each change the user types in, but you could get some weird intermediate results. I'd be interested to see some other opinions.

Other opinions would be nice.

My opinion as a user is that the user doesn't know nor care when you post the edits into !Output.irp, so you could post every edit into the file as it happens or you could hold all the edits in memory and not post any of them until the user presses Make Hex. Either way the user has a two step process, edit the GUI fields then press Make Hex. (Rather than Edit then Accept then Make Hex).

My opinion as a software engineer is that you should keep the edits in memory. The Make Hex button should then do the whole job: Write out the !output.irp file and run MakeHex against it.

I'll give it a shot. I also have a few other tweaks to do.

I agree that the user doesn't/shouldn't care about what gets written to what file or when. In spite of what I implied, I don't really change the IRP file itself, even when you press accept. Everything you see on the screen, edits included, is just in memory. I only write to my !output.irp when you press makehex. So I'm already doing it like you said, aside from the accept (preview) step.

mdavej wrote:In spite of what I implied, I don't really change the IRP file itself, even when you press accept. Everything you see on the screen, edits included, is just in memory. I only write to my !output.irp when you press makehex. So I'm already doing it like you said, aside from the accept (preview) step.

I was AFRAID to push the Accept button for just that reason. I ususally play with the tools while reading the documentation. With the Accept button I was afraid to try it.

Now that I realize that I'm not going to screw anything up by pressing Accept, I'll do some more experimenting.

I like it! It definitely makes generating Pronto hex much easier.

My preference would be to eliminate the Accept button. Also, I would make the default choice for the format of the device/function number in the output file to be "Both". I can't see any downside to including both decimal and hex numbers.

ETA: How about including the protocol name as the first line in the output file?

This may be a limitation of the irp file format, but it would be good if there were a warning when the user specifies an illegal device or function number. For example, using Sony12 as the protocol, device 129 with function numbers up to 255 is accepted. The generated Pronto Hex is device 1, and the function numbers roll over at 128, so the final ouput is legal, but it doesn't match the description.

New version posted. Removed "Accept" button and default to "Both".

Nothing I can do about the protocol name. I thought about putting it in the file name, but then you'd have to manage lots of output files versus one, so I decided against that.

I could add some limit checks too, but I don't know the rules for each protocol.

mdavej wrote:Nothing I can do about the protocol name.

It seems like it would be simple enough to open the outfile for append after MakeHex has released it, move the file pointer to the first line, and add the protocol name as the first line in the file.

As far as the name of the outfile I generally like the standard MakeHex way of naming the outfile by protocol better; but it seems reasonable to me that in a GUI interface the user should have control over the name of the outfile.

Your program definitely makes using MakeHex easier than opening each irp file for for editing prior to running MakeHex. I also prefer leaving the irp files in their original state which your GUI allows.

johnsfine wrote:You specify a single function a or a.b or you specify a range of function a through c or a.b through c.d by deciding which of those four fields to fill in.

I have never seen the need for specifying a single function a.b or a range of functions a.b through c.d. The a.b or a.b..c.d function specification yields a function number(s) in the form X.X. In other words what protocol uses a function number that is something other than a whole number? Or am I using this wrong?

garyb.ncc wrote:I have never seen the need for specifying a single function a.b or a range of functions a.b through c.d. The a.b or a.b..c.d function specification yields a function number(s) in the form X.X. In other words what protocol uses a function number that is something other than a whole number? Or am I using this wrong?

Oops! I actually don't remember. I wrote what you quoted after looking at the GUI and assuming the feature was there for a reason.

I half remember inventing makehex support for two part function numbers similar to the support for two part device numbers, but I don't remember whether I finished that feature or tested it or ever had any use for it.

A two part function number would have been useful for the way Marantz and others uses RC5x protocol. But since the DecodeIr interface would handle that so badly, I made the questionable decision to pretend the first part of an RC5x function is a "subdevice" and the second part is the function. Then I made the IRP file compatible with the decoder rather than sensible for the way RC5x is used.

Yamaha receivers use the NEC1 protocol, and recently some functions have 16 bits of data. Normally the second byte of data in NEC1 is the complement of the the first byte, but Yamaha now sometimes violates that "rule".

I don't know whether MakeHex would generate such a code or not.

johnsfine wrote:Oops! I actually don't remember.

Well I've been using MakeHex for quite some time and have never really been able to figure out the 2 part function numbers. It's good to know that I've really not been missing anything - a least if I have, you forgot what it was.

The combination of MakeHex and DecodeIR has saved my keyster on more than one occasion so thinks for the great programs.