TP_ARRAY vs DEFINE_COMBINE

dthorson

What?s the dis/advantages of using a TP_ARRAY[] vs DEFINE_COMBINE a panel and a virtual panel?

DEFINE_DEVICE

dvTP               =  10001:1:0    (* MVP-8400 Modero ViewPoint Touch Panel                     *)
vdvTP              =  33001:1:0    (* VIRTUAL TOUCH PANEL DEVICE                                *)

DEFINE_COMBINE (vdvTP,dvTP)

//-------------------- OR --------------------//

DEFINE_VARIABLE
DEV TPArray[] = {vdvTP, dvTP}

vining

Arrays give you more flexabilty and control. Once TPs are combine for instance what you do to one you do to all unless doing and uncombine before hand and then recombine after. (that might be wrong cuz I've never tried it). With an array you can do something to the whole array or any part of the array. Typically who have a TP_array to receive button events so that any TP that has a button push goes through the same button_event handler but by using some thing like button.input.device you can selectively only respond to or control the panel that intiated the push or event where if they are combine using the button.input.device would still affect all the TPs that were combined.

gary_cummins

There is also a third way...COMBINE_DEVICES...

I use combine devices this way because you can UNCOMBINE_DEVICES anywhere in programming and then recombine it again. (Great for combinable conference rooms.) You can't do that with a DEFINE_COMBINE or an array.

vining

So maybe if you use Define_Combine you can't un-combine, where as if you use combine_device you can. That sound vaguely familiar and I would look it up if I really cared.

However with an array you can always group what ever elements of the array you want and never have to worry about combining or uncombining. Basically what combine devices does is load the DEV values in an empty DEV array or structure, well at least that's want I assume it does.

DHawthorne

With a single real device, as posted in the example, there is no reason at all to make an array or a combine. So I assume we are talking about multiple real devices, not one real with one virtual.

I almost never use combines anymore, always an array. Combining makes all of your real devices act like a single panel, so if you ever need to know exactly what panel a command came from, you are out of luck. All of your panels have to be doing exactly the same thing at any given instant. And for many modern devices, this cripples the functionality. Take any media server, from iPod to MAX - you really need for each panel to work independently, and combining them makes that impossible. And frankly, I don't see where combining gives you any advantage over an array. If you want all your panels to reflect the same thing all the time, you can just as easily send your updates to the array as to a virtual.

dthorson

Thanks everyone who responded,

So a DEFINE_COMBINE, all panels act as one.

A TP_ARRAY, you can add or remove panels as needed, and determine what panel triggered an event.

With COMBINE_DEVICES, you can uncombine as needed.


I like that we have this flexibility with AMX.

REBUILD_EVENT

never ever ever use DEFINE_COMBINE twice in a system of two controllers on the same devices. we did so and both systems hung after booting. since then, we always check if we have a duplicate DEFINE_COMBINE on the systems when something is strange...

TurnipTruck

I have found that with COMBINE_DEVICES, you can get some strange feedback occurences. For example:

nBUTTON_ARRAY[]={1,2,3}

ON [dvDEVICE,nBUTTON_ARRAY] will show feedback on all three buttons.
OFF [dvDEVICE,nBUTTON_ARRAY] will NOT always stop feedback on the buttons.

I have pretty much accepted, for myself, that DEV arrays are the way to go. All of the "benefits" of combined devices can be acheived in code within a device array, with a lot more reliability.

Joe

TurnipTruck wrote:

I have found that with COMBINE_DEVICES, you can get some strange feedback occurences. For example:

nBUTTON_ARRAY[]={1,2,3}

ON [dvDEVICE,nBUTTON_ARRAY] will show feedback on all three buttons.
OFF [dvDEVICE,nBUTTON_ARRAY] will NOT always stop feedback on the buttons.

I have pretty much accepted, for myself, that DEV arrays are the way to go. All of the "benefits" of combined devices can be acheived in code within a device array, with a lot more reliability.

Okay, I was going to post a thread about this, but it looks like I can continue here. TurnipTruck, you mentioned above that COMBINE_DEVICES gives you strange feedback, but your example shows an array.
My issue is when I do an array of panels, I can capture the pushes, but if I try to send feedback to the array, it doesn't work.
Example

DEFINE_DEVICE

10128:1:1 = TP_1
10132:1:1 = TP_2
10136:1:1 = TP_3

DEFINE_VARIABLE

DEV TP_ALL[]={TP_1,TP_2,TP_3}

DEFINE_EVENT

BUTTON_EVENT[TP_ALL,1]   // POWER ON
  {
   PUSH:
      {
       ON[RELAY,POWER_ON]    // JUST AN EXAMPLE  
       POWER_ON=1
      }
   }

DEFINE_PROGRAM

[TP_ALL,1] = POWER_ON=1    // THIS DOESN'T WORK

[TP_1,1] = POWER_ON=1        
[TP_2,1] = POWER_ON=1        // THESE WORK
[TP_3,1] = POEWR_ON=1

I've also tried it by sticking virtual devices in there, but the result is always the same. No feedback when sent to a device array.
Am I doing something wrong or is this how it works?

Thanks!

Joe

TurnipTruck

DEFINE_PROGRAM

[TP_ALL,1] = POWER_ON=1    // THIS DOESN'T WORK

How about

[TP_ALL,1] = POWER_ON

You will also need to define POWER_ON as some sort of an integer variable.

TonyAngelo

DHawthorne wrote:

With a single real device, as posted in the example, there is no reason at all to make an array or a combine.

I disagree with this. Even in systems with one panel I use a DEV array for that panel, the reason being that I can then add another control device (like a keypad or handheld) without changing too much code.

DHawthorne

TonyAngelo wrote:

I disagree with this. Even in systems with one panel I use a DEV array for that panel, the reason being that I can then add another control device (like a keypad or handheld) without changing too much code.

I see the point, but I also tend to want to conserve resources (a bit old-school, I guess ... not working with 64K anymore, I have to keep telling myself ...). I find it trivial to change a single panel reference to an array reference if I am upgrading. And besides, I did say there was no reason for an array on a single device, and IMO, prepping for potential multiples is not really a "single" device anymore.

dchristo

Joe wrote:

DEFINE_PROGRAM

[TP_ALL,1] = POWER_ON=1    // THIS DOESN'T WORK

Joe,

I do exactly this in most programs I write, and I've never had a problem with feedback to the array.

--D

richardherman

DEFINE_PROGRAM

[TP_ALL,1] = POWER_ON=1 // THIS DOESN'T WORK


How about :

[TP_ALL,1] = (POWER_ON=1)

I did this more than once without problems.

Richard

Chip Moody

Seriously, like TurnipTruck suggested:

[TP_ALL,1] = POWER_ON

There's no need to add anything else on top of that...

- Chip

NMarkRoberts

Chip, you've been mainlining Halo 3 for quite a while now, are you getting anywhere?

Chip Moody

Well, I not-so-subtly changed my sig recently to reflect the fact that the crown has been passed to Halo 3 from Halo 2.

But if it means anything, yes - I'm currently ranked as a Commander Grade 1 in matchmaking.

- Chip

NMarkRoberts wrote:

Chip, you've been mainlining Halo 3 for quite a while now, are you getting anywhere?

a_riot42

Chip Moody wrote:

Seriously, like TurnipTruck suggested:

[TP_ALL,1] = POWER_ON

There's no need to add anything else on top of that...

- Chip

What does [TP_ALL,1] = POWER_ON=1 give you that [TP_ALL,1] = POWER_ON doesn't?

Its similar to:

if (variable == true) do this
else if (variable == false) do that

instead of 

if (variable) do this
else do that

Joe Hebert

a_riot42 wrote:

What does [TP_ALL,1] = POWER_ON=1 give you that [TP_ALL,1] = POWER_ON doesn't?

There is a difference, subtle as it may be.

The line
[TP_ALL,1] = (POWER_ON=1)
will turn the feedback on if and only if POWER_ON equals 1.


The line
[TP_ALL,1] = POWER_ON
will turn the feedback on if POWER_ON equals anything other than 0 (e.g. 2).

I follow the latter style unless I explicitly need the former.

a_riot42

Joe Hebert wrote:

There is a difference, subtle as it may be.

The line
[TP_ALL,1] = (POWER_ON=1)
will turn the feedback on if and only if POWER_ON equals 1.


The line
[TP_ALL,1] = POWER_ON
will turn the feedback on if POWER_ON equals anything other than 0 (e.g. 2).

I follow the latter style unless I explicitly need the former.

I understand the difference, I guess I just wonder why you would want to break a decades old convention. To my thinking POWER_ON can only have two states, on or not on, and thus could never be equal to anything other than 0 or 1 (or some other positive integer).

GSLogic

a_riot42 wrote:

I understand the difference, I guess I just wonder why you would want to break a decades old convention. To my thinking POWER_ON can only have two states, on or not on, and thus could never be equal to anything other than 0 or 1 (or some other positive integer).

I will sometimes use three states for a projector.
0=off 1=on 2=cooling/warming, this way I can change the button states and block out any pressing when in a cool/warm state.

If it is a small job with only one panel, I'll use some DEFINE_PROGRAM feedback, otherwise I always do feedback on the string return of an ONLINE device.

a_riot42

GSLogic wrote:

I will sometimes use three states for a projector.
0=off 1=on 2=cooling/warming, this way I can change the button states and block out any pressing when in a cool/warm state.

If it is a small job with only one panel, I'll use some DEFINE_PROGRAM feedback, otherwise I always do feedback on the string return of an ONLINE device.

Sure I do that too, but then I would have a variable named POWER or PROJ_STATUS that can have say an ON, OFF and STANDBY state. But I would never have a variable named POWER_ON that has more than two states. That's just confusing to me.
Paul

PyroGuy

On a bit of a tangent for combining panels, I am just about to get into a project with a combined room. Sometimes the dividing wall is open, sometimes closed. There is a panel in each room to operate the projector, screens etc, in each room.

When the door is opened, I need to have both panels mimic each other - on a page showing the combined facilities (ie both screens, projectors, volume etc)

Woud this work...

when the rooms are separate, both panels are independant
when the rooms are open, create a page that offers all the facilities (screens, proj, volume) for both rooms and combine the panels when this page is being used.

When the rooms are separated again, uncombine them.

Thoughts?