On November 28, 2012 at 18:41, dtc said...
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.
