Recent Posts

Pages: 1 ... 8 9 [10]
91
Discussions / Re: Changing colour of any bus strip
« Last post by azslow3 on October 08, 2023, 11:56:15 AM »
Hi Robert,

With API it is possible to get strip color, but it doesn't allow change it.
92
Discussions / Changing colour of any bus strip
« Last post by norfolkmastering on October 06, 2023, 12:53:39 PM »
Hi Alexey

Does AZ Controller have any way to change any colour attribute of a bus strip in the console view?
I mean the whole colour of the strip or the colour of a knob?

Or if not colour then the choice of strip icon?

I have a switchable custom function for buses (switched by incoming MIDI CC to AZ) and I want it to really stand out when it is selected.

All ideas would be welcome!

Regards
Robert
93
Hi Robert,

Yes, I just report the label Cakewalk is giving me. Verbatim.

What Sonar will be, will it support the same API, how much it will cost, etc. are open questions. We just can wait till it is there.
94
Hi Alexey

Mark has added the fix to get the surface API to report the correct track send names.

It will be a Sonar fix so I'll check out the free trial version of Sonar when it appears.

Best regards
Robert
95
Hi Alexey

I am sorry if I appear to be asking the same question multiple times.  I am just trying to understand what I need to ask Cakewalk to modify.

So I will ask Mark to modify the surface API to report the correct track send names and see if he is willing to do it.

If it is only going to be updated in paid in Sonar and I decide to buy a license,  then I will consider buying a license for you as well, otherwise I cannot get future AZ support.

Let's see what Mark says first.

Thanks again for all your help with this.

Regards
Robert
96
I have tried to explain why I can NOT use strips and HW names to find correct sends and outputs.

If you want changed is labels, you should ask CW.

I will say that is not a modification, it is fixing a bug. Obviously Cakewalk should show (and report to surface API) correct target names (including S/L/R suffix). In current version it doesn't even show the suffix for sends (in the selection nor in the inspector), so I guess the bug is not (or not only) in surface API related part.

But if the codebase is fixed, the only hope is the next version of "Sonar". Note that I probably will not get it (I am not ready to pay for it...).
97
Hi Alexey

The friendly names I use for the track sends do not use or require the "L", "R" or "S" suffixes.

Within the current track output select you get three names per audio port with the suffixes "L", "R" and "S
Within the current track send select, these suffixes have disappeared!

So, do you have a method in AZ to find 'correct' friendly name for the send which matches the name actually displayed in the send display (I mean in the track strip display just above the send level control)?

Or do I need to ask Mark for a modification to the API?

Regards
Robert



98
Hi Robert,

Yes, I display whatever Cakewalk returns.

Note that for me in current version Cakewalk is "buggy" by itself with sends. Even so it allows me to select "L", "R" or "S" initially, it display it without these characters. If I try to change the send, it also no longer display "L" "R" "S" in the list, even so there are still 3 items in the menu per stereo output.
99
Hi Alexey

Thanks for the explanation.

I want to be sure I ask Mark for the correct Cakewalk update, so let me try to summarise from my understanding.  Sorry if this involves some additional questions.

My focus is still with track sends:

Can you confirm that GetMixParaValueText() is only returning the stereo friendly name even if the send is to a mono audio port?

If that is the case, then if I ask Mark to update the API so that GetMixParaValueText() makes available the correct name for each send to an audio port, so either left name, right name and stereo name, will you be able to provide the correct name for each send in AZ?

I do not need to know the stereo/mono nature of each send name.  The friendly names I use tell me that.

If a Cakewalk update is needed, then I think that Mark will be willing to make the update as part of the first Sonar release BUT I need to ensure I am asking him for the correct update.
So I am really asking, what exactly do you need from Cakewalk to allow AZ to display the correct track send names?

Best regards
Robert

100
Hi Robert,

API has GetMixParamValue() and GetMixParamValueText() methods. The first returns numeric value and the second corresponding text. So for sends and outputs I can get the "value" and then ask for its meaning. For reasons you probably remember, I and Cakewalk tries to cash both as far as that make sense (especially in AZ Controller it can happened you need the same value or text several times within one monitoring loop, f.e. to check the value/text is changed and later to send it to your device). If cashing is implemented incorrectly, corresponding value or text is not updated. Obviously that can be wrong on both sides, so I periodically "guess" the problem is in Cakewalk and Mark guess it is in AZ Controller. In worse case it can be on both sides ;)

I just get "the text", I can't guess it is about mono or stereo. Cakewalk API (I guess for historical reasons) expose the number in the "whole list" of targets, including stereo/mono/different types of targets. BTW it also does the same for MIDI, including in project persistence, I guess that "feature" is responsible for many strange MIDI routing bugs in Cakewalk history. So nothing can be done on my side.

I am slowly updating all strip names, with different API methods. So I can detect when something is renamed, even without "topology is changed" flag. Obviously that works in case Cakewalk flash the cash correctly (that is why "bus names" in the test preset was not updating before recent fix from Cakewalk). But I can't use that information to update Output nor Send, because I can't guess which "value" correspond to which strip (sends/outputs can be to buses, hardware outputs, auxes and side chain plug-in inputs, I have no direct info about the number of last 2; also the target can't be the strip itself (in case of buses), so there are some "skips"; the list of strips exposed to surface can be different from real (strips "visibility"); there is no way to get UID for target,
unlike f.e. in REAPER).
Pages: 1 ... 8 9 [10]