Airlite condition check channel source selector

[andrerotgans]

Hi Bernd,

In our set up with a D&R Airlite mixer we use some exec_command2 conditional checks in the GPIO setup. We do this to ie check the status of the Autoplay, but also some statuses of the different channels on the Airlite. When using fader start, we check for the status of the input selector on the fader. So, when it's on Line input, PFOA (which is using the USB input) does not start.

We use the $(airlitestateXsourcesel) for this, 0 is Line input, 1 is USB input.

However, when doing so, we see that it doesn't work quite as expected. When testing it with a very small script I found out that the Airlite sends the msg to PFOA correct. However, the output of the $(airlitestateXsourcesel) is only changed after you open or close a screen in the GPIO Client. As I understand that this might be not that easy to explain, I've recorded a screen capture to show you whats happening and what I mean.

https://dl.dropboxusercontent.com/u/202 ... 20GPIO.avi

During this recording I've done two things which you can not see on screen:
- changing the source selector on a specific channel
- pressing a button on the Airlite to fire of this check-script

Do we do something wrong, or is this a bug?

best regards,

André

[radio42]

I see what you mean, but that is weird.
There is no reason, why it would only change when you close/reopen the monitor...as I use a complete UI independed thread to get the states back from the Airlite console.

Did that also happen with all the other macros, e.g. the ${airlitestateXon} or the ${airlitestateXcue} ??

[andrerotgans]

Hi Bernd,

Didn't try the other macros, as we only use the sourcesel and the ${cplautoplay} to check for the autoplay status. That one works, the sourcesel is not working, for different faders (so, in the video I've checked for fader 5, but all other faders, same result.)

All conditions are made out of more than one condition (ie is fader on the right input ánd is autoplay turned off, then faderstart will function). But, as you can see, also when using a single condition I've got the same result.

[radio42]

Please also check the other macros. Since I don't own an Airlite we need to eliminate that it is an D&R issue.

[andrerotgans]

Hi Bernd,

not yet. As I also don't have an Airlite, I need to test it at that particular radio stations. Which happens to be 120km's from my residence. So, I need to set that up, either remote (which is quite cumbersome in this particular case, because I need them to press buttons and pull faders) or 'live' when I'm over there.

By the way, in the monitoring tool from the GPI-client, the status change from the Airlite is coming in ok. You see it changing from 1 to 0. So, PFOA is detecting status change from the Airlite for this particular function.

I'll keep you posted about the tests, can take a while!

[radio42]

Any news?

[radio42]

Any news?

[andrerotgans]

hi Bernd,

Not yet, as I have to check if remote (I mentioned that earlier) so I have to pick a moment that works for both parties and tell my friend at the other end exactly what to do/test. Combine that with my normal job which is rather stressful and time-consuming, a rebuilding at home, and you'll get the picture

I'll let you know in this thread.

Best regards,

André

[andrerotgans]

Dear Bernd,

It took a while, but I managed to find time to test it at the radiostation. I've tested the two macros you mentioned, ${airlitestateXon} and ${airlitestateXcue}. Exactly the same result as the $(airlitestateXsourcesel) macro

Best regards,

André

[radio42]

When ALL of them are not working, then I need to go back to D&R and check with them, as then it maybe an issue with their API...