JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RemoteMaster v0.91 now available!
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Feb 24, 2004 10:57 pm    Post subject: RemoteMaster v0.91 now available! Reply with quote

I've built and released RemoteMaster v0.91

Changes for v0.91

- Improved Device Combiner support:
- Correct device and protocol upgrade code
- Direct entry of protocols (not just by importing)
- Support for 740 and 6805 based remotes.

Links:
RemoteMaster.v0.91.zip
Release Notes and Change Log (also included in the ZIP file)
Installation Instructions (also in the Readme.html included in the ZIP file)
The RemoteMaster project home page.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)


Last edited by gfb107 on Wed Feb 25, 2004 10:38 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Tue Feb 24, 2004 10:58 pm    Post subject: Reply with quote

Note that there still is NO support for importing KM upgrades that use Device Combiner.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
streetskater



Joined: 18 Feb 2004
Posts: 75
Location: NYC

                    
PostPosted: Wed Feb 25, 2004 1:21 am    Post subject: Reply with quote

I'm experimenting with the Sony Combined (new) and the 15-1995 & 15-2117 remotes.

It's working but You have to explicitly enter the double Hex bytes into the Fucntion Sheet--nothing else works . Even though the Protocol column has a drop down that shows the correct choices it always defaults back to the "Sony12". Ditto the Device Column--it shows the appropriate choices but always displays "none". --So when you plug in the correct Hex values the only other columns that show the correct info are OBC and EFC. None-the-less it seems to be generating the correct Device Upgrade and Device Protocol.

When I switch the "look & Feel" I now have enough room to properly display double hex codes--previous versions truncated the display when I swiched from "Windows"...so RM is coming along nicely IMHO.
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Wed Feb 25, 2004 7:57 am    Post subject: Reply with quote

As you can see I have fiddled with the Sony Combo (new) a bit, but it isn't done yet. I've got the visual layout done, but none of the code to enforce the interaction among the fields. That will be in the next release.

This release was all about Device Combiner.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
DGG



Joined: 08 Dec 2003
Posts: 143

                    
PostPosted: Wed Feb 25, 2004 9:17 pm    Post subject: Reply with quote

Downloaded 0.91. Still having a problem that I first noticed a couple of weeks ago that appears to be related to something in (or not in) two of my upgrade files. That is, after I start RM, the first upgrade file seems to load normally - even the "problem files". However, if I subsequently attempt to load one of the "problem files", RM's displays are not be completely updated to reflect the new file.

When I attempt to load one of the "problem files" other than immediately following startup of RM, on the Setup Tab, none of: Description, any of the protocol information, Upgrade Notes and Protocol Notes are updated. The Description window sometimes is partially cleared. However, the Setup Code display shows the setup code for the "problem file". All other tabs appear to reflect the data in the "problem file".

The loading of any upgrade file other than the two "problem files" seems normal in all respects.

While I don't recall the version number when I didn't have the problem, this situation seems to have developed during the last couple of weeks. I don't recall making any changes to the "problem files" during that period

Incidentally, one of the "problem files" was the initial source for the other.

If I can do further testing to help you isolate the problem, just let me know. In the meantime, I've posted the "original" of the two "problem files" in the Diagnosis Area under the hearing [url=http://groups.yahoo.com/group/jp1/files/Diagnosis%20Area/Motorola%20DCT2000%20(URC%208911).rmdu] "Motorola DCT 2000 (URC 8911).rmdu"[/url].

Incidentally, I'm using Windows XP on a Dell Dimension 4500.
Don
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Wed Feb 25, 2004 10:34 pm    Post subject: Reply with quote

Whenever you see RM behave like this (it seems like it either isn't responding, or gave up part way), close it and take a look in rmaster.err for any kind of Exception. That usually provides very good information for me to pinpoint the problem.

I've just been doing some testing, and I can only duplicate your results if I have used the Device Combiner protocol (either manually or by loading a device upgrade that uses it). I couldn't find any problems with your upgrade file.

I'll have a new release out tonight that corrects this.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
DGG



Joined: 08 Dec 2003
Posts: 143

                    
PostPosted: Thu Feb 26, 2004 12:13 am    Post subject: Reply with quote

Thanks for the quick turnaround.

rmaster.err in Diagnosis Area as "DGG-rmaster.err".
Don
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Thu Feb 26, 2004 9:24 am    Post subject: Reply with quote

OK, I've got this one figured out. It is not fixed in v0.92, but will be in v0.93. That will be posted later today.

Again, this isn't caused by anything in your upgrade file.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
DGG



Joined: 08 Dec 2003
Posts: 143

                    
PostPosted: Thu Feb 26, 2004 1:08 pm    Post subject: Reply with quote

Thanks, Greg. Don't rush on my account since, as I noted, I have a workaround.

There's one other little thing about RM I don't recall whether I or someone else may have previously mentioned. That is, under the External Functions tab in the EFC/Hex data block, entry of "$" with hex data is treated as an error - which makes RM inconsistent with the other JP1 tools. Obviously, the "$" is not required for interpretation of the data. (I assume that's what the data "Type" identifier is for.). But, for consistency across tools, I wonder if "$" shouldn't be permitted - even if it if just ignored.

And, on a related topic, since there is at least one situation in which one would enter ASCII data, i.e., for the CustomName special protocol, could the Type field be expanded to include ASCII format?

Don
Back to top
View user's profile Send private message
DGG



Joined: 08 Dec 2003
Posts: 143

                    
PostPosted: Fri Feb 27, 2004 12:09 am    Post subject: Reply with quote

Greg, I 've discovered another little problem with v0.91. That is, I don't seem to be able to enter an EFC for an external function. In fact, nothing gets accepted in the EFC/Hex field when Type is EFC. Hex entry seems to be OK though (when Type=Hex).

Also, just curious. Why is the EFC/Hex field center-justified?

This is the first time I've really explored "External Functions" in RM. Previously, I had assumed that External Functions in RM were equivalent to Keymoves in KM. Of course, they're not. Do you plan to implement a "keymoves" function as well into RM?
Don
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Fri Feb 27, 2004 8:01 am    Post subject: Reply with quote

I've got a fix for that ready as part of v0.93. I've also made it so that $ will be allowed (but ignored) for hex data.

I'll have to think about the ASCII idea. It seems simple enough, except that Java doesn't do ASCII, it does unicode. If I do it, I would probably call it Text instead of ASCII.

There is no special reason for having it centered. I'll make it left-aligned.

Not having used the Keymove feature in KM, I don't really know what the difference between external functions and Keymoves is. I might be willing to implement it if you would explain it.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
Mark Pierson
Expert


Joined: 03 Aug 2003
Posts: 3017
Location: Connecticut, USA

                    
PostPosted: Fri Feb 27, 2004 9:38 am    Post subject: Reply with quote

gfb107 wrote:
Not having used the Keymove feature in KM, I don't really know what the difference between external functions and Keymoves is. I might be willing to implement it if you would explain it.

The Key Moves sheet in KM can be used to create key moves based on the current device, but bound to another device button. By default, it shows all the functions defined on the Functions sheet, and allows you to assign them to a Bound Device and Bound Key. It creates a seperate Key Move Code block on the Setup Sheet that is used with the Import button on IR's Key Moves tab.
_________________
Mark
Back to top
View user's profile Send private message Send e-mail Visit poster's website
DGG



Joined: 08 Dec 2003
Posts: 143

                    
PostPosted: Fri Feb 27, 2004 11:27 am    Post subject: Reply with quote

I'm glad Mark jumped in. He did a much better job of explaining KM's Keymove function that I would have. If it's not a "big deal", I think you should implement it - because not only is the capability useful, but it was recently "advertised" (for KM) in the fifth and sixth entries in this post

Since I seem to have set you on a consistency "binge" with External Functions, there's one other itsy bitsy thing you might look at. That is, leading 0s are suppressed in the Setup Code field. They are not suppressed either on RM's Setup page or by other tools.

By the way, despite all the "nits", RM is a great tool.
Don
Back to top
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Fri Feb 27, 2004 1:22 pm    Post subject: Reply with quote

I'm thinking about how to add the KM Keymove function.

The obvious approach is to simply duplicate the KM Keymove sheet.

I'd like to brain storm about other ideas, especially ones that would take advantage of RM's ability to display an interactive image of the remote.

I have an idea that would be something like the Layout panel.

On the left we would have an image of the remote. The device buttons would allow selection of the "Bound device", which would be highlighted in some special way. It would be possible to have no device button highlighted, which would be equivalent to using the "(upgrade)" choice present on KM's Keymove sheet. There would also be a place to select the "Shift state", like the Layout panel.

On the right side would be a table containing the list of defined Keymoves, with appropriate controls for adding and deleting.
The columns would be very similar to KM's Key Move's sheet, although I would probably NOT show the EFC, Hex cmd or Keymove code.

There would be a number of different ways of interacting with this panel.

Graphical (interacting with the image):
Click on a device button to select the bound device, click on a shift state to select the desired shift state.
Any (non-device) buttons with keymoves that match the bound device and shift state would be filled in indicating there is a keymove bound. Clicking that button would highlight (select) the corresponding entry in the table. Right-clicking a non-device button would display a context-menu of all the available functions (including "- none -"). Choosing one of those functions would create a new keymove with that function and the selected bound device, bound key, and shift state. Selecting "- none -" would delete the keymove. If there already was a keymove bound to that key, the function would just be changed.

Tabular (interaction with the table):
The user would be able to change the function, bound device, bound key and shift state. Also be able to create new and delete existing keymoves. Selecting a keymove in the table would also cause the image to highlight the corresponding button, and to reflect the bound device and shift state.

Thoughts?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Back to top
View user's profile Send private message Visit poster's website
DGG



Joined: 08 Dec 2003
Posts: 143

                    
PostPosted: Fri Feb 27, 2004 3:42 pm    Post subject: Reply with quote

WOW!!!!

Your proposal certainly has "sex appeal" but, unless you plan to provide a similar graphical (layout-supported) interface for the basic button assignment functions and are simply using "keymoves" as a way to prove the concept, I'm not sure it's worth the effort (But then, it's your effort.)

For me, the simple tabular interface you describe would suffice. Frankly, I don't see the companion layout as being particularly useful even for button assignment, and especially not for keymoves on non-"upgrade" devices, since only the buttons assigned in the current upgrade could be taken into account - at best, an incomplete picture - unless, of course, you can access IR.exe's .txt file.

But, let me offer a couple of specific comments anyway.

Quote:
It would be possible to have no device button highlighted

I think the device button for the bound device of the keymove selected in the table should always be highlighted. I don't see any advantage to differentiating between the "upgrade" device and the others in this way.

Quote:
On the right side would be a table containing the list of defined Keymoves

Would this include keymoves automatically generated by RM for, say, shifted keys? If so, they should be specially tagged. And, if they could be modified under this tab you may want to consider some form of flagging under the Buttons tab as well. Otherwise, I'd be concerned about confusion, and contention (RM's simple refusal to proceed in the face of an error condition rather than providing an error message isn't one of my favourite features) between the Keymove tab and the Button tab.

There are at least two other classes that should be considered for a comprehensive list of keymoves but that (I suspect) couldn't be accounted for on the new Keymove tab. They are keymoves generated directly with IR.exe and keymoves for the upgrade device set up on the Keymove tab of the upgrades for other devices (i.e., the function that started this discussion).

Finally, RM's current External Functions cabability, while the name suggests otherwise, is just another keymove assigment mechanism, i.e., it sets up keymoves on the upgrade device that cause some other device to do something. I appreciate that the Functions/Buttons mechanism is used to make the assignment but, they are, nonetheless, keymoves and in fact, are treated that way in the output file.

If all keymoves relevant to the "upgrade" device can't be included, I'd be inclined to re-label the function "External Keymoves" and limit it to setting up keymoves on another device that require execution by the "upgrade" device. That being said, it seems to me the new function logically could be integrated with the current External Functions tab, with the bound device (or the presence or absence thereof) defining the general nature of the keymove.

Hope this helps
Don

PS: Going back to an earlier post, why does one need to specify the type of data to be entered into the External Function EFC/Hex field. Is this a shortcoming of using JAVA? Why not simply enter data in the traditional form, i.e., $xx for hex, "abc" for character strings and assume anything else is an EFC?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control