Author Topic: Alternative method of track to group routing  (Read 3867 times)

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Alternative method of track to group routing
« on: December 26, 2022, 04:52:18 PM »
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



Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: Alternative method of track to group routing
« Reply #1 on: December 27, 2022, 08:00:30 AM »
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.

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #2 on: December 28, 2022, 05:33:52 PM »
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

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: Alternative method of track to group routing
« Reply #3 on: December 29, 2022, 12:43:05 AM »
"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.

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #4 on: December 29, 2022, 11:35:12 AM »
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



Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: Alternative method of track to group routing
« Reply #5 on: December 29, 2022, 10:50:36 PM »
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.

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #6 on: December 30, 2022, 12:31:56 PM »
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

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #7 on: January 03, 2023, 10:26:34 PM »
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

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: Alternative method of track to group routing
« Reply #8 on: January 04, 2023, 09:44:45 AM »
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.



Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #9 on: January 04, 2023, 11:49:22 AM »
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

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #10 on: January 04, 2023, 06:24:32 PM »
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


Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: Alternative method of track to group routing
« Reply #11 on: January 04, 2023, 10:24:57 PM »
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.

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #12 on: January 05, 2023, 10:49:07 AM »
Hi Alexey
Thanks for offering to modify the preset to demonstrate blocking.  This looks a promising solution to the issue.
Regards
Robert

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: Alternative method of track to group routing
« Reply #13 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.

Offline norfolkmastering

  • Full Member
  • ***
  • Posts: 191
Re: Alternative method of track to group routing
« Reply #14 on: January 09, 2023, 04:09:17 PM »
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