SNAPI control and feedback channels

PsyenceFact

For some components, SNAPI specifies a single channel number for both control and feedback. For example, the Volume component uses channel 199 for VOL_MUTE_ON and VOL_MUTE_FB. This seems fine when toggling the mute state by pulsing channel 26 (VOL_MUTE) as a module implementing the volume controller should keep track of the current mute state and set VOL_MUTE_FB as appropriate to be used by other parts of the project (such as updating a UI).

However, I'm using serial port feedback from a hardware device (a Marantz AVR, as it happens) to the module and setting VOL_MUTE_FB whenever "MUON" or "MUOFF" is received.

If I want to set the mute state explicitly to on, I have been setting the VOL_MUTE_ON channel on the virtual device provided by the module.

ON[vdvDevice, VOL_MUTE_ON]

My problem here is that this is the same channel number as the feedback channel so events listening to the feedback channel will be triggered immediately, rather than waiting until a "MUON" message is received from the AVR. If there's a problem and the AVR does not mute, I don't want the feedback channel to be set.

Is this a fundamental problem with the channels concept or (far more likely) am I missing something very obvious?

Andy

ericmedley

I never cross the streams in this case. I use the mute feedback channel as strictly feedback. I track it's sate and only use the toggle channel and hit it based on the condition of the feedback. Ex. Don't pulse the mute toggle to mute if it's already muted. Another approach would be to use the Passthru And send mute/up mute commands discretely and skip the toggle channel altogether.

trav

translate_device()

Sounds like you need http://www.amxforums.com/showthread.php?1926-The-not-documentary-function/page2&highlight=translate_device to consult that thread.

It works well so you can set feedback channels (SNAPI) within your module on the vdv so your main.axs can use those, without then triggering anything within your module that is listening for a change on that channel/level/thingy.

PsyenceFact

Thanks for the input folks!

I've had a go with the method suggested in trav's link and it seems to do exactly what I want. I'm still keen to know the "official" AMX version of how to handle such situations though.

Andy

nicholasjames

PsyenceFact wrote: »

Thanks for the input folks!

I've had a go with the method suggested in trav's link and it seems to do exactly what I want. I'm still keen to know the "official" AMX version of how to handle such situations though.

Andy

In my experience with AMX, it's either Eric's solution, or let the Duet module handle it. Duet can do essentially what TRANSLATE_DEVICE does (keep in mind TRANSLATE_DEVICE isn't officially supported by AMX).

My preferred solution is to use SEND_COMMANDS to "request" the mute and only use the Channel as your official button feedback once the device responds.

GregG

The way I prefer for basic netlinx modules is to send commands _in_ to a virtual and listen for strings back _out_.

So I send something like send_command vdvDSP,'MUTE-1:T' to toggle mute on fader 1 (I set up the info about the faders IDs when the virtual devices come online, 1 would just be the index I arbitrarily gave the first fader I'm controlling)

Then I'll get back in the string: data event for vdvDSP either 'MUTE-1:1' or 'MUTE-1:0' and I set feedback with that.

You can also write the command section in the module to accept forced assigns like 'MUTE-1:1' so you can handle "mute all" syncs and stuff.

If you want to use channels you can do commands to the vdv channels, and put up feedback on the real serial port channels

Dennis E.

Simple Solution !

Just set the Virtual device as
37865 - 40999 Module Virtual Device range (MVD)


Then it won't have any EVENT loopback inside the module.
/Dennis