| Post 1 made on Friday January 9, 2009 at 16:57 | |
jack D Long Time Member |
| |
I recently programmed my first pronto (9800) using PEP2. The way I went out about it, learning as doing, was to create a page for each of my devices. I added buttons and commands for each device. That way, I could check if the commands worked for each device. Then I structured activities that use those devices. Having the individual device pages helped debug if the chain of commands I entered into the activity did not work as expected. Once the activity turns on all the relevant devices and sets them to the proper inputs the activity jumps to the relevant device page.
The thing is, the example xcf in PEP is not really set up this way. The activities have everything in them and then there will be a page with whatever controls are necessary for that activity. There are not, however, separate pages for devices.
So it seems that the suggestion is to structure everything around activities rather than devices.
In my case, once the proper equipment is turned on in an activity I pretty much only need to access the controls of one device to "manage" that activity. The only exceptions to this are for volume (always my surround processor) and a few other things like that which I have programmed into the hard buttons on the system page.
The only advantage I can see to structuring everything around activities is that it makes the remote and one's system easier to use for someone who doesn't know or care to know what is going on "behind the scenes." So, for example, if you are a pro installer doing the set up for a customer you might want to structure the xcf around activities thereby hiding details.
Is there any other reason from a programming point of view that it is better to structure everything around activities rather than devices?
Thanks for any thoughts.
This message was edited by jack D on Friday January 9, 2009 at 17:33. |
| [ Reply | Quote & Reply |
| Post 2 made on Friday January 9, 2009 at 19:10 | |
Lyndel McGee Loyal Member |
| |
Prior to PEPV2 (which no longer supports links), we used devices vs activities as containers for hidden IR code pages as you associated a device with an extender and therefore all codes in one device would be sent to a particular extender as configured for the device.
ProntoScript is still 'device' or what they now call an 'activity', specific. That is, you cannot jump between pages of different devices and maintain ProntoScript context.
Personally, one of the reason I'm not yet using PEPV2 because I like the modular concept promoted by Links and Hidden Code pages (I never used MyDatabase in PEPV1). This approach makes swapping out equipment very easy. If you'd like a better overview of said usefulness, see Dale Crawford's documentation from the file download of Easy Theater/re CCF(s) in Classic Pronto Forum.
I've followed this practice since my 2nd config on the old Marantz RC5000i and I am not ready to give it up. I'm hoping for links in PEPV2 but I don't think they will reappear due to structure of the internal XML file. Right now, the structure does not promote links as did the XML structure of a PEPV1 file. |
Lyndel McGee
Philips Pronto Addict/Beta Tester
View EscientPronto 1.0.2 Docs - http://www.mediafire.com/do...hp?yyfzfzzok5z | [ Reply | Quote & Reply |
| Post 3 made on Friday January 9, 2009 at 19:58 | |
Guy Palmer Regular Member |
| |
Although they can both achieve the same ends, PEPV2 and PEPV1 work in very different ways. Lyndel's method is typical when using PEPV1: set up hidden pages for each device, link to these hidden pages from the visible pages, and don't use MyDatabase. No distinction is made between 'devices' and 'activities', both of which are called 'devices'. In PEPV2, however, a sharp distinction is drawn between 'devices' and 'activities' and the use of MyDatabase is fundamental as it is the only place to store 'devices'. The equivalent to Lyndel's method when using PEPV2 is: set up MyDatabase entries for each device and call these entries from the visible pages, each of which is part of a designated activity.
I personally find the clear distinction between 'devices' and 'activities' in PEPV2 to be very helpful. When there is a one-to-one correspondence between devices and activities, PEPV2 and PEPV1 work in very similar ways. When, however, activities use multiple devices or the same device is used in multiple activities, I find that the separation between them in PEPV2 makes the activities much easier to maintain.
Putting this all a different way: 'devices' and ''activities' are, in my mind, very different things and I therefore like the fact that PEPV2 keeps them separate. |
| [ Reply | Quote & Reply |
| Post 4 made on Friday January 9, 2009 at 20:22 | |
Jon Welfringer Long Time Member |
| |
| On Friday January 9, 2009 at 19:58, Guy Palmer said... |
|.........
|
I personally find the clear distinction between 'devices' and 'activities' in PEPV2 to be very helpful. When there is a one-to-one correspondence between devices and activities, PEPV2 and PEPV1 work in very similar ways. When, however, activities use multiple devices or the same device is used in multiple activities, I find that the separation between them in PEPV2 makes the activities much easier to maintain.
Putting this all a different way: 'devices' and ''activities' are, in my mind, very different things and I therefore like the fact that PEPV2 keeps them separate. |
I agree with this 100%. For devices in MyDatabase, PEPv2 makes it much easier to re-use the device.
The only place I have a problem with this is if you need to control your device with ProntoScript. In those cases, you have to re-use your same code in each activity. If they would make global functions that can easily be called across activities, then even these devices would be defined once and used everywhere just like MyDatabase. (Yes, I know some of the work-arounds to global code, but to me it's a kludge.) |
| [ Reply | Quote & Reply |
| Post 5 made on Saturday January 10, 2009 at 10:45 | |
jack D Long Time Member |
| |
Perhaps since I never worked with PEP1 I don't mind the concept of using MyDatabase (MD) to configure the codes for each device. Seems like a good idea although I've had funny stuff happen from time to time where PEP2 reloads the default devices into MD and I have to go through and delete them.
I set up two pages on my Home Page. One with buttons for activities and another to go my device pages which just pull the code from MD. So I have activity pages that set everything up but then I also have a separate page for each device so I can control the devices "manually" as if I were using the original remote (well not every command but all the ones I use).
Like I said, I started with setting up the individual device pages because it seemed the easiest way to ensure that the controls were set up correctly for each device. Then I created the activity pages which just turn stuff on and then jump to the relevant device page.
I guess it must be a hassle not being able to port scripts across pages when working with prontoscript. I don't have any experience with scripts except that I imported Lyndel's script for the Escient. I never paid much attention to what that script is doing. I just know that it works. Anyway, it does seem like a big problem and one wonders what Philips were thinking when they designed PEP2. |
| [ Reply | Quote & Reply |
| Post 6 made on Saturday January 10, 2009 at 12:27 | |
Jon Welfringer Long Time Member |
| |
| On Saturday January 10, 2009 at 10:45, jack D said... |
| Perhaps since I never worked with PEP1 I don't mind the concept of using MyDatabase (MD) to configure the codes for each device. Seems like a good idea although I've had funny stuff happen from time to time where PEP2 reloads the default devices into MD and I have to go through and delete them. |
I think this is a bug in MyDatabase. I have the same issue with a Denon device that has a ton of bogus codes defined in it. I delete the codes and it appears fine for maybe one or two trips back into MD, then all of a sudden they magically reappear. No rhyme or reason. Any other changes that I make to a code stay just fine, only issue is the deleted ones reappearing. I've resolved myself to just leaving them there now. |
| [ Reply | Quote & Reply |
| Post 7 made on Sunday January 11, 2009 at 10:13 | |
jack D Long Time Member |
| |
| I've experienced both that codes get added to devices after I delete them and also devices get added. I have not determined under what conditions this happens. I just try not to fool around too much with MD. :-) |
| [ Reply | Quote & Reply |
| Post 8 made on Sunday January 11, 2009 at 14:33 | |
Jon Welfringer Long Time Member |
| |
| While I'm not 100% certain, I think the other devices get added when you are opening other sample XCF files that you may have downloaded. |
| [ Reply | Quote & Reply |
| Post 9 made on Sunday January 11, 2009 at 17:22 | |
jack D Long Time Member |
| |
| Yeah that could be. I did download some files and was looking through them for ideas or equipment set ups I could adopt. That might have been when the devices got added to MD. |
| [ Reply | Quote & Reply |
| Post 10 made on Monday January 12, 2009 at 17:51 | |
jack D Long Time Member |
| |
| If I shared my xcf file with some of you experts would anyone be willing to critique it? thx |
| [ Reply | Quote & Reply |
