Recent Posts

Pages: [1] 2 3 ... 10
1
Discussions / Re: Accessing the External Insert Return Source
« Last post by azslow3 on January 31, 2023, 11:32:29 AM »
Hi Robert,

I definitively can't add (or remove) parameters of Cakewalk or its plug-ins. And I don't think destination/source are exposed as parameters.

Cheers,
Alexey.
2
Wishes / Re: Akai MidiMix settings
« Last post by azslow3 on January 31, 2023, 11:25:01 AM »
I don't have MidiMix and I am not aware of any AZ Controller user with it. So I can't recommend ready to use preset.

The device is Ableton oriented, so it does not has "natural" mapping for Cakewalk. But you can use it with Cakewalk, throw "ACT MIDI", "Generic" or "AZ Controller" surface plug-ins.
There are many instructions/videos about the first two. They are somehow simpler to understand and initially configure. But I (obviously) recommend "AZ Controller", it allows
getting more from your device ("ACT MIDI" can't work with more then 25 distinguishable  controls, MidiMix has 59, "Generic" is a bit limited in assignments).

Set default mapping on MidiMix (just for consistency, that will also help with buttons LEDs when/if you try to control them), then use https://www.azslow.com/index.php/topic,154.0.html
I think it is reasonable to start with 8 strips and 3 buttons per channel (ARM, MUTE, SOLO). Assign faders, one row of knobs and strip buttons. You can also assign bank buttons if you want (but using them for transport may be more practical). I think that is reasonable start point. Other knobs you can use for MIDI Learn inside VSTis.

Sure you can extend the preset later (or ask me to extend it, once you know what you want), but Startup preset you can adopt within half an hour yourself, without any knowledge about AZ Controller. Just follow the video.   
3
Discussions / Accessing the External Insert Return Source
« Last post by norfolkmastering on January 31, 2023, 10:54:41 AM »
Hello Alexey

As a consequence of my move to name based routing, I need to be able to remote control the bus external insert return audio source, preferably by using the port friendly names.

Are you able to make this parameter available as an addition to the FX-External Insert-Parameter list?

Regards
Robert
4
Wishes / Akai MidiMix settings
« Last post by Dega on January 30, 2023, 09:17:40 PM »
Anyone using the Akai MidiMix (https://www.akaipro.com/midimix) control surface successfully with Cakewalk? Are there any files available for D/L that would get me started with this?

Thanks!
5
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 28, 2023, 05:08:49 PM »
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
6
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 27, 2023, 10:37:14 AM »
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
7
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 26, 2023, 06:21:30 PM »
Hi Alexey

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

Regards
Robert
8
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.
9
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?

Regards
Robert

10
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).
Pages: [1] 2 3 ... 10