AZSlow

Hi Alexey

I have spent some time optimising my PIC software to work with name based routing and the system seems to work reliably but with two issues to discuss.

1. You are already aware of the issue where sometimes the track output name is reported as the 'old' name after a bus has been renamed to a 'new' name.  I am testing this by routing all 24 tracks to the same bus and then renaming that bus.  The PIC software detects if the track output name does not match any current bus name.  If this is detected then the PIC instructs (via AZ) that track to route to 'none'.  Through repeated testing, I am finding that at least one track output name is reported incorrectly in about 20% of the tests.

2. The other issue relates to the time gap between the first and second 'name' SysEx messages when I rearrange the order of the buses in Cakewalk.  With the refresh rate set to 25ms (which I need for fader response time), the gap between first and second SysEx messages is sometimes well below the minimum expected time of 25ms.  I have measured as low as 9ms.  The gap between the second and all subsequent SysEx messages is always above 25ms.

So I did some experimentation and found that the issue is connected to the number of hardware outputs in the project.
I have 24 hardware outputs (D/A) in my standard project set up.  These are configured as one send per track.

If I remove 12 of these hardware outputs from the project, then the minimum time gap between first and second 'name' SysEx messages is 20ms.  If I remove all 24 hardware outputs from the project, then the minimum gap between first and second SysEx messages is always above 25ms.

There is a software state and logic to set (from the PIC) which hardware output is routed from which track.  I have tried removing this software state and all the logic but it does not fix the issue.

Even though the PIC is running in C, the computation required to recover and then compare string variable names within the PIC is quite slow.  I am concerned that a 9ms gap between the start of the first message and the start of the second message (which means only a few ms between the PIC receiving the final byte of the first message and the arrival of the first byte of the second SysEx) risks overflow of the (2 byte) USART RX buffer and so the second message is lost.

Could you please consider why this might be happening and whether there is any possible solution?

Regards
Robert

Hi Alexey

From your message below, could I clarify two points please:

1. You said, Text = "" is a correction for original example.
The test preset shows Text = "
Which is correct?

2. Is this additional Text entry required for 'Parameter value' feedback or just for 'Parameter name' feedback?

Regards
Robert

Hi Robert,

I attach proposed approach. Note that "Timer Once" should have priority 0, so higher then any SysEx sending Monitor. It will work also with other priority,
but can introduce more then one cycle delay (depends in which order monitors are checked).

You may ask why I explicitly reset Timer Monitor, instead of just defining State Monitor which should be triggered automatically.
The answer is... it seems like State Monitor has a bug under such use

So, before sending any SysEx I forbid triggering any other SysEx sending Monitor and schedule resetting of that block for the next cycle.

Text = "" is a correction for original example. If there is no specific Bus/Track, Text = "Parameter name" has no effect, effectively the last value of Text
will be preserved. That can produce "side effects" in complex presets (sending SysEx with wrong name for not existing output/bus).

"Display" actions are just for me, to test how all that works (since I don't have PIC to receive SysExes). Initially I put "~1sec" in Reset options to test, and Display
was updating one by one. With "at next" it should update with cycle delay.

Cheers,
Alexey.

He Robert,

Well.. that is definitively logical bug in AZ Controller
Please give me some days to fix.

Cheers,
Alexey.
PS. As you know, getting names of strips and outputs in Cakewalk is "slow". For strips I slowly "scanning" all strips for changes. But for outputs not.
I have to revise the code. I remember there was some "tricks" because brute force way was suffering from the slowness, and probably I have "optimized" it too far.
In that particular case the "value" of output is not changed (it is numerically the same), the name check is optimized away and so it does not work.
Reverting to check the name all the time is not a good option, I have to implement something else (f.e. trigger output name check if some bus name is changed,
that will not trigger on hardware outputs changes and side-chain changes, but the last is buggy in any case and the second is not usual operation...).
 

If you use my example with delayed SysEx, but do not delay CCs, you will get CCs "in time" but names delays.

Note that changes in bus names are "detected" by AZ Controller logic, it is slowly checking own cache of strip names. Doing that for all strips every cycle is not going to work.
Monitored outputs are checked in each cycle (assuming Ultra monitor), using Cakewalk caching logic.
Most other parameters are checked "in time". Monitors for them are triggered if the value is changed or AZ Controller think the strip (container) is changed.

I suggest you modify your code to accept information in arbitrary order. It is in general not possible to predict when some parameter is updated, when this update is detectable
and when it is detected. DAWs by definition have many parallel operations which at some point are synchronized, but at any particular moment the disposition is not deterministic (like a live of Schrödinger's cat).
Audio is processed in "blocks", all parameters are fixed before the block processing starts and can't be changed till the next block. That processing happens in a separate thread(s). Controlling part accept changes at any time, in parallel to that processing. The changes can be from many places, including GUI and Control Surfaces. I repeat, all that is working in parallel (even physically, modern computers have more then one thread running). DAW has to "orchestrate"  the process, broadcasting changes from one logical part to another, but it is impossible to know in which order all that happens.

One thing is a fact, nothing happens instantly. F.e. when you "Mute" a Track, if you ask Cakewalk immediately what is current status, it returns "Note muted". So it is a bad idea to do "ask to mute, check the result, update LED" in one go. For some sequences (f.e. stop->undo->record) I had to use really huge delays (a second or more), the result was "unpredictable" otherwise.
So just accepting everything in arbitrary order is the only safe option.
 

I guess it is sent, but to other MIDI device/port. Probably configurable on the keyboard or corresponding software.

Which keyboard you have? I can check its documentation to give explicit answer.