Recent Posts

Pages: 1 [2] 3 4 ... 10
Discussions / Re: Alternative method of track to group routing
« Last post by 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.
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 26, 2023, 03:49:11 PM »
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?


Discussions / Re: Alternative method of track to group routing
« Last post by azslow3 on January 24, 2023, 11:40:35 AM »
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).
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 24, 2023, 10:16:15 AM »
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?


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.

Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 20, 2023, 06:13:15 PM »
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.

Discussions / Re: Alternative method of track to group routing
« Last post by azslow3 on January 20, 2023, 05:47:55 PM »
He Robert,

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

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...).
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 20, 2023, 03:56:58 PM »
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.

Discussions / Re: Alternative method of track to group routing
« Last post by azslow3 on January 19, 2023, 06:46:48 PM »
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.
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 19, 2023, 05:29:16 PM »
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?

Discussions / Re: AZ Controller Not Seeing Sustain Pedal?
« Last post by azslow3 on January 17, 2023, 04:47:43 PM »
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.
Pages: 1 [2] 3 4 ... 10