I have just started using the CCP editor. It seems if I create a macro with an alias to a specific command in a specific device (Like device TV/page 1/HDMI1) and then use the button editor to move around the buttons in that device (like the buttons in the TV device), the alias in the macro does not move to the new location. It stays with the original location. Is that correct? Is there a way to have the alias in the macro track the change in location of buttons in the device? Or should I just get all the codes for macros directly from the IR database?

Thanks.

Why not move the buttons around first and THEN create your macros???

After the fact I can do that. But I found out about this I had already done a bunch of macros. So, I was just trying to confirm the behavior and see if anyone knows of an alternate way to do the aliases. It is different behavior than on the pre-CCP software.

Can you confirm that the behavior I am seeing is normal and that there is no way to change that behavior?

There is no way to change that behavior. When you "Create and Name Devices" you are creating a data object within the program of class device and the members of the class are the IR codes which are then mapped to the button of the device. When you create aliases in your macros you are creating data pointers to those members within the object. The macro then dereferences that pointer address it reads the IR code stored there.

If you change the button after you've created the macro, the macro will still dereference that same pointer address which is now reinitialized and [null].

Like kgossen said, move your buttons then write your macros. This behavior didn't change from the previous editors either. They had the same object oriented programming structure.

Thanks. That is what I suspected was happening.

On my old 850 when I create a macro by learning a sequence, each command in the macro is referenced by Device and Function. If I move the elements on a device, the Function in the macro does not change. So, I do think CCP is different. That is what tripped me up.

Seems to me that the best way to do this is to not use recorded sequences for any IR codes, but rather to get them all from the database as needed. That avoids any potential problem if there is a reason to move the codes in a device after the fact. The only problem with that I need to be sure never to move codes that are not in the database, like specific hex codes that I enter.

Thanks for your explanation.

Nope, because that's not the most efficient use of the memory. When you create a central pool of IR commands all macros (1-255 step) dereference that pool of memory addresses and gives a predictable result for macro performance.

If you are entering specific hex codes it is better to create another device just for whatever new codes you need, even if it is duplicating one that's already in your project. It's ok to have 2 of the same Sony CD player in there, one with URC library codes and one with custom hex codes. You can just hide the one the the hex and alias the commands in you macros. Your IR routing is all based on devices, not buttons like RTI.

CCP assigns button ID's for automapping of commands (Play to Play, Vol + to Vol +). Part of that reason is that it allows for multiple inheritance and object code reuse with each project. The Transporter function within CCP would rely on this type of code reuse when exporting a MX980 program to a MX780 for instance, but I don't think I've ever seen this work. You can import devices from other CCP programs but the tool never behaves like it was finished.

I am not as interested in memory usage as I am in ease of programing. I understand that using database codes may not be as efficient, but unless you are really approaching memory limits, using individual codes seems like the way I will go. Unless you have an extremely complicated system, memory usage and speed of macro execution is really not the primary concern.

Personally, I like the paradigm from the old 850 editor, although I understand that may follow the correct current programming paradigm.

By the way, I used to write assembler code for huge programs for 16 bit computers, so I am well aware of memory usage issues. I understand well the tradeoffs of complexity of coding versus resource usage.

Thanks for your comments. I think I am all set on the direction to take for my particular situations.

I converted my file so all the macros and other button references use ir database links rather than aliasing to the device buttons. I downloaded both to the remote, and the 2 approaches used essentially the same amount of memory. This is a simple system with a receiver, BluRay, and a TV. It is however probably a pretty common configuration for 780 users. At least in this simple experiment, using ir database links rather than aliasing did not use more memory than aliasing. So, I will stick to database links, which then allows me the option to move the device buttons as needed.

If/when you ever need to use an rf basestation and need to route ir devices to specific ports, you will wish you hadn't done it like that.

Exactly.

I too used to build my macros with the MX900 Editor and then move the buttons. It worked fine. With CCP, that is not the case. However, it really is not a big issue. How often are you aliasing commands from lets say, a cable box? Not sure about others, but I place my TV, receiver, and other devices that a client does not need access to on a hidden page. The layout of the buttons in these devices are a non-issue, as the client never sees them. What the client sees is the Cable Box pages, BDP pages... These pages will typically contain no buttons or codes that are aliased anywhere.

Can you explain? Thanks.

URC just won't work that way. If you want a code out of the IR database you copy it to a button FIRST, then alias to it. If you add a basestation you'll be redoing ALL your macros.

basestation routing is tied to the device. If you used aliases you would get the correct routing for each device. If you put a bunch of codes from different physical devices into a single logical device then they will all route to the device you are in at that time which is probably not what you want.

I am coming for 850's and 900's and trying to figure out the best way to work in CCP. So, thanks for your comment. I was just surprised that I could not move commands if they were aliased to. Now that I know that, I can work out an efficient way to not move commands, if necessary

This remote is for someone who is more than a casual user and may want to sometimes use buttons that are not commonly used on some of the devices. So, rather than hiding the original pages on some devices, I just arrange the pages so that the common commands are on page 1, but they still have access to the other pages. I suppose I can create a device that is pretty much a copy of the original device using aliases and hide the original device. Then I can move any commands on the copied pages as needed. I originally moved buttons because this is a new receiver (NAD 757) to me and I did not realize that some of the commands (like the A/V presents) might be useful sometimes. Plus, some of the layouts in the database have related commands (like the Input commands) scattered around the pages and even aliasing to them is tedious. Now I will rearrange them from the start.

I usually do not hide any devices for these people. I just make they harder to access, like putting them on page 2 of Main 2, or something like that. Then they can use them if the wish, but the casual user will problem never stumble on them. I would not do that for a casual user, but do for more knowledgeable users.

Thanks for you comment.

Thanks. I had figured that out. The last time I tried to do routing the software said you could do it but the basestations did not actually support it.

Thanks for all the help guys. I think I am getting up to speed on CCP. I do think that not allowing buttons to be moved was a step backward, but knowing that it works that way, I can live with it.

Thanks again.