Issues With Modules

dvTP1	=	128:1:1		/// Master Bedroom Touch Panel
dvTP2	=	132:1:1		/// Media Room Touch Panel
dvTP3	=	136:1:1		/// Kitchen Touch Panel

arqTP1	=	129:1:1		/// ReQuest TP
arqTP2	=	133:1:1		/// ReQuest TP
arqTP3	=	137:1:1		/// ReQuest TP

Are there just three touch panels or six? The above would indicate six but I'm thinking you only have three and the arq's should be ports on the TP's not there own TP.

dvTP1	=	128:1:1		/// Master Bedroom Touch Panel
dvTP2	=	132:1:1		/// Media Room Touch Panel
dvTP3	=	136:1:1		/// Kitchen Touch Panel

arqTP1	=	128:2:1		/// ReQuest TP
arqTP2	=	132:2:1		/// ReQuest TP
arqTP3	=	136:2:1		/// ReQuest TP

Ondrovic,

You are doing it correctly. Based on the addresses, you are using the older G3 panels which don't have the options of different ports. Each touchpanel has the ability to be 1-4 different devices with I think it was 256 channels per device.

The new G4 touchpanels are much nicer and allow you much more flexibility. The graphics options are also a LOT better

Jeff

ondrovic wrote:

Anyone have any ideas on where to start? I have never written a module file with a seperate comm / touchpanel files?

Should I do it as include files?

Thanks for the guidance

To conform to the model AMX endorses, you should write two different modules. You should pass your Comm module the port the device is on, and a virtual device you define in your main program.
You should pass your UI module a touchpanel, and the same virtual device you used for the Comm module, in addition to the channel sets and address sets and whatever else you feel like sending it. That way, if you need to add a touchpanel, you just define another instance of the UI module with another touchpanel.

example

DEFINE_MODULE 'VRQ Comm v1_0_2' VRQ_Comm(dv_VRQ, vdv_VRQ, VRQ_IP, VRQ_PORT, (* other stuff *))
DEFINE_MODULE 'VRQ TP UI v1_0_2' VRQ_TP_1 (dv_VRQ_TP1, vdv_VRQ, (* other stuff *)

One thing I've noticed if you're adding multiple instances of the same Module they have to be one after another or it causes problems

For instance this is good

Define_module 'X' mdl1(vdvDEV,dvDEV)
Define_module 'X' mdl2(vdvDEV,dvDEV)
Define_module 'Y' mdl3(vdvDEV,dvDEV)

This is bad

Define_module 'X' mdl1(vdvDEV,dvDEV)
Define_module 'Y' mdl2(vdvDEV,dvDEV)
Define_module 'X' mdl3(vdvDEV,dvDEV)

And of course each instance of the same module needs an unique identifier.

alexanbo wrote:

One thing I've noticed if you're adding multiple instances of the same Module they have to be one after another or it causes problems

For instance this is good

Define_module 'X' mdl1(vdvDEV,dvDEV)
Define_module 'X' mdl2(vdvDEV,dvDEV)
Define_module 'Y' mdl3(vdvDEV,dvDEV)

This is bad

Define_module 'X' mdl1(vdvDEV,dvDEV)
Define_module 'Y' mdl2(vdvDEV,dvDEV)
Define_module 'X' mdl3(vdvDEV,dvDEV)

And of course each instance of the same module needs an unique identifier.

When I read this I thought "good thing I always do that" but I've just realised that my current project groups modules by room not by name, so it breaks this rule, and it works fine.

Alexanbo, what problems have you observed?

Tech note 527 refers

I just found tech note 527 from 2002 that says that you must declare modules in bunches. It seems this advice is now out of date.

Kari wrote:

I have been creating modules for mixers to control volume/mute status. Usually I'll add one instance for each volume bar I have. This is because I want to reference a particular volume input/output/processing bus/block of the device.

Here's how I do this, and never ever let it be said that controlling volume is easy. It seems to me that every installation does it completely differently. I always do volume control last cos it's hard work and every job I do seems to be very different from the last one.

For every physical device that has volume control write a driver module which, among other things, translates a standard volume control command into whatever that device requires. It can accept this command from anywhere. It knows nothing about the system, just this one device. You can reuse this module in every installation that uses this equipment.

For each room write a control module which runs the UI and does everything except volume control, apart from passing on volume button pushes and sending system start / stop commands.

Enumerate the different volume controls somehow, one for each slider / up / down seen on the UI. That could be one per room, or one per zone, or 1 = Master volume and 2 = Mic vol and 3 = "Whichever AV device is currently selected". It totally depends on the nature of the system.

Write a generic volume control module that controls an array of volumes and knows all about the nuances of volume control for each controlled volume:

Minimum permitted volume
Maximum permitted volume
Default volume
Current volume
Number of steps from min to max
Number of increments per second
Maximum ramping time to prevent runaway
Automated unmuting on volume change
...and so it goes on

This module knows nothing about the system, and calls an included volume-setting routine for all system-specific knowledge. You can reuse this module in every installation, and you can make it as clever as you like. You could use multiple instantiation of a module which controls just one volume channel, but I haven't, not sure why!

Finally, write an include file that knows all about volume control in this system, and when asked by the generic volume control module to set the volume for particular enumerated volume channel, sends the right generic command to the right device module. This code turns out to be very easy to write after you have made all of the investments listed above!