I've done URC a lot longer than RTI, and looking back, I've felt that after a couple dozen MX850s I could knock them out in a reasonable timeframe and have a real feel for it. Saving often used devices was a particular timesaver.

Now I've done RTI for about a year and a half, and though I've done several dozen, I always wonder if I am doing it the best way. In particular, handling macros and page flips.

My feeling is that page flips should be doable without going into standalone mode, but I can't arm wrestle RTI into putting that into software. They are not very quick to incorporate new ideas as it is. Page flips, in particular "please wait" flips are really beneficial. But then, you must build system macros. No page flips needed? Then just do all the programming on the device itself.

But what is best practice here? Store dozens of premade macros on the processor that get copied to every new processor you use, and only utilize the ones you need? Or, keep all the programming on the remote only?

How do y'all do it to be most efficient? I am specifically interested in those who do slightly or significantly different configs at each client's home, perhaps including a piece or two of client gear if needed. Those who do the same systems over and over won't even have to think about it.

Appreciate your thoughts.

I am interested in thismyself being fairly new to RTI and want to start doing this the right way to avoid hastles and wasted time later on.

I also agree with you 100% that you should not have to go into standalone mode to do page links on the remote. I get the understanding that page flips can only be run on the device itself becuase there isno 2-way But with that understanding, there then is no reason why RTI should then make you have to change individual buttons to run the macros as standalone. They should provide you the option to insert "page links" and if this option is used do either of the following:

1) Automatically then assign the button as standalone for this code once the option is selected with no programmer intervention.

2) Leave the button as not standalone but the system should know that the page link part of a macro runs local on the device. **MOST IDEAL**

I also think this should be the case for flags as well. Make two options in the macro window. System flags and local flags. Like above, if your buttons are set to default (which is tied to a processor) and you pick the option for "local flags" then the device knows to set, cler, etc that flag locally on the device.

The ability to run animated GIF files would save coutless pages in having to make animated pages. The other way would be for RTI to allow routines/modules. You then just create the Please Wait pages like you do today with the delay set between pages and these stay in a routine/module called please wait. Anytime you want to do the please wait routine, there would be a maco option called routine, you pick from the stored routine called for example "Please Wait" and set the the amount of seconds that that routine would run. The screen would show the routine for that amount of seconds while at the same time the processor or device continues to process the remaining macro. This way you can use the same routine over and over agin throught the system and the only thing you have to figure out is how many seconds to have that routine run on the screen before it disappears. You would also be cutting down your animation routine becuase you only need to create enough pages to run one full cycle.

There is a good reason why the page link feature only works in Standalone mode.
If the button is set to RF mode, and you build a macro on the button (ie not on the processor), the macro is actually STORED on the processor, not on the remote.

With the older URC model, if you had a macro on an RF button, each of the commands in the macro would send a separate RF signal to the processor. This is one of the reasons that RF on the old URCs was so flakey. If ALL of the RF signals did not get received properly by the processor, the macro would fail.

On RTI, even the macro is shown on the button, it is actually stored as a complete macro on the processor. Then, the remote only has to send ONE RF trigger signal to the processor. As longs as that signal arrives at the processor AND the processor is not busy when it arrives, the macro will run correctly.

What you guys want is something like this on a button:


Page flip to PLEASE WAIT page
TV On
Receiver On
Delay
Receiver Input
TV input
Source Play
Page flip to SOURCE CONTROL page

The problem is that if you want the command parts of the macro to reside on the processor, the remote will execute like this:

Page flip to PLEASE WAIT page
Send trigger command to run macro on processor
Page flip to SOURCE CONTROL page.

There will be NO delay between the page flips.

Yes, there is ways that RTI could add this type of feature, but it would potentially add a level of complexity not required for most users.


As for best practices:

I have a template "system".

In the system is a single RP6, and one of each type of remote.
When I load the template, I save it as the customers name.
Then I delete the remotes that I'm not using, leaving the processor and 1 remote in the file.

The remote has a HOME page. On the HOME page are buttons for all the activities.
Each activity button is set to standalone, and looks like this:

Page flip to Please Wait
System Macro Trigger
Delay.....
Page flip to source page.

On the source pages, all the buttons are set to RF mode, unless they require macros.


Now, on the processor, I build a bunch of macros. These are generally in a couple of different groups: Actitivity macros, and "subroutines":

Sub_TV ON
Sub_TV Off
Sub_TV Input1
Sub_TV Input2
Sub_Receiver ON
Sub_Receiver OFF
etc
etc

I'll also have some "source" macros:

Source_DVD ON
Source_DVD OFF
Source_CD ON
Source_CD OFF

and the Activity Macros:

Act_Watch TV
Act_Watch DVD
Act_Listen CD

(NOTE: It is VERY good practice to leave lots of extra macros (unused) between the actual macros, so you can add more later:

Act_Watch TV
Act_Watch DVD
System Macro 3
System Macro 4
System Macro 5
System Macro 6
System Macro 7
Act_Listen TV
Act_Listen Cable Box
Act_Listen Tuner
System Macro 11
System Macro 12
System Macro 13
etc

(you get the idea).

Now, the activity macros look like this (example: watch DVD)

System Macro: Sub_TV ON
System Macro: Sub_Receiver ON
System Macro: Sub_DVD ON
Delay xxxx seconds
System Macro: Sub_TV input1
System Macro: Sub_Receiver Input DVD


The benefit of this type of design, is that you can change every instance of the TV power ON command, by changing the single macro called Sub_TV ON... so its easy to change brands/models etc.

This should give you a very large head start if you are just starting out.

It's all about working smarter!! You want to know a best practice? Build a couple base systems that you offer clients. I mean more then just remote programming. Have packages that you sell with a TV, DVD player, Receiver, Speakers, and control. Advertise it as such and that way you can have remotes already programmed for the exact system. That way all you need to change is the main page if you customize it for each client. We have about 6 different packages that we offer the most. Does that mean that we don't offer other product? No but it's easier for the salespeople and the clients. Even if you don't do that you can have remotes that you use as templates. I have a ton of clients I've done RTI remotes for and I usually use my template remotes with minor changes. Hope this helps.

First, I want to say thank you very much. This is great. I wish I had this advise before I started programming my last and first RTI remote, the T4. Now I'll go back and set suff up right. This past job was existing older components that I would never use agan, except for the cable box and the request so I would have had to start over anyway.



I assume initially I would create each type of remote as I have a job where that remote is spec'd. Eventually I would have a setup for all remotes, if I use all remotes. does that sound right?


Unless they require any macro or if they require macros that have too long of delay that you need to make a please wait page/animation.



This is one thing that should be improved. You should either have the ability to insert a macro, so that you don't have to leave blank spacing or you should have the ability to sort the list so then as long as common components start with the exact same name they can be shown grouped together. How much space in between



For example, do you just place the panasonic RS232 command in the SUB_TV ON or do you also create individual system macros for all of the component features, Like TV_PANASONIC_ON and then place the RS232 command in that macro and then put the TV_PANASONIC_ON in the SUB_TV ON macro?

Whatever works for you. You will continue to improve upon the templates anyways, and I've started from scratch several times as I've learned better methods


Yeah, thats right. Or if other devices (remotes/keypads) will need to run the same macro. For example, we use a Sony 5 disc CD in some of our dist audio systems. There is no discrete for Random On/Off, but I've found a work around:

Play Normal: Program, Play, Continue
Play Random: Program, Play, Shuffle

If there is only one remote, I can put all of these commands right on the button. The advantage is that I can now MERGE my CD page into a new system, and the macros will work.
However, if I need 4 remotes and 2 touchpanels to also control the CD player, you could create system macros for CD_Play Normal and CD_Play Random




You cannot insert a macro.... and I have learned NEVER to delete a macro either. Instead, I just erase all the steps, and rename it as System Macro ###.
When you name macros, use a prefix such as ACT_ or SOURCE_ or CD_ or however you want to name things. When you want to trigger a macro, the list of available macros is alpha ordered, so this keeps related macros together.

I would love to see the ability to create folders with collections of macros in each folder. And as an extension, the macros could identified like this FolderName/Macro Name. This would be ideal on a processor with more memory. Then, over time, you could have folders for each Brand, etc.


Up to you. I played around with a very complicated method (using many flags) for making a "universal" template that would handle all the brands we carry. Basically, in ever macro, I triggered an INITIALIZE macro. In the INIT macro, I set and cleared an array of flags which told all the macros what gear I was using.

In the end, it became too much to manage... but that was before they allowed naming of flags. Still, I've gotten fast enough now that I won't try this again until they give me real variables.

The folder idea would be a good one.

If the list is sorted when you want to trigger a macro, then why is it important to leave extra blank spaces between the different types or models when entering them on the RP6? I assume its so that you can have room to keep them grouped together. But this is also why RTI should give you the ability to at a min sort this list (i.e. click on the heading for description, on the RP6, to sort alpha by description) so that it doesn't matter the order you enter them in the list, you can still view them in the list the right way. Actually if the list was always shown in order of description, instead of by Macro #, this would solve the need for blank lines completely.

Why never delete a macro? Or is this for the same reason to keep the extra space.



Variables are much needed. You wouldn't have to necessarily have to enter all of the products codes into the system then. You name a variable for the device property you want to control i.e. TV_ON, TV_INPUT1 and then bring up a "variable/product wizard". You then assign those variables to codes in the IR database, the new rs-232 database. The system then just imports those codes into a variable table/list. If you want to use a different TV you can bring up this variable/product wizard to quickly reassign and remap variables.

Bingo! I do this all of the time... 4-6 open macros labeled "zzz" between each group of similar programmed macros. I always end up adding things that I did not have planned in the first place. It make my more elaborate processor configurations easy to search and edit.


I liken this to the old days of programming Prontos where I (and others) would create no frills hidden pages that contained all of the codes for a particular device and all of the UI pages just linked to those codes so that you only had to go to one location to change, edit or troubleshoot. There is the IR code search and replace feature with RTI which is very cool and may seem to render this "centralized" or "root level" approach overkill when using IR only, however, if you have to alter routing or assign routing for like devices (which happens quite often) you would still have to sweep through the entire configuration to make changes.

... this brings big wishes of mine... I would like to be able to group edit specific IR code routing within groups of channel macros without recreating the macros and to group edit IR routing and device codes for multiple pages. This would save me an unbelievable amount of time on larger projects.

A scenario would be this... Multiple Tivo boxes addressed differently thus using different code sets... currently I can not use the IR code search and replace. I have to drag on new codes for each new code set and then to change routing I have to select the screen and hard buttons seperately for each page, select all and then change the routing. After that I then have to recreate the channel macros. By the time you are configuring multiple remotes that all have control over several like devices (say 4-6 cable or sat boxes, each dedicated to a particular household member) it take a frustrating amount of time to make these changes from a template.

I feel your pain. Just finishing 2 cable boxes, two displays, main amps in surround sound for main display, pair left and right speakers to secondary display, fed by zone 2 amps...ended up with four groups of favorites, two for each display... I could elaborate on why but you probably get it. Not looking ahead, I started with the 5 or 6 pages of favorites, all of which had to be duplicated. Very time consuming.


I understand completely.

What is so difficult about changing TT editor so that certain commands are ignored by the processor when it stores the macro? Simple boolean logic:

Process: compile macro

IF var = $(pageflip,delay,buttontest)
IGNORE
ELSE
READ command into macro and compile
ENDIF

How's that for a quick fix? :^)

I think it is not a matter of some fabulous programming feat but more like the priority or the will to do it. JMHO.

Your system looks good and I am going to study it further.

If a second T2C were in the same system I assume you just duplicate the remote?

I agree with you as well but I realized the one thing that was overlooked when I thought this out. This is the Delay function. If its in RF mode,the delay occurs on the processor and the steps within the macro that will be run on the processor and not on the remote itself.

In standalone, if you put in a delay that occurs on the remote itself not the processor. You would call a system macro to run a macro on the processor. Now if they made two different type of delay macro's (local & processor), then you can do what you we suggted and use the booleen type of command to run any pagelinks and local delay's as standalone while the processor stores all of the other commands and is triggered via an RF trigger code from the remote.

The only other thing I can think that is specifficaly tied to standalone mode is local flags (aside from the obvious sending IR directly from the remote).

This still doesn't help in any but the most basic cases. If the macro running on the RP-6 checks a flag or reads a power sensor, then there is no way for the remote to know how far along in running the macro that the RP-6 is, since it can be different every time the macro runs. You would need a two-way communications channel back to the remote so that they could both run the macro in lockstep.

Bruce

As for the multiple cable box issue, I'm a bit confused by this.
Here's how I do it (most of my systems have 3 or 4 cable boxes, each accessible throughout the house, and thus controlled by several remotes):

Lets say these are multiple cable boxes.

First, I make sure that all of the cable boxes are on the same RP6
Each Cable box is on a dedicated IR port.
Usually I have multiple RP6 units in the house. But, since I use the scrolling list feature (which only works on the default RP6), I set all of the remotes to use the RP6 with the cable boxes as their default.

Now, on one remote, I create a cable box control page.
I put all the necessary commands on hard buttons.
Then, I select all the hard buttons at once, and EDIT BUTTON PROPERTIES. I make sure that they are all set to output RF to the default RP6 (the one with all the cable boxes). While still in the EDIT PROP page, I open the IR routing tab, and unselect ALL of the ports, except the one for the cable box I want to control from this page.

As for favourites, to be honest, I don't offer TV channel favourites, and have never been asked to. However, I do use the scrolling list feature for ONE or more of the cable boxes which are designated for DIGITAL MUSIC CHANNELS. The same procedure would apply for doing TV channel favourites though:

1. Create the scrolling list
2. There is no way to change which RP6 the scrolling list will effect, but in the setup of the scrolling list, I go in and deselect all the IR ports except the one for the cable box I'm controlling.


I now have a nice cable box control page, which a complete array of hard buttons, and a scrolling list of favourites.... and all of this is set to output to only one IR port, so just one cable box.

Now, I duplicate the page for each of the cable boxes I need to control from the remote.

On each duplicate page, I highlight/select all the hard buttons, and change the IR routing.
On the scrolling list, I go in and change the IR routing of the list (I don't go into every macro to do this, I just use the built in feature of the scrolling list)


Now I have several identical cable box pages, each controlling a single cable box.

Now I just "merge" these pages onto all the remotes.

Now I have several remotes, each having the ability to control multiple cable boxes.... and since I start with a cable box control page I have already created (a template), the whole process takes about 5 minutes per remote...

That is how I do it as well.

My issue is that I have to do it in four steps once the GUI is created and loaded with commands for the first cable box routing.

1) Copy all Gui pages for another like device and/or another remote
2) Select all and change routing for the screen buttons
3) Select all and change routing for the hard buttons
4) Rerun channel macro wizard for fave pages (I offer more than I should!)

If I could select multiple pages and change the default routing of the commands (or of certain device commands) or control routing properties in conjunction with an IR code search and replace it would speed the process greatly and save my click hand.
This is very time consuming.

I do admit though, that the page merge had eluded me. I have been using a copy-paste method.

I think I will try and start an RTI tips and tricks thread this weekend!

You still have that same problem today when putting the button in standalone. This is why you make the "Please Wait" or some other type of delay pages before the final page flip. Now wth 2-way, you wouldn't need alocal delay, since you can get feedback from the processor when it has finished running the process, and then do a page flip. Thus no need for "standalone" unless the remote is sending out its own IR codes.

If you right click the scrolling list and select properties and then Output you can chnage the output mode right there to any RP6 or RP1 that you want no?





This would be great.