AZSlow

1) all monitors, except of type "Timer Once", are checked on AZ Controller activation. Checked means Logic block containing them is executed in "Monitor checking" mode. And if it comes to Monitor itself (the execution is not abandoned by Action flagged Final and Conditions for Monitor Action itself are ok, it is triggered. In other words, AZ Controller knows when Monitored entity is "undefined". In case of "Context", initial value is "undefined", "NoProject" is a different State and it will be triggered.

You get that monitor triggered (assuming Logic Actions are not preventing that): (1) with "NoProject" (2) "Console"/"Track"/"Plugin" when the project is loaded (2...n) when you change focus between "Console"/"Track"/"Plugin" (n+1) with "NoProject" when you close the project (also in case that is implicit during Sonar exit).

My proposal for "Project" Set is to avoid (2..n) triggers, which will simplify your preset.

(2) everything you set in Logic is executed in "Monitor checking" mode. It is very close to feedback mode, but "Set engine state" flag is working differently from Feedback. All initial states are "real", just changes of them during "Monitor checking" are discarded (after Monitor execution, if triggered, so changes can be "saved" explicitly in Feedback).

Context:NoProject will work correctly during any "Monitor checking". In other words, "Context"  (and all other system states) is  changed by AZ Controller PRIOR executing any "Monitor checking".

Hi again Alexey
As I'll have some thinking time when I'm travelling, it would be really helpful if you could clarify some points about the functioning of the Software Set 'Context'.

1)
If I set up a logic action: 'Monitor state', 'Context'
Then some kind of Feedback event.
Will the feedback event be triggered by any change of the 'Context' state?
To ask the question another way:
If I load Sonar (but not yet a project), is there would this trigger a change of 'Context' 'Monitor State'?
If I then load a project, does this trigger a further change of 'Context' 'Monitor State'?

2)
When I set an action condition using 'Context (NoProject) as part of a control Logic,
Is AZ Controller able to differentiate between no project loaded and project loaded?  Or is it only sensing a change of state of 'Context'?

Regards
Robert

Hi Alexey
Thanks for the suggestions.  I'll do some updates and let you know how it goes.
I'm off travelling for a week so it will have to be when I get back.
Best regards
Robert

"Parameter Value Monitor" need parameter... If it is not defined in the same logic control, it takes whatever was set before. That can produce random results.
So I guess you have not listed your real "Hello" actions.

If you want send just one time, use "Context" Set Monitor. But it included several States which can be switched while project is open, you you need extra set,
let say "Project" with "Opened"  and "Closed". Then:
In "Context" monitor:
Context:NoProject Project:Opened -> Set Project Closed (set engine state, final)
Context:NoProject -> Undefined (final)
# for all other states
Project:Closed -> Set Project Opened (set engine state, final)

Then you need "Project" set monitor, but it will only trigger when project is opened or closed, so you can:
Project:Opened -> ... send hello to pic ...
Project:Closed -> ... send goodby to pic ...
# or  Project:Closed Device:Online -> ...send goodby... with "race case" protection in Hello reply processing (when Project:Closed)
Project:Closed -> Set Device Offline

It may sense to give "Context" monitor highest priority and "Project" monitor next to highest, so they are executed in correct order in the same cycle and before any "Value" monitors.

Hi Alexey

I have the handshaking working with my two PICs and two instances of AZ Controller (RECORD and REPLAY).

I have one problem.

When I load Sonar, but before loading a project, the two instances of AZ Controller are active.  This is good!

Then I load a project and I send 'Hello' message to PIC.  I send just one message rather than using slow timer which just clutters up PIC input.

'Hello' message
Logic actions:
'Context:NoProject' - Undefined*
'Device Offline' - Reset Hello: : Parameter Value Monitor
'Device:Offline' - Parameter Value Monitor

Feeback
-Ch:15 CC9 Value(14bit): 380

I respond from the PIC to set 'Device:Online'
All is good!

Here is the issue:
I close the project
I use 'Device Online' - State Monitor to send shut down message to both PICs.
The two PICs are put in standby mode.
The two instances of AZ Controller become inactive.

However, when I load the next project (Sonar is still open), there is no trigger of the 'Hello' message, even though the AZ Controller instances become active again.

Can you help with this please.

Regards
Robert

I have checked.

Connect/Disconnect methods of surface DLL are not related to "surface connection". It is to make a "connection" between Sonar and DLL, in other words "Connect" means "Hey, Sonar is ready for communication". And "Disconnect" means "Please no longer communicate with me".

So, it is about "programming interfaces" communication. In case you know a bit Windows programming, surface DLL is COM. In this method all surface DLLs (including AZ Controller) get pointers to "Sonar interfaces", and finally can do some initialization (access information from Sonar).

So you should not do anything in PIC for that.

If you want send "Disconnect" to PIC, you can monitor Context and check for "NoProject" state. AZ Controller does "final monitor loop" in Disconnect method, to be sure you have a change to send "Goodby" if required.
Obviously you can't expect there will be a chance to receive reply in this case.
Long time ago I have decided there is no reason to process "AZ Controller is removed from surfaces list", "Sonar is closed", "Project is closed" separately. So all that just trigger "NoProject" in Context (the project is always closed when Sonar is closing, if AZ Controller is removed it will be unable to send anything, without loaded project AZ Controller can't do much, if I remember correctly even surface idle is not called).

Hi Alexey

Now I understood your line:
'Context':'NoProject' Undefined * (final)

Sorry to be so slow in my understanding!

Now I have working handshaking exactly as you described, that is:
 * if there is no project, nothing will happen
 * if there is project and we are 'Offline' (initially, but can be set later), AZ Controller will periodically send "Hello"
 * in case AZ Controller receives reply and project is loaded, it change the state to 'Online'.

When you have time, could you explain Mark's comment:

'Sonar calls the Connect method on the DLL, and the DLL should return almost immediately with a success code.

If you've got some sort of a handshake, the connect method typically sends a short MIDI message to your device, but should always return immediately - otherwise Sonar will wait for the Connect method. to complete. You definitely don't want this.

Your device may then respond, but this should be handled by the control surface DLL as it would handle any message coming in on MIDI IN.  The connect method should never wait for a reply.'

So my question from Mark's comment is:
Does AZ controller provide the immediate response to Sonar's call (Connect method) on the DLL?
Or is this something I have to do from my PIC?

Best regards
Robert

Just to say I was able to set up the 'Device' Set ('Offline' (default), 'Online').

And I was able to set up Logic, Action, Monitor, Timer, Slow, to output a 'Hello' message (every 300ms) which is great.

The only line from your previous notes which I don't understand is:
 'Context':'NoProject' Undefined * (final)

I can see there is a system defined Software State called 'Context' but I do not understand how you planned to use it within the handshaking protocol?

Regards
Robert

Hi Alexey

No problem.  When you have some time to have a look at my proposed scheme, let me know and we can hopefully sort out a practical solution.

I am sure that Sonar is sending some MIDI messages (in my case via AZ Controller) during the Sonar load period (so I mean before a project is loaded).  I don't know whether AZ Controller is active sufficiently early to prevent these messages?  Hopefully it will be.

Regards
Robert

Sorry, I am a bit busy at the moment to dive into that.

Theoretically I can check if I can add some logic to "Connect". But I don't think that is required in our scenario, if AZ Controller can't send "Hello", PIC will not receive it and so everything stay "Offline".
Also I don't remember cases when AZ Controller was already sending something useful, while Cakewalk MIDI was not ready yet. I guess they prepare assigned to surface MIDI port before loading surface (sure, some "hot-plug" logic was foreseen, but Sonar was buggy with that since decades and I am not sure all these problems are solved in new Sonar). At least at some continuous time, when assigned MIDI port was not available, surface was not loaded at all.

Handshakes are good and useful for hardware, almost "a must" for complicated devices. Yes, "disable handshake" has allowed to use some simple "Mackie (in)compatible" devices with corresponding plug-in, but that doesn't mean that is good. F.e. NI controllers require quite initialization from "deep integration" solutions, the DAW has to inform the device it is "aware" and that is not possible without handshakes.