AZSlow

Hello Alexey

This question relates to my use of AZ Controller Feedback messages to control the track to bus routing of my external analogue audio mixer.
The current working system uses a Software State with entries corresponding to each bus, so:

'--- None ---'
'Group 1'
'Group 2'
'Group 3'
'Group 4'
'Group 5'
'Group 6'
'Group 7'
'Group 8'
'unknown'
'11' (dummy)
up to
'128' (dummy)

This system works reliably but it means I can never change the names of the buses during a project.  This is not ideal.

Remembering that I have a PIC available to process messages received from AZ Controller, I want to consider an alternative system for routing tracks to buses in my mixer.

Is AZ Controller capable of reading the actual bus routing alphanumeric label which is displayed at the bottom of a track strip, e.g., if track 6 is routed to 'Drums', can AZ read the 'Drums' label?  If AZ can do this then I may be able to control the routing control of my mixer is a more friendly way as it would allow me to change bus labels during a session.

Any information or suggestions you have would be very welcome.

Best regards
Robert

With Software State you can send Bus number as numerical value. You can get the Bus name with Text Action ('Parameter value') and send it with SysEx.

The only thing which is not possible is absolute Bus number. I mean if you have 7 Buses and the output is to the Bus 6, the number "6" is not possible to get.
In general, "Output" can be Bus, Hardware Output, Aux Track or Side Chain input. Cakewalk give me flat list of all of them and position from that list. I mean I can't detect which
kind of output that is and so absolute number doesn't has fixed meaning in arbitrary project. But I can add a possibility to get the value, so in predictable project (with concrete
audio interface) you can predict correct bus number in your PIC.

Hello Alexey
Thanks for getting back on this possibility.

Can I clarify one point please:

You say 'You can get the Bus name with Text Action ('Parameter value') and send it with SysEx.'  Can you get the Bus name in the track to bus assignment?  or only the bus label in the bus strip?

If I can get both,  then I can do everything in the PIC without having to use bus numbers.

Regards
Robert

"Output" parameter of the track/bus is what is in the "at the bottom of the strip". Buses names you can monitor as well (separately). So yes, you can collect bus names and output names.

Hello Alexey
Thanks for the further information.

I think it should be possible to change to a routing system based on bus names and output names.
So I created a test Cakewalk project with 3 tracks and 3 buses labelled:
'Track 1'
'Track 2'
'Track 3'
'Bus 1'
'Bus 2'
'Bus 3'

I want to get the bus names and output names to my PIC.

So I created a test AZ preset called 'Bus Names' which I have attached.
For the output names I tried creating a Logic Control with three actions:
Strip:Track:Output
Text: Param. value
Parameter Value Monitor

Then a Feedback action:
SysEx/MIDI:SysEx:Send

But I get no output from this feedback action.

For the bus names I don't know how to focus on the name, so I set up a Logic Control with three actions just to test the preset was working:
Strip:Bus:Volume
Direct Linear
Parameter Value Monitor

Then a Feedback action:
MIDI:CC:Value

This works okay but of course does not output the bus name.

Can I ask you to help me with this test preset please, then I should be able to do some test code for the PIC.

Best regards
Robert

Hi Robert,

I have modified the preset. Hopefully it works.

For Track Output you monitor the value. And then get it in Feedback into Text and construct SysEx using this text (prepending something to understand what it is...).
For Bus Names any parameter Name monitor will be triggered on Bus name change. Important to get the Text from "Origin name", since parameter name will be just "Volume".

Cheers,
Alexey.

Hi Alexey

The modified preset works, thank you.

When I load a Cakewalk project I get a dump of all the bus names and output names.
When I change a name, then I get a feedback message.
So I think that is enough information to modify my PIC programme.

Your suggested use of SysEx prefixes unique to each track or bus will allow me to identify exactly which label I am receiving.

I need to work out the best way of storing and comparing the received SysEx messages.
I think my options are to either:

Convert the received values back to character strings and then use the C function strcmp to match track output names to bus names (so I do the correct audio routing in my mixer).
OR
Store the received values in numerical arrays and then try to find a high level C function to compare numerical arrays. (I have not been able to find a high level function yet).

Thanks again for your help with this.  Not only will this improvement allow me to change bus names as a recording and mixing session evolves, it also opens up the possibility of rearranging the Cakewalk displayed order of busses which is not possible with my current PIC software.

I'll let you know how the work progresses.

Regards
Robert

Hi Alexey

I have the routing system based on labels working.
There is one issue.
As the PIC has to do a lot of data processing for each received label, I think I am losing some routing MIDI messages from AZ to the PIC when the bulk dump is carried out.  This is part of the start-up process when a Cakewalk project is opened.

Is there any way to affect a small delay between each of the SySEx messages, so I mean perhaps 10ms?

Regards
Robert

Hi Robert,

AZ Controller does not support that. You can try to set speed to "Normal" for corresponding monitors, if I remember correctly that should "spread" monitoring a bit. Alternatively explicit monitoring blocking can be organized (so after 1-n sends other monitors are not checked in the same cycle). But all that will be timed in cycles, so 75ms (default) or whatever you currently use.

I was thinking about a separate thread for quantized MIDI sending several times, but so far I have managed to use other approaches. Cakewalk is obviously "ready" for MIDI sends during MIDI processing and timed cycles (it initiate both), but I am not sure what happens if I start sending at random times from different thread. You know, when something was never foreseen, that is probably buggy.

Cheers,
Alexey.

Hi Alexey
Thanks for your advice.

I tried setting the speed to "Normal" for the relevant monitors but it did not fix the issue.

My cycle time is set to 25ms, so if there is a way to configure monitor blocking then this may provide a practical solution.

Using my test preset, is it possible to set monitor blocking so that;
If 'Track1' is checked in one cycle, then 'Track2' and 'Track3' are not checked in the same cycle?
Then 'Track2' is checked in the next cycle but 'Track3' is not checked in that cycle.

So what I am trying to achieve (using the test preset) is that only one 'Trackx' is checked per cycle.
Is that possible?

Regards
Robert

Hi Alexey

Further to my last message.

I just discovered that it is possible to do selective action monitor resets.  I did not realise that this was possible and it is a potential solution to my issue.

So my idea is that the PIC can send a MIDI command to trigger only some/all of the output name SysEx messages.

However this depends on a Monitor reset feature I don't fully understand.  So can I ask:

For a single each action Monitor reset, there is an option to change the trigger timing .e.g. 'after 2 cycles'.  Can you tell me what each cycle means?  Is this multiples of the Cakewalk refresh rate or another timing measure?

Sorry another question.  Could you increase the number of trigger timing options?  The cycle limit at the moment is 11 cycles.  Could you extend this drop down?  say to range up to 127 cycles?

If this is possible, then I could put all of my routing SysEx actions into a single Monitor reset but with each action having a different trigger delay.  Would that space out the SysEx messages from AZ as I require?

Best regards
Robert

Hi Robert,

You can initiate request-reply for names from PIC, by sending some MIDI from PIC and directly sending the name as the reaction, so without monitors. But then changes  in names are not going to be send.

Cycles are loops, when specified  reset after "X seconds", that means X*13 cycles (since default cycle is 75ms...).

I can modify the example... probably not before weekend... to demonstrate blocking. If any monitor send SysEx, it set "SysEx_Sent" Set to "Yes" and reset special "Timer once" Monitor at "next" cycle. That monitor with 0 priority reset "SysEx_Sent" to "No". All sending monitors should have "SyeEx_Sent:Yes - Undefined final" before the monitor in the logic list.
So, if any Monitor is triggered SysEx_Sent is set, so all other monitors will not be triggered in the same cycle. High priority monitor will unset the State at the beginning of the next cycle, so some other Monitor can send SysEx.
That should work fine at the beginning/project changing and for "run time" renaming.

Hi Alexey
Thanks for offering to modify the preset to demonstrate blocking.  This looks a promising solution to the issue.
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.

Hi Alexey

Thanks so much for updating the test preset and for the explanations.
I'll spend some time experimenting with this approach and let you know how it works for me.

Best regards
Robert

Hi Alexey

I am making good progress with the test preset.
Putting aside the SysEx blocking function for a moment please, I have another question:

I have a need to ensure that three types of feedback are sent out from AZ in a particular order.
I am trying to use priorities to do this but the results are not consistent.
Let me explain.

With my set up, when a buss name is changed in Cakewalk, it triggers the following feedback outputs:
The new buss name (SysEx)
The buss output name (SysEx)
All of the CCs associated with that bus (input, gain, fader setting etc)

I want the new buss name always to be output first, so I tried setting it to priority 0
The bus output name to be output next, so I set this it to priority 1
Those two work okay.

Next I set the CCs to priority 2
However the CCs are always output first (before the two SysEx messages)
I tried CCs set to priority 10.
Same result, the CCs are always output first.

Do you have an idea why the priorities are not being followed?

It is possible that changing a bus name changes (what Mark McLeod called) 'the audio routing graph' which is part of the cache they introduced to solve an earlier issue I had.  Could this be delaying the sending of the bus name into AZ?

regards
Robert

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.

Hi Alexey

Thanks for your advice that I need to programme assuming everything is in arbitrary order.  I will move forward with this rule in mind.
The reason I started to look at using priorities is a problem with track output bus names.  Let me explain with a simple example.

Bus 1 is named 'Test1'
One or more tracks is already routed to Bus 1 'Test1'
I change the Bus 1 name to 'Test2'
The tracks already routed to Bus 1 correctly change the Cakewalk screen labels to 'Test 2' but the track output names reported from AZ are remaining at 'Test1'
This is causing big problems with my PIC and mixer routing system.

Are you able to check for this problem please and let me know if you understand what is happening.

Regards
Robert

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...).

Hi Alexey

Thanks for your explanation and a really big thank you for agreeing to look for a fix.

The move to use labels for routing of my audio mixer is a big change but it offers some great advantages for my sessions.  I will be able to:

-  Change bus names (the old routing system required fixed bus names).
-  Rearrange the order of buses in Cakewalk and my audio mixer will follow those positional changes.
-  Be able to work with any number of buses up to eight 'sub' buses and one 'master' bus.  (the old routing system required always eight 'sub' buses and one 'master' bus)

So a lot more flexibility.

Thanks for helping me so much with this.

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

Quote from: azslow3 on January 09, 2023, 02:40:04 PM
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.

Text="" is a good idea before any Text = Name/Value. That ensure in case corresponding parameter/strip is not there, the Text sent will be "". It will stay whatever it
was otherwise (by default also "", but if you change is as "engine state" anywhere, the value will be persistent... and such logical mistake is very hard to catch).

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

I have never measured how Cakewalk calculate cycles, so is 25ms means between last cycle is finished and new started or just between beginning of cycles. The later case can explain your observation, if cycle processing takes 16ms with big number of tracks, and we know Cakewalk is slow reporting sends and outputs names, it can happened the first SysEx is triggered at the end of processing, so just before 9ms of the next cycle.
There is no feel of "real time" in AZ Controller at the moment... but we can organize "one SysEx per 2 cycles". That will give "normal" speed 50ms, x24 = 1.2sec to update 24 tracks. But I guess that is acceptable in case of such change in the project.

Hi Alexey

I agree that one SysEx per 2 cycles would be worth trying.  Is it an easy change to the preset?

Regards
Robert

Quote from: azslow3 on January 26, 2023, 05:32:56 PM
I have never measured how Cakewalk calculate cycles, so is 25ms means between last cycle is finished and new started or just between beginning of cycles. The later case can explain your observation, if cycle processing takes 16ms with big number of tracks, and we know Cakewalk is slow reporting sends and outputs names, it can happened the first SysEx is triggered at the end of processing, so just before 9ms of the next cycle.
There is no feel of "real time" in AZ Controller at the moment... but we can organize "one SysEx per 2 cycles". That will give "normal" speed 50ms, x24 = 1.2sec to update 24 tracks. But I guess that is acceptable in case of such change in the project.

Hi Alexey
I changed the Monitor reset for the 'CanSendSysEx : Timer' to trigger in 2 cycles and the minimum time between first and second SysEx messages is now 31ms which is fine.  Thanks for your advice to fix that issue.

Please let me know when you have a solution for the reporting of Track Outputs Names as this is still causing routing failures on a regular basis.
Best regards
Robert

Hi Alexey

A further update on my progress.

I experimented and found a mechanism to trigger a Cakewalk refresh of the track output names.

I found that any instruction received by Cakewalk to set a routing (even if the instruction sets it to its existing destination) causes Cakewalk to refresh the track output names, so I mean the names which sit in the AZ 'buffer'.  So this means that the 'old' track output names are updated with the correct 'new' names.

I added a routine in my PIC which detects when a bus name is changed.  When this is detected, I send a MIDI instruction from the PIC to AZ/Cakewalk to set my Track 1 Send 1 to its already set destination (which is always set to the hardware output 'DAW1'.  This causes no change to my setup but the track output names issue is resolved.

I will continue testing this work-a-round but so far it is 100% reliable.

Of course it would be great to get the issue fixed the correct way but I wanted to let you know I found this way around the issue.

Best regards

Robert

Hi Robert,

Just to keep you informed. I have not forgotten about the problem. It just happened to be more severe then I have thought at the beginning, so I have to rewrite
the whole sends/output monitoring logic and that takes time.

I must admit current implementation is logically buggy at many places. It is "too fast", I mean it works faster then proper implementation. But can return wrong names/values
for sends, project dependent.

In addition, Cakewalk informs surfaces "there was topology change" in case of most related operations, including changing any send. But it does not do this in case
the output is changed (at least not in Sonar X2). While with strip names I can understand that, at the end changing in names do not change topology, changing output has
the same effect on topology as changing send output. I am going to check later with CbB, and if that is still the case there I probably write feature request.
I mean I can cache sends values but can't cache outputs values, and as we know for some reason I don't understand (even after some explanation from Cakewalk...) that
API calls are "pricey".

Hi Alexey

Thanks very much for keeping me informed.  I understand your explanation.
For now, the work-a-round which I have implemented is working 100% reliably so I have a functioning system.

To keep you up to date with my PIC programming progress:

My hardware mixer has 24 channels (tracks) which mix down to eight stereo buses (which I call 'groups'), and these groups mix down to one Master bus.

With the name based routing system, I always have one bus in Cakewalk named 'Master'.
The other eight buses can be freely named.

Today, I finished a PIC update which allows the 'Master' bus (in Cakewalk) to be placed in any slot position within the nine buses.
This was an interesting programming challenge because in the hardware mixer, the Master bus pcb is special and, of course, its output is physically connected to the monitor loudspeakers and master stereo tape machine.  So far my update is working but lots of testing still to do.

Next step is to allow the number of 'groups' to be varied from one to eight.  This means I will be able to add extra groups as I need them during a project, name them as I like to, and the hardware mixer will continue to be mapped correctly from Cakewalk/AZ.  So now I will be implementing how to deal with AZ SysEx name outputs for buses which don't exist within the Cakewalk project.  You already gave me very good advice on how to deal with this using the Feedback action 'Text =''.

As always, I could do none of this without AZ Controller and your continued support.  A very  big thank you from me to you!

Best regards
Robert

Hi Robert,

I have uploaded "pre-release" as test version (https://www.azslow.com/index.php?action=downloads;sa=view;down=28)

Everything related to Input/Output(Strip and Send) is reworked. I try to cache what is possible (according to Sonar X2 behavior, I have not really tested with CbB).
But not cache if that can break things.

So note that "Output" (unlike "Send output") is asking Cakewalk all the time. It make sense to assign "Normal" speed for corresponding monitors, if you notice Cakewalk
is laggy again.

Strip (including buses) name changes are noticed "slowly" (can take seconds), independent from monitors speed (that is done is slowly continuous looping over all strips).
Other changes should be spotted almost instantly. As I wrote, Cakewalk informs about most structural changes (except Input/Output), with a kind of flag "something in structure
is changed". For Input/Output I just follow preset specified speed, it seems like the operation is not extremely heavy. But getting names (for everything) is heavy. So I traverse
strips slowly. Names for Inputs/Outputs are stay the same as long the value is not changed, there is no structural changes and no renames. So I can cache them till one of these
conditions is triggered.

Please let me know if something is broken or odd. The modification is deep, I could easily break something.

Hi,

if you have downloaded, please re-download. During fixing send/input/output value changes (from AZ Controller) I have noticed I can't cache send output value.
Cakewalk notify me in case it is changed by mouse, but keep silence if I do the same from controller. And since there can be more then one controller,
it is unsafe to cache it.

Hi Alexey
I've been travelling for the last week so just got back home.  I will download and test over the weekend.
Can You tell me: Do I have to uninstall the old version first? or does the new version overwrite the old version?
Regards
Robert

Quote from: norfolkmastering on February 10, 2023, 06:34:11 PM
Hi Alexey
I've been travelling for the last week so just got back home.  I will download and test over the weekend.
Can You tell me: Do I have to uninstall the old version first? or does the new version overwrite the old version?
Regards
Robert

Sorry, another question:  If I have to go back to the previous version, how do I preserve the multiple instances I run?
Thanks
Robert

The installer overwrites existing version, so keeping the installer with version you want to revert is sufficient. Nothing special
is required to install older versions (but presets saved under newer version can be incompatible with older... well, all versions last years
are just fixes or extensions, so compatible with each other).

It is better use one version for all instances. Strange things can happened otherwise since that was never tested. When defaults are used during installation,
re-registering instances is not required.

Thanks Alexey.
I'll get back to you when I've carefully tested the new version with my setup.
Best regards
Robert

H Alexey
I downloaded the AZ test version and tested with my setup.

I found that the SysEx message for a track or bus routed to no destination is being output from AZ differently than before.

The normal output (no destination) SysEx contains the name '--- None ---'
With the new version of AZ, this name is being output as 'None'

My PIC software is all written to expect '--- None ---' so it sees this different name as an unknown destination and gets into a loop, i.e. tells Cakewalk to change unknown destination to '--- None ---' but gets name back from Cakewalk/AZ as 'None' and so this loops continues.

Could you check this please before I do any more testing.  I want to make sure the name outputs are consistent with previous AZ version.

Regards
Robert

Hi Robert,

Please re-download. Should be "corrected" now.

I write that in quotas because Cakewalk is a kind of inconsistent there. It shows "--- None ---" for Sends and Strip Outputs and  "-None-" for Inputs. While in selection menu they use "None".
But I am not a big fan of renaming... even in case original naming looks wrong.

In this new version I am not asking Cakewalk for "None/Omni" (all kinds) names. So I was explicitly returning "None" and that has triggered the different.
Thanks for spotting.

Cheers,
Alexey.

Thanks Alexey

I downloaded the latest version and that fixed the 'None' SysEx issue.
I will test for some days and them get back to you.
Best regards
Robert

Hello Alexey

I did some testing of the new AZ version today.
Sadly it is still not updating the track output names when a bus name is changed.

I have attached a screen shot from MIDI-OX which monitors the output of AZ:

I test by changing the bus 2 name from 'Group 2' to 'Test 5'
The first SysEx message
240 0 1 84 101 115 116 32 53 247
is the ascii for 'Test 5'

The next SysEx message is the bus 2 output name '--- None ---'

Next are the bus 2 CCs (Fader, Pan etc)

Before I changed the Bus 2 name, I had routed Track 3 to bus 2.
The next SysEx is the Track 3 output name, still showing 'Group 2' (although the Track 3 output name on the Cakewalk screen shows 'Test 5')

So this mismatch of SysEx names is picked up by my PIC which interprets Track 3 as asking to be routed to an unknown bus.
This triggers an instruction from the PIC back to AZ to change the Track 3 destination to '--- None ---' (MIDI CH14 CC2 Value 0)
This is actioned and the final SysEx message shows the Track 3 output name as '--- None ---'

With the new software, this failure to update the track names is happening 100% of the time.

Sorry for the news!

I know you've spent a lot of time on this issue.  If you want to stop working on it then I have the work-a-round (I described before) and it is working 100% of the time, so please don't spend a lot more time on this, unless you really want to.

I'm happy to do further testing of course.

Best regards
Robert

Hello Robert,

Sorry for negative results, thank you for patience ;)

The update supposed to fix the logic, so I want it works correctly (for everyone).

I attach test preset. It probably sends wrong sysExes, so use it without connection to PIC. Just open build-in display (in the "Options" tab).
Upper cells should be bus names (1,2,3) and lower cells should be track output names (1,2,3).
SysEx slow sending is still there and name scans are even slower then that, so you should more or less notice in which order the display is updated in case
of changes. I have set Track outputs monitors priority lower then bus names, so they have to be updated (in case of bus renaming) strictly in that order.

Please test that preset updates display correctly in case: (a) track output is changed (b) bus is renamed.
The result can give me the idea from where your observation comes:
(1) I am testing on Wine/Sonar X2 (32bit), can be Cakewalk has changed something
(2) I have uploaded/you have installed not the version I have
(3) something in your current preset make things not working as expected

Regards,
Alexey.

Hi Alexey

I downloaded the new preset and loaded it whilst running the test AZ version 0_5r11b419M.

I did testing with a large number of physical I/O ports (32 in, 40 out) and with a smaller number of ports (8 in, 10 out)
For both sizes of ports the results were identical.

FIRST TEST
I changed the bus name and then checked to see if the track output name (for track already routed to that bus) changed to match the new bus name.

In most number of tests, the track output name did not update correctly.
In a small number of cases, the track output name did update correctly.

When the track output name did not update correctly, I see only one SysEs message output on MIDI-OX, the new bus name.
When the track output name did update correctly, I see two SysEx messages on MIDI-OX, the new bus name and the new track output name.

SECOND TEST
I changed the bus name and checked for track output name update failure.
If track output name update failed, then I routed a second track to that renamed bus.  In all cases the second track output name output correctly.

I hope this helps your investigation.  If you want me to do additional tests then please let me know and I will be happy to.

Best regards
Robert

Hi Robert,

Thank you for testing. And sorry I have not tested it myself (CbB is not working under Linux/Wine, it is always a pain for me to test with it on my development setup...).

I think that is (1), Cakewalk bug. I have specially tested, Cakewalk is reporting old name. I have reported in:
https://discuss.cakewalk.com/index.php?/topic/54690-br-surface-api-strip-output-name/

I can't workaround the bug, numerical output value is just sequential number in the strip specific list, I can't deduct what is the destination. I mean theoretically in
some situations it is possible, but that will hammer Cakewalk hard and will not work in all projects.

Regards,
Alexey.

Hi Alexey
Thanks for the update.
I will add my voice to the topic and see if we can get a commitment to fix it.
Best regards
Robert

Hi Robert.

It is interesting why your "workaround" using older AZ Controller version works... At the end it use the same calls, which in my current test return not updated name.
Sometimes several bugs together make things looking like working correctly  ;)

Cheers,
Alexey.