Channel_Event arrays and REBUILD_EVENTS()

npepper

Ok, given the annoying fact that the PrecisLT w/ DSP 18x18 does not have a module for it that would make it even remotely useful in a multi-zone audio situation, I am writing my own module so that volume ramp can be used by more than one zone at a time. During runtime I am creating an array with all of the zones (18) in the device and then running a REBUILD_EVENT(). Defining a channel event further down in the program with this array does not ever fire an event. Am I missing something with the channel events, here is my code snipped below:

DEFINE_START

CALL 'INIT_COMM'

{
	vdvALLZONES[1] = vdvDEV
	vdvALLZONES[2] = vdvDEV.NUMBER:2:vdvDEV.SYSTEM
	vdvALLZONES[3] = vdvDEV.NUMBER:3:vdvDEV.SYSTEM
	vdvALLZONES[4] = vdvDEV.NUMBER:4:vdvDEV.SYSTEM
	vdvALLZONES[5] = vdvDEV.NUMBER:5:vdvDEV.SYSTEM
	vdvALLZONES[6] = vdvDEV.NUMBER:6:vdvDEV.SYSTEM
	vdvALLZONES[7] = vdvDEV.NUMBER:7:vdvDEV.SYSTEM
	vdvALLZONES[8] = vdvDEV.NUMBER:8:vdvDEV.SYSTEM
	vdvALLZONES[9] = vdvDEV.NUMBER:9:vdvDEV.SYSTEM
	vdvALLZONES[10] = vdvDEV.NUMBER:10:vdvDEV.SYSTEM
	vdvALLZONES[11] = vdvDEV.NUMBER:11:vdvDEV.SYSTEM
	vdvALLZONES[12] = vdvDEV.NUMBER:12:vdvDEV.SYSTEM
	vdvALLZONES[13] = vdvDEV.NUMBER:13:vdvDEV.SYSTEM
	vdvALLZONES[14] = vdvDEV.NUMBER:14:vdvDEV.SYSTEM
	vdvALLZONES[15] = vdvDEV.NUMBER:15:vdvDEV.SYSTEM
	vdvALLZONES[16] = vdvDEV.NUMBER:16:vdvDEV.SYSTEM
	vdvALLZONES[17] = vdvDEV.NUMBER:17:vdvDEV.SYSTEM
	vdvALLZONES[18] = vdvDEV.NUMBER:18:vdvDEV.SYSTEM

	REBUILD_EVENT()
}

DEFINE_EVENT

CHANNEL_EVENT[vdvDEV, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:2:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:3:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:4:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:5:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:6:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:7:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:8:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:9:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:10:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:11:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:12:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:13:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:14:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:15:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:16:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:17:vdvDEV.SYSTEM, chnVOLUME]
CHANNEL_EVENT[vdvDEV.NUMBER:18:vdvDEV.SYSTEM, chnVOLUME]
{
        //This works fine
}

CHANNEL_EVENT[vdvALLZONES, chnSRC_SEL]
{
      // This does not
}

I am a little confused, because I am following the procedure that is supposed to work, but the second channel event form does not work?

Nick P

REBUILD_EVENT

try assigning this way:

vdvMyArr[] = {vdvMyDev1, vdvMyDev2, ...}

DHawthorne

I think there is a question here whether event tables get built before DEFINE_START runs. If they do not, your REBUILD_EVENTS operation is not going to work because the the events haven't been defined yet.

If it's not that, I would be willing to bet it's some other wonky start-up timing issue.

ericmedley

The Presis is not a difficult box to program. The protocol is very straight forward. It took me no time at all to write it. It definitely fits into the ' simple enough to skip using the module' category, IMHO

alexanbo

Did you do a SET_VIRTUAL_PORT on vdvdev? By default virtual devices only have one port and you need to tell them if they have more.

By the way is it just me or if you're doing a multi-room audio system, wouldn't you rather send commands like "zone 2 vol up" rather then mucking about with virtual devices and channels.

npepper

More

The problem with the first replly

vdvMyArr[] = {xxx, xxx....}

is that that will work with constant devices, such as defined in the main program or such. However, since this is a module, the device is different every time, so I need to declare the virtual ports as a variable.

You are correct in saying the Precis is not very difficult to operate, however its more of a principle thing to cut down on the code in future modules (and knowledge seeking). I really like using arrays of everything when it comes to defining events.

I did not use SET_VIRTUAL_PORT, thank you for pointing out that command, I'll look it up.

The way that the base program I use was written, is that every aspect of the program is in an array (zones, touchpanels, devices, volumes, lights, hvac, etc.), and all events run through a few BUTTON_EVENT functions. So while sending a "zone 2 vol up" command is very easy to do, it doesn't fit in the program that way. The volume up command is something like:

BUTTON_EVENT [dvALLCONTROLS, butVOL]
{
....
     TO[BUTTON.INPUT]
     nVOL = mapVOLDEV[tpINFO[TP].curZONE][znZONE[tpINFO[TP].curZONE].curDEV]
     TO[vdvVOLALL[nVOL],24]
....
}

While that is a little complicated to follow, it makes adding interfaces or sources or zones or devices as easy as adding an element in an array.

While I can easily define multiple channel events just like in the original snippet of code, my ultimate goal is to have everything referenced in arrays so that all it takes to create a full system is to modify the arrays while the guts are in an include.

Not being able to use dynamic events has puzzled me for a while, but now its time to figure it out.

Thanks for all of the replies!

Nick P

alexanbo

I find the command model allows more flexibility. Some devices that control volume don't generate button events. Controlling volume in multiple zones at once from one control device is easier using commands. Not all zones have their volume controlled from the centralized mux. Using commands makes it easier I've found to route the command to a secondary volume control device like a receiver.

Of course it could be I've been programming since before they introduced the channel/button model and that's why I find it easier to use commands.

npepper

alexanbo wrote:

I find the command model allows more flexibility. Some devices that control volume don't generate button events. Controlling volume in multiple zones at once from one control device is easier using commands. Not all zones have their volume controlled from the centralized mux. Using commands makes it easier I've found to route the command to a secondary volume control device like a receiver.

Of course it could be I've been programming since before they introduced the channel/button model and that's why I find it easier to use commands.

I myself am relatively new to the AMX world, but I'm not sure if I could program a system without that type of channel/button model. It doesn't seem like a very powerful language without it.

Part of the problem that I am running into is controlling multiple zones at once using channels instead of commands, as every module we use has to be rewritten or wrapped in a virtual device again. I've had to set the modules to look for the volume +/- channels in the mainline of the module to get it to work successfully.

Although more confusing, with every volume device having a module that works with the channel method, it has been pretty painless making an array that holds a reference to a DEV for each device in each zone.

DHawthorne

I often prefer the SEND_COMMAND paradigm. There are times when a button or channel event just don't make sense. I've said this in other threads: don't decide one way is better and stubbornly cling to it when in fact the other way might suit the current situation.

I utterly despise it when I am using someone else's module, and they have forced me to their paradigm. Here's an example: switching inputs on a receiver. When a source is selected, I want the receiver to come on, the source to change, control to switch over, the display to come on if it's a video source, and any number of other things to happen. That forces me to use a DO_PUSH if the receiver module only uses channel events. I've got no real problem with that in and of itself, but it's not very easy to read six months later. Just what am I calling with DO_PUSH(dvReceiverPanel, 3) anyway?? I would far rather use SEND_COMMAND vdvReceiver, "'INPUT=DVD'". This is even more true for something like matrix switches ... it makes no sense at all for me to have to build a grid of buttons and figure out which one is doing what, when SEND_COMMAND vdvMatrix, "'SWITCH=1:2'" is perfectly appropriate.

Similarly, when doing something like chaning surround modes, a send_command is overly annoying, because of feedback. I have to send the command, and parse the return; in that case a button channel that follows the mode is more appropriate.

When I write a module, I use both. I use channels and levels when appropriate, and I always have a command handler for the stuff that is just easier to do that way.