AZSlow

Hi Alexey

Thanks very much for your further advice and suggestions.

In my test project I created a Software State 'allow' with 'YES' and 'NO (default)' states.
Then I added an additional (first in the action list) feedback action 'allow NO' - Undefined - final, to each of the hardware controls.

So now when Sonar is loaded, or a project is loaded, there are no feedback outputs for controls I have set this way.  Even when I then change to 'allow YES', there is no memory of the feedback actions.  This is exactly what I needed to achieve and will hugely simplify my PIC coding.

It also allows me to deal with the circumstance where Sonar track slot positions are changed.  My present scheme to deal with this is hugely complicated.

When you get time, could I ask you to have a look at why AZ Controller is not able to process control inputs before a Sonar project is loaded.  If it is a restriction in the Cakewalk API then I'll speak to Mark about it and see if it can be changed.

Best regards
Robert

Hi Robert,

It is just a guess, but it seems like you conditioning "Monitor" Action itself. Block in the Feedback of it instead, f.e. insert first Action in the Feedback section
"Allosfeedback:No" Undefined, final

When you condition Monitor itself, it keeps old value. And when you "unlock" it, it compare current situation with what it had and so triggered. You should let it trigger, but void what it does.

When a project is loaded, many things "appear" (f.e. "Track 1"), so almost all monitors of Sonar parameters are triggered.

Action condition for Monitors make sense, but in different situation. Let say you don't know PIC is connected. You can condition all Monitors which send something to it with "PIC:Online". When you know it is connected you set "Pic:Online" and Monitors will trigger.
Note Conditions for Monitors have "don't monitor till" meaning, not "delay" (they don't remember they wanted trigger).

Alexey.

Hi Alexey
Thank you for the advice.  I will check out your suggested scheme and report back.

I have a related question please:
When Sonar loads a project, there is a 'dump' of all the current control values from AZ to the allocated MIDI output port.

I have tried using Software Sets to block some or all of this 'dump' but I do not properly understand what is happening.

As an example:
I set up a Software set called 'allowfeedback' with two states 'YES' and 'NO'.
I set the default state to 'NO'

I use this Software State as an Action condition on those Feedback Actions I want to block (in my case I am blocking MIDI CC outputs and some SysEx messages)

What I am finding is that these Feedback Actions are blocked but then released as soon as I change the state to 'YES'. (which I have to do at some time in order to have a functional system!)

What I need is to find a way not just to delay the output of this 'dump' but to 'delete' it so it does not appear when I change the state to 'Yes'

Is there a way to make this possible?

Best regards
Robert

Hi Robert,

from what I remember, AZ Controller by itself is "working" even when project is not loaded.
But it can do almost nothing in Sonar.

You can execute something on project load/unload. For that:
* create Software Set "Project" with "Unloaded" (default) and "Loaded".
* create Monitor State "Context", Priority 0, with Feedback:
  "Context:NoProject" - Set State "Project" -> "Not loaded", "set engine state" , "final"
  Set State "Project" -> "Loaded"
* create Monitor State "Project", Priority 1, with Feedback:
  "Project:Loaded" - <do what you want on load>
  "Project:Unloaded" - <do what you want on unload>

Extra "Project" is required because Context switch to Track/Console/Plug-in/NoProject and so will be triggered not only on load/unload.

Let say AZ Controller get something from PIC when there is no project.(I assume Sonar deliver, but I have not tested that for a while...). You can set some State, for example
Set State "SendOnLoad" -> "Yes"
Then in already described scenario, in "Project" Monitor, you
"Project:Loaded", "SendOnLoad:Yes" - <do what you want>
"Project:Loaded" - Set State "SendOnLoad" -> "No", "set engine state"

Using that approach you can do something next time some project is loaded based on MIDI fro Pic.


Alexey.

Hi Alexey

I have a few Logic actions in AZ which I want to trigger before a project is loaded.
The MIDI to trigger these actions would come from my PIC.

Is there any way to configure AZ Controller to make this possible?

Regards
Robert

There is Tracker option in the OSC menu, shortcut F4. The term comes from me and may be it is not the best, means focus tracks changes in the mixer. Sorry if there is already a good term to describe the behavior.

Don't forget to switch it off when operating AOSC since any external changes will auto-navigate throw the interface and can be confusing.

Thank you for this clarification.  Having any changes reported from any means of controlling the mixer would still be awesome.  How does one place Air Access into tracking mode?  I'm assuming this means tracking changes to the mixer rather than "tracking" as in recording. 

I will continue to research using the X-touch with X-air to determine if it will work for our situation.  Unfortunately, the decision regarding the X-Air 18 has already been made.  It was donated to them several months ago. 

AOSC does not support control surfaces on its own. And so AOSC can't define what you control nor reace when you just touch a fader.
The only report you can get is from Tracking mode on AOSC. When some parameter defined in AOSC is changed in the mixer, it will focus corresponding element in AOSC and your screen reader will do the trick.
So if something in X-Air is controllable by X-Touch, you will get corresponding feedback from AOSC. When you change something, not just touch. I think it should work for most parameters, but I never had X-Touch and so don't have real experience.

You connect X-Touch to X-Air. The protocol is not strictly Mackie, Behringer has designed specific approach for the combination.

AOSC Tracking is working for any changes, so you also get report from Behringer app, in case sighted mates are using it.


X32 Producer has 17 strips instead of 9 of X-Touch, so less banks switching during live mixing, apart from other advantages. And the price is not drastically higher then X-Air plus X-Touch combination. Gerad took that way.  If it is not too late, may be you can consider that as well.

Hello, I am so grateful this project exists!!  At first I was very sad when my organization got an X-Air 18, and I worried that I wouldn't be able to mix live sound for them anymore.  But this project showed me that it is, in deed, still possible. 

I have a question though:  I would love to use an X-Touch control surface with physical faders.  Ideally, I'd love to be able to touch a fader and have NVDA report the channel name or number and current level before I move it.  I'd also love for it to confirm when I've muted or unmuted a channel.  I'd also really love to be able to control FX parameters with the control surface when I enter those pages.  Is this something that is currently possible through Air Access 18?  Would I connect the X-touch directly to the mixer, or would I connect it to the Windows laptop / tablet running AOSC and Air Access?  Would it use the Mackey protocol or would I have to do MIDI mapping?  Thanks for any insights you may have, and thanks for your work on the project. 

Hi Alexey
Okay thanks for info.
I'll ask Mark if it's possible to do but if not possible then I'll do it manually each time.
Best regards
Robert