Volume target Crosspoint layer

[pvladi]

Dear team, I have developed a very similar framework to yours, but more extensive, and more flexible. We have been using it for years in our projects, but we were going to rewrite it from scratch, but may instead contribute to your project, and keep it open source.

To start with, in our framework we had volume crosspoint targets. We found that on most projects not all the audio control is done though a central switcher, and there are always one or two amps in various rooms, and audio coming from the TVs or sound bars in others. Additionally, some rooms had ceiling speakers for central audio, but video was coming from the TVs, so separate sources required separate volume controls.

To this end, we had multiple interchangeable modules for volume control, SWAMP, BIPAD8, generic amp with analog slider, and discrete volume (+/-/mute) Each volume would translate standard 0-100% analog values to whatever the range that device accepts, meaning that control modules did not need to change.

The room switcher module had a parameter matrix, in the style off Source 01 Name Source 01 Control XP ID Source 01 Volume XP ID Source 01 Icon Source 01 Subpage This allows for each source selection to have it's own volume control if needed.

The remote / panel module would receive XP ID of the target volume module through the room module, and then connect to the volume module, and receive the parameters through digital joins, such as "display slider", "Display surround sound mode selection buttons" etc.

[adelyte-chris]

Thank you very much for raising this issue. We welcome any and every contribution you and your team can make.

Crescendo has a crosspoint architecture that I believe leads to a similar result. Please review the crosspoint architecture and notes below and correct me if I am wrong.

Similarities

• Neither framework is dependent on a central matrix switcher or audio/video distribution of any sort.
• Both frameworks support local and central sources.
• Both frameworks allow an interface to control several switchers working together (including televisions, amplifiers, and sound bars). With Crescendo, interfaces control switchers through rooms.
• Both frameworks allow different sources to be heard on different subzones within the same room (e.g. ceiling speakers for music and television speakers for shows).
• Both frameworks provide for different volume control types (e.g. volume slider or up/down buttons).

Key Difference

Audio and video subzones are handled with logic internal to the Room module, which uses metadata from:

• Source to determine which zone should handle volume control, and
• Switcher to determine what type of volume control is available (absolute or relative).

The Switcher module also has a parameter for source selections that should trigger a power off. By default, an end user can watch one thing and listen to another simply by selecting a video source and then an audio source: the video switchers do not respond to the audio source but the audio switchers do respond.

Exception

The only case we've encountered where the Crescendo data model was insufficient was complex "rooms" with multiple video and audio zones—think sports bars or video production labs. In those cases, we have created a logical room for each zone that required independent control and customized the graphics for easy control.

[pvladi]

Chris, perhaps I was not able to express myself properly. Our framework is also crosspoint based, and we have solved the issue of the "sports bar"

Our room controller module has parameters for each source, Device ID (for play/stop etc) and Volume ID

So when a room is on source 1, which is a TV, for example, the Volume ID analog join travels via crosspoint to the volume client than then connects to TVs basic volume module When a room is on source 2, which are ceiling speakers, the Volume ID analog is changed, and volume client connects to the SWAMP volume module. and so on.

Thus any combination is supported.

In fact, we done the same system for lights and HVAC, as one room can have AC, whilst another one can have underfloor heating - and one room can have Crestron lights, whilst another can have Lutron, one load can be slider controlled, another on/off only - so having ID parameters for the modules to then connect to means that we have a robust and scalable network for any combinations of hardware

[adelyte-chris]

Your flowchart was very helpful. Thank you.

I believe I understand your architecture in the abstract, but I would like to see a concrete example. Could you scrub a working program of identifiable information and either attach it to this issue or email it to me?