Nion Feedback

ish

Using the same variable (Level_) to send and receive data, is this o.k?
Feels like theres some kind of pushing and pulling going on through the device. What is the best way to send and receive data?

DEFINE_DEVICE
dvTP = 1001:1:1
matrix_dvCLIENT = 0:3:1


DEFINE_VARIABLE

NON_VOLATILE SINTEGER Level_ = -30 //mic 1
NON_VOLATILE SINTEGER Level3 = -30 //mic 1

DEFINE_FUNCTION levelUP() // mic_1
{
Level_++
IF(Level_>0)
Level_ = 0
}
DEFINE_FUNCTION levelDN()// mic_1
{
Level_--
IF(Level_<-100)
Level_ = -100
}
DEFINE_FUNCTION levelUP3()// line_1
{
Level3 ++
IF(Level3 >0)
Level3 = 0
}
DEFINE_FUNCTION levelDN3()// line_1
{
Level3 --
IF(Level3 <-100)
Level3 = -100
}

DEFINE_EVENT
BUTTON_EVENT[dvTP,11] //Media_Matrix volume control mic_1
BUTTON_EVENT[dvTP,12]
BUTTON_EVENT[dvTP,13] // matrix mute
{
PUSH:
{
SWITCH(BUTTON.INPUT.CHANNEL -10)

{
CASE 1:
{
{
To[dvTP,11]
levelUP()
}
SEND_STRING matrix_dvCLIENT,"'controlSet "mic_1_"',ITOA(Level_),$0D"
{
SEND_STRING matrix_dvCLIENT,"'controlSet "micMute_1"',ITOA(0),$0D"
OFF[dvTP,13]
}
}
CASE 2:
{
{
levelDN()
To[dvTP,12]
}
SEND_STRING matrix_dvCLIENT,"'controlSet "mic_1_"',ITOA(Level_),$0D"
SEND_STRING matrix_dvCLIENT,"'controlSet "micMute_1"',ITOA(0),$0D"
OFF[dvTP,13]
}
case 3:
{
IF(![dvTP,13]) // muted
{
SEND_STRING matrix_dvCLIENT,"'controlSet "micMute_1"',ITOA(1),$0D"
}
ELSE
{
SEND_STRING matrix_dvCLIENT,"'controlSet "micMute_1"',ITOA(0),$0D"
}
}
}

}
HOLD[.9, REPEAT]:
{
SWITCH(BUTTON.INPUT.CHANNEL -10)
{
CASE 1:
{
{
LevelUP()
}
SEND_STRING matrix_dvCLIENT,"'controlSet "mic_1_"',ITOA(Level_),$0D"

}
CASE 2:
{
{
LevelDN()
}
SEND_STRING matrix_dvCLIENT,"'controlSet "mic_1_"',ITOA(Level_),$0D"
}
}
}
}
DATA_EVENT [matrix_dvCLIENT]
{
ONLINE:
{
ON[matrix_dvCLIENT,255]
}

OFFLINE:
{
OFF[matrix_dvCLIENT,255]
SEND_COMMAND dvTP,"'^TXT-154,0,'"
ON[dvTP,151]
}
STRING:
{
SELECT
{
(***************************** Levels **************************************)
ACTIVE (FIND_STRING(data.text,'mic_1_',1)):
{
LOCAL_VAR INTEGER i
{
for(i=1;i<length_string(data.text);i++)
remove_string(data.text,'valueIs "mic_1_"',1)
Level_ = ATOL("LEFT_STRING(data.text,5)")
SEND_COMMAND dvTP,"'^TXT-11,0,', ITOA(Level_),'dB'"
}
}
ACTIVE (FIND_STRING(data.text,'line_1_',1)):
{
LOCAL_VAR INTEGER i
{
for(i=1;i<length_string(data.text);i++)
remove_string(data.text,'valueIs "line_1_"',1)
Level3 = ATOL("LEFT_STRING(data.text,5)")
SEND_COMMAND dvTP,"'^TXT-19,0,', ITOA(Level3),'dB'"
}
}

NMarkRoberts

ish wrote:

Using the same variable (Level_) to send and receive data, is this o.k?

I don't think so. You are, as you say, using the variable both to store your required level and also to store feedback as to the last level set. You might get away with it if the timing worked OK, but I can't see why you would want to do that. Do you want to allow level changes prompted some other way? Why are you interpreting the replies at all?

Here's how I write this kind of thing. I keep two values - Requested and Reported. The Requested is bumped up and down by button pushes. The Reported is interpreted from replies or is faked by assuming that a command sent will work. You send a gain command when Requested and Reported differ.

BTW, this line looks wrong:

HOLD[.9, REPEAT]:

I'm surprised that the decimal point compiles, and I wonder what effect it has... that number is tenths of a second, so a strict interpretation of your code would be a hold repeat interval 0.09 of a second, which I doubt you want. 9/10 of a second also seems to long... I usually go with 4, although that assumes the value increment is reasonable; you need about 25 steps from a whisper to a roar.

Spire_Jeff

NMarkRoberts wrote:

BTW, this line looks wrong:

HOLD[.9, REPEAT]:

I'm surprised that the decimal point compiles, and I wonder what effect it has... that number is tenths of a second, so a strict interpretation of your code would be a hold repeat interval 0.09 of a second, which I doubt you want. 9/10 of a second also seems to long... I usually go with 4, although that assumes the value increment is reasonable; you need about 25 steps from a whisper to a roar.

Waits do allow 1/100 second resolution. From the help file:

NetLinx Manual wrote:

NOTE: If greater precision is required, the time parameter can be expressed as a decimal fraction, for example 0.1 to specify a wait time of 1/100th of a second. The range is 0.1 - 0.9.

Timelines let you go to millisecond resolution.

Jeff

NMarkRoberts

Spire_Jeff wrote:

Waits do allow 1/100 second resolution.

Thanks Jeff - that explains why it compiles - but of course not why you would want a repeat at 0.09 of a second.

Spire_Jeff

NMarkRoberts wrote:

Thanks Jeff - that explains why it compiles - but of course not why you would want a repeat at 0.09 of a second.

A couple of things that come to mind right now would be for controlling a stepping motor or precise timing to drive a startup sequence.

Not sure if this would even work, but would be fun to try... Say you have a model train display and you wanted to provide control over a crane via the AMX panel. Using a stepper motor, you could allow precise control and with a little programming, you could prevent the crane from turning too far.

Or maybe for an animatronic display or even a homemade camera pan and tilt base.In fact, I think the timelines were added specifically to address even more precise timing for a specific adventure park's animatronic display as I recall hearing at a training class.


Jeff