Premise Please help: Automation browser interworkings of audio.volume

[etc6849]

I ran into an interesting dilemma last night. I am trying to create a subwoofer driver that uses IR communications. The sub has three properties similar to volume: level, low pass and phase.

I was able to create a new class and manually level, low pass and phase as percent properties.

The problem is this: it is possible for someone to manually change the level (and etc) at the sub. For example, someone could lower the level manually at the sub and Premise would still think the level is 100%. When this happens, if the level property is already at 100% and you hit the up button in the automation browser, the on property change script does not fire since the property has not changed. I use the level property change script to send an IR continuous command by toggling continuousCommand between the associated command object and Nothing. This works great, but again quits working at 0% and 100% and I want it to keep firing at these values when the automation browser button is pushed. The button triggering the property change script is the ramp method called by the automation browser as I've defined the appropriate selectors and controls. For the composite control, I'm using the Ramp Button type.

What is interesting is if I just inherent the audio class, volume does exactly what I want! It keeps going even when volume is 100% or 0%! This leads me to believe audio.Volume is doing some special event triggering beyond normal on change scripts. I'm seeking for any thoughts on what you think volume might be doing internally to send the IR commands. I know it toggles continuousCommand as you can see this change when you change volume. I know automation browser is only using the ramp method to initiate volume's property change. However, there must be hidden code I'm not seeing that manipulates the ContinuousCommand property for the IR output port and I really would like to know what that would be...

 

[mustangcoupe]

I ran into an interesting dilemma last night. I am trying to create a subwoofer driver that uses IR communications. The sub has three properties similar to volume: level, low pass and phase.

I was able to create a new class and manually level, low pass and phase as percent properties.

The problem is this: it is possible for someone to manually change the level (and etc) at the sub. For example, someone could lower the level manually at the sub and Premise would still think the level is 100%. When this happens, if the level property is already at 100% and you hit the up button in the automation browser, the on property change script does not fire since the property has not changed. I use the level property change script to send an IR continuous command by toggling continuousCommand between the associated command object and Nothing. This works great, but again quits working at 0% and 100% and I want it to keep firing at these values when the automation browser button is pushed. The button triggering the property change script is the ramp method called by the automation browser as I've defined the appropriate selectors and controls. For the composite control, I'm using the Ramp Button type.

What is interesting is if I just inherent the audio class, volume does exactly what I want! It keeps going even when volume is 100% or 0%! This leads me to believe audio.Volume is doing some special event triggering beyond normal on change scripts. I'm seeking for any thoughts on what you think volume might be doing internally to send the IR commands. I know it toggles continuousCommand as you can see this change when you change volume. I know automation browser is only using the ramp method to initiate volume's property change. However, there must be hidden code I'm not seeing that manipulates the ContinuousCommand property for the IR output port and I really would like to know what that would be...

Not knowing Premise, or having worked with it.. can you have your button set the premise value to something other then 100% when the button is pressed
button press event would not actually drive the property, but set a value then run the property? Im not sure but it might work

 

[etc6849]

Yes, you are exactly right. You can set the percent property to be momentary and not persistant, then set some value like 50% as the default value. However, this will not allow for the press and hold action of the RampButton as the level quickly reaches 50% again and action stops after that so the onchange script is not triggered continuously (as it is when you hold a volume button down).

 

[123]

A property's state remains unchanged if the requested state is identical to the current state. For example, if Powerstate is currently True, requesting it to change to True, using Powerstate=True or this.SetValue "Powerstate", True, will not trigger a property-change transaction. You'd have to use this.SetValueForced "Powerstate", True to force a property-change transaction.

You reported that the Ramp Button appears to respect this paradigm whereas the Audio class's Volume property does not. Could you direct me to examples of this behaviour in Premise Browser? Let me know what existing Home objects I need to throw together so that I can see the contrasting behaviours.

 

[etc6849]

Thanks 123. It's getting late here, but I'll post an easy to follow example tomorrow night complete with home buttons. In the mean time, incase you are curious the rampbuttons found here seem to exhibit the strange behavoir: sys://Schema/Modules/Plugins/ControlsLibrary/BasicAudioVideo/DeviceAudio.

Have a good night,

Ellery

 

[123]

Let's begin our trip through AutomationBrowser's code ...

The RampButton class is defined in: Modules/AutomationBrowser/ControlPanelManager/Classes/RampButton. If you explore its Render method it contains the following code:

Output = ""

Output = Output & "<BUTTON class=""ImageButton"" "
Output = Output & "ondblclick=""OnRampDoubleClick();"" "
Output = Output & "onmouseout=""OnRampMouseOut();"" "
Output = Output & "onmouseup=""OnRampMouseUp();"" "
Output = Output & "onmousedown=""OnRampMouseDown('RampIt', '" & this.ObjectID & "');""><IMG SRC='" & this.ObjectID & "!Image'></BUTTON>" & vbcrlf

method.Output = Output

The important line is the one containing the "onmousedown" event. It calls RampButton's RampIt method which looks like this:

set device = nothing
set curLoc = sysevent.ClientSession.CurrentLocation

if curLoc.IsOfExplicitType("sys://Schema/Device/AudioVideo/MediaZone") then
	set device = curLoc
else
	if this.Parent.Path = "sys://Schema/Modules/Plugins/ControlsLibrary/BasicAudioVideo/DeviceAudio" then
		set device = curLoc
	else
		set homeDevice = GetHomeLevelDevice(curLoc)
		if not homeDevice is nothing then
			set device = homeDevice.Parent
		end if
	end if
end if

if not device is nothing then
	if method.RampType = "Stop" then
		device.RampProperty this.TargetProperty, eRampTypeStop
	else
		device.RampProperty this.TargetProperty, this.RampType
	end if
end if

The first thing RampIt does is determine what kind of object is calling it (i.e. sysevent.ClientSession.CurrentLocation). It tries to determine if "it" is a MediaZone or if the parent object is DeviceAudio. If neither is true, it uses the GetHomeLevelDevice function (defined in: Modules/AutomationBrowser/MediaZonePanel/GlobalScripts/Global) to determine what "it" is. When RampIt finds "it", it calls the object's RampProperty method.

So at the end of our journey, we find that RampButton will always call the object's RampProperty method. Yet, your custom control and DeviceAudio use the same RampButton class but do not behave the same way (when they reach a value of 0 or 100). Hmm.

 

[etc6849]

123, you are exactly right and this is what I thought too. I see the same code as you using the break at next statement and the step in buttons in builder.

Give the simple TV driver I've attached a try and see though. You'll need to add a TV to home and link the tv to an IR port (I used the GC-100 add in).

Some strange behavior: You'll be able to set the devices audio to 100% using the mouse, then hold down the volume up button. You'll see the device property called continuous command flash the IR command object as you hold the button down. Hold the TV volume button in the automation browser down for a really long time, the continuousCommand property will continue to flash no matter what the volume level is. My question is where is the code that is causing the IR command to be transmitted regardless of volume level?

What is interesting, is this doesn't update the Audio level, but sends the command. However, if you delete the IR codes I've added for volume, then try the button it does update the Audio volume. I believe this functionality is added only the Audio class and is not part of the percent property class that I can create manually. This may have been done to improve ease of use, but I really would like to see the code behind it.

PS: I just made the TV module using the wizard. No scripting or anything.

 

[123]

Thanks for the TV module. I used Premise's Transaction Viewer to observe the operation of the Volume control. There are two Volume controls in the TV's UI and they behave differently.

Referring to the attached image, by repeatedly clicking the "+" Master Volume button, I raised the TV's Volume property to 100%. Additional button clicks will not generate additional transactions (i.e. Volume has reached its max value).

The other "+" Volume button appears to work differently. Clicking it will generate a completely different transaction "ContinuousCommand, VolumeIncrease". You can click as many times as you want and it will always initiate a transaction. I suspect this is the behaviour you want for your custom control.

 

[123]

Check out: Modules/Plugins/Selectors/AudioVideo/AV_Components/Television

1. Under TV you'll find "Audio". It represents the "DeviceAudio" CompositeControl. In the TV's UI, this is the lower set of volume controls
2. You'll also find "MasterVolume". It represents the ""MediaZoneAudio" CompositeControl. In the TV's UI, this is the upper set of volume controls

The mysterious part is that both DeviceAudio and MediaZoneAudio are based on RampButtons. You'd expect them to behave identically but they do not.

I think the key differentiator is the fact that the TV driver contains Commands (see the attached image). These Commands must override DeviceAudio's default behaviour. The TV driver contains a Volume Increase command and this must be what DeviceAudio uses when requested to increase the TV's Volume. Try adding Commands to your custom driver (copy/paste them from the TV driver).

 

[etc6849]

Thanks 123 for looking at this! Atleast now I know I'm not crazy

I tried that before by adding the CommandControl class to my custom driver and adding an infrared code. It behaves like a ramp property should.

If you add a percent property to the TV module (and link it to a copy of the device audio button container), you'll see it does work the same way.

Although, I already modified the driver to use the PressAndHold button type that you showed me before and posted it, I would really would like to understand what is going on better than I do. To think and I really thought I was starting to understand Premise

 

[123]

FWIW, if you delete the Volume Increase and Volume Decrease Commands from the TV driver, the lower set of volume controls will revert to behaving like the upper set of volume controls (i.e. range is limited to 0-100).

It appears that if your driver contains Commands (for Volume control), the associated object's Volume controls will be unconstrained by the 0-100 range limit.

 

[etc6849]

Interesting. I tried to find "Commands." It appears this is a hidden class. Any way to unhide it and all other hidden objects? See attached pictures. To view a hidden object, apparently Builder's explorer flashes very fast past the object when you control+left click to it. However, it appears you can click back and it appears then. I had no idea Premise was hiding certain classes from me (although I did know about checking the virtual property so that I can see unhidden classes when I browse)!

On the TV driver, I deleted the CommandControl inheritance (which is also called generic devices). CommandControl inherits from "Commands." After I deleted it, I could no longer add TV as a device. When I added it back (by copying from another driver), I could once again add TV as a device.

I also found a class called Command that might be more relevant, but I couldn't find how it is inherited by the TV class. Found here: sys://Schema/System/Command; pic is also attached.

 

[etc6849]

PS: I really like the use of the transaction viewer; thanks for showing me that. I'd never clicked it before!