AZSlow

Thanks Alexey.

I will go ahead and implement this scheme in the full system.

By the way, I have been working to eliminate the use of MIDI-OX and loopMIDI in my system.
I used these two utilities to provide a flexible way to route, merge and distribute the various MIDI streams my system requires.

You may remember that I use a number of additional GUI based buttons ('Chameleon' app) to switch a number of core functions in my mixer and tape machines (e.g. I have a RECORD mode and a REPLAY mode).  These buttons sit on top of the Sonar GUI.

So I have increased the number of AZ Controller instances from two to six. (previously I had a RECORD instance and a REPLAY instance).  The additional instances allow me to read and set the additional GUI based buttons via AZ Controller.

The new method works really well and has also allowed me to reduce the number of hardware MIDI ports to just two pairs (between the PC and my PICs).
The system response time has improved as has the reliability.

My final upgrade, in planning, is to replace the six old MOTU ultralite audio interfaces (Firewire based which Windows 11 struggles to support) with three MOTU 16A audio interfaces (Thunderbolt). 

We shall see!

Best regards
Robert

Hi Robert,

It looks good. You are right, I forgot to remind about priorities. But that is usual for any monitoring, if you want something happens in predictable sequence, you need correct relative priorities.

Alexey.

Hi Alexey

Thanks for the advice.  I got a test preset working which I have attached.
It acts to prevent fader values from being output for a short time whenever the envelope/offset button is pressed.

Could you have a look at the preset please and let me know if there are any unnecessary actions.

You will see that I set the 'Monitor Timer' and 'monitor offset' - 'Monitor Command feedback' at a higher priority that the fader monitors.  This is necessary to stop the fader feedbacks from being sent whenever the envelope/offset button is pressed.

Regards
Robert

Hi Robert,

Create a separate control, let say Inhibit, with the only Action:
Monitor Timer Once

In the feedback of that Monitor Timer, put:
Set state Inhibit OFF, set engine state



In the structure before, at the end (so near "... actions which send MIDI based on Offset On/Off"), add
Set state Inhibit ON, set engine state
Monitor Reset Inhibit::Timer in X cycles/seconds

Adjust X to whatever you need, note that "seconds" are still the number of cycled, for 75ms Refresh Frequency (I remember you have it smaller).

--------------
The explanation: original "OffsetMode" monitor is triggered on any change. So it is a good place do set Inhibit=ON. Another "Timer Once" is never triggered by itself, it can be triggered by "Reset monitor" only. So we schedule its execution after required time, to reset Inhibit into OFF.

If you want, you can place "Timer Once" into some existing control. I have proposed a separate control for clear naming only.

Alexey.

Hi Alexey

Some time ago you helped me to set up an AZ control which would report on the state of the Sonar Envelope/Offset button.  This works just fine thank you.  I use the software state 'Offset' for this purpose as you set out in one of the earlier posts on this topic.

I want to set up an associated function so that, when any change of software state 'Offset' is detected, then another Software State (let us call it 'inhibit') will set to ON for 50ms then set back to its default state of 'OFF'.

The purpose of the function is to prevent feedback outputs from all faders and pans when the Sonar Envelope/Offset button is pressed but just for 50ms.

It is any change of the state of the Sonar Envelope/Offset button I want to detect and then execute the action described above.

Is this 50ms time limited change of state possible using AZ Controller?
If 'yes' can you help me with the control structure please.

Regards
Robert

Ok no problem, my memory is the same as yours especially in my daily job! I'll look into it in my free time and try to figure it out myself!
Thanks again,
Christian

Hello Christian,
Sorry to say, but I tend to completely forget what I was doing.
That happens even with tools which I have solely developed myself. One time Scott has asked about one utility.
I was sure I never had it, not even knew for what it is good. Till I have found the source code on my computer, which obviously was written by me. And related posts in the web, obviously written by me. lol.

ReaLearn is using normal Windows GUI, in range of Swell. I remember the order of elements in dialogs was bad. I also remember Microsoft tools a kind of forgot that is important. In recent for that time tools, it was almost impossible to re-order controls, so I have (probably) done that editing resource files. Also I remember some controls had no text labels or they was unreadable, for example arrows.

I am sure newer version is far from what it was 3 years ago, so that reordering has to be done from scratch again. I remember I had discussion with the author, but I don't remember on which platform and about what. Something about new ideas for GUI construction, but may be not.

That are the only bits from my memory about ReaLearn. Sorry.

Alexey.

Hello!
My name is Christian, I'm a new user and I already have noticed you are developing very interesting stuff, but I signed up because I read elsewhere that in the past (maybe 3 years ago?) you worked to make ReaLearn accessible. Can you tell me more about it?
At the moment I can use it with NVDA object navigation and, as I am a software developer too, I was tempted to study the code, especially the UI part, to figure out what prevents it from being totally accessible.
What's strange is that the developer seems very collaborative and the UI engine seems a wrapper around standard old Windows API, but anyway the screen reader has no clue about where the focus is as soon as I press tab and I have to simulate mouse clicks to reach the controls; moreover, I still know nothing about Reaper internals but I have the impression that this Swell-UI is used also by stock plugins that I can normally use with NVDA and keyboard navigation.
I have also downloaded your realearn.dll, but I can't find the version number and the one I have installed at the moment is more recent for sure and has no file called "realearn.dll" and I don't know where to put it just to give it a try!
So I'm asking you: what was your experience in trying to make ReaLearn accessible?
Can something still be done or did you have to give up because it can't be improved any further?
Thanks!

Hi Alexey
I got another replay from Mark.

'It seems Alexey is correct. MIDI output messages are sent immediately, but incoming MIDI messages aren't processed until a project is loaded.

This may not be an issue in practice with Sonar: If you have the start screen set to show on startup, there's a hidden project open in the background which is used for previewing projects.

It might be worth Alexey testing with the free version of the latest Sonar, as the start up sequence has changed since X2 (which is now over 13 years old).'

So I tried setting the 'start screen' to show when Sonar is loaded and it does seem to switch on the incoming MIDI messages to AZ Controller, which is good.  I have asked Mark if incoming MIDI can be switched on by default when Sonar is loaded.  I do not like pop up 'splash' screens!

I have done about 50% of the work to update my AZ profiles based on the advice you have given me over the last week.  The results are very encouraging so far.  Much better control of MIDI message flow to and from AZ and my PICs.

I'll let you know how it works out when I've completed the updates.

Best regards
Robert

I have just checked with the latest Sonar. When there is no project:
* MIDI sending from Surface plug-ins is works
* MIDI receiving is NOT working, at least not in "Cakewalk ACT MIDI Controller"