Using AZ Controller for Cakewalk control of external audio mixer

[azslow3]

Try Send number 0... Its "programmers" world 

[norfolkmastering]

Hello Alexey

I tried send number 0 but still not working.

I have attached three screen shots showing the three actions programmed for Rotor 2.  Could you have a look please.

(and just to assure you that Rotor 1 - which I programmed before to control the Track 1 fader is working, so the MIDI between my nektar keyboard and AZ/Cakewalk is working okay)

Regards

Robert

[azslow3]

Hello Robert,

Do NOT use Cakewalk AUXes for your purpose,  use Buses (name them AUXes if your want).

Cakewalk has "hacked" AUXes into original engine as the way to record soft synthes and FXes live. When someone really "play" soft instrument live, the sound can be significant different from re-play of recorded MIDI. That is the only reason to use them.

From the beginning, this "hack" was quite buggy. On of the bugs you have just hit yourself: sends to them can not be controlled by surfaces 

[norfolkmastering]

Hello Alexey

Thanks for the advice.  I was able control bus sends from tracks, so that is a big step forward.

Can I check one more point with you for now please:-

Could you explain how to achieve a latching function for buttons please.  One example:-

I can programme a button on my nektar keyboard to operate a track SOLO function, but when I release the button then the SOLO is also released.  So it provides a non-latching action which is not what is required.

Can you please tell me how to achieve a latching action for the button?  So I PRESS and RELEASE the button, and the SOLO function changes state.  I mean:-

If the SOLO was "OFF" then it switches to "ON".

If the SOLO was "ON" then it switches to "OFF".

I have many requirements for this type of latching button, so your advice would be appreciated.

And I have to say that the AZ Controller is amazing!  Yes it will take me some time to learn but the very deep level of control and feedback is incredible.

Very best wishes

Robert

[azslow3]

Hello Robert,

What you call "button latching" is reaction on button press only. Some surfaces just send "button", but more "smart" devices send "button is pressed" and "button is released".
If the code does not take that into account, it does not distinguish between "pressed" and "released" and so toggle f.e. Solo when pressed and when released.

Press and release send different value (you can see that in the "Last MIDI event"). Normally press is value 127 and release is value 0.

AZ Controller tries to help you with processing that. In case you look precisely, there is "Note:On" condition on every action by default. So no action is executed when "Note:Off" (Note Off MIDI event or Note On with Value 0 MIDI event). But in case a button send not Note MIDI event but something else, what to do is not obvious. F.e. when you turn a knob which sends CC you want Value 0 is processed as any other value.

The solution in AZ Controller is explicitly declare a hardware control as a "Button". In the Options tab select button control as set its type from "Unknown" to "Button", do not forget to press "Save" near that combo box. In this case CC with value 0 will be interpreted as "Note:Off" and so there will be no reaction on release (till you change Note conditions for particular actions, useful f.e. to implement modifier keys like Shift).

[norfolkmastering]

Hello Alexey

Thanks for the advice.  Changing the button type to "pad" (which I think was your reference to "button") provided the require action.

For information, I am experimenting with a Microchip PIC demo board to map out the structure of how the MIDI commands sent as feedback actions from AZ Controller will control the hardware control elements of the analogue mixer.  These are mostly VCAs (level) and FETs (switching).

I am building a small two channel analogue audio mixer to check out the basic hardware control elements.  After that, I will look to design the full size mixer.  Current plan is:-

24 channels (tracks)
8 + 2 + 1 stereo group buses (8 groups, 2 "auxes", 1 master).

The mixer will receive its audio for mixdown from a 24 track analogue tape machine also under remote control and sync from Cakewalk.

I will study the use of OSC for the communications between AZ and my hardware controller.  It looks like a good solution.

I will be in touch again once I have decided on the protocols.

Again, thank you for your good advice to date.

Regards

Robert

[norfolkmastering]

Hello Alexey

As I will be controlling a digitally controlled analogue mixer from Cakewalk via AZ controller, using Feedback actions, the monitor refresh frequency is important for me.

When I set the Cakewalk controller refresh frequency to 50ms and the Parameter Value Monitor to Ultra (let us use the example of track volume monitoring) then I get a maximum of 20 track fader values per second (corresponding to the 50ms refresh setting).  This is as expected.

Here is my question please:-

It is possible to set the Cakewalk controller refresh frequency below 50ms by editing the Calkwalk.ini file.  I tried setting to 25ms in Cakewalk.ini and the value appears to be accepted; i.e. 25ms is displayed in the preferences/MIDI/controller surfaces display.

However it does not increase the frequency of monitor messages output on to my MIDI stream.

Can you tell me if this is due to a configuration setting in AZ Controller? So I mean is the 'ultra' setting limited to 50ms?  Or do you think that Cakewalk is ignoring any setting below 50ms?

For my unusual application, I want to try to increase the controller refresh frequency if it is possible.

Regards

Robert

[azslow3]

From what I know, that comes from Cakewalk.

Note that values can not update faster then the buffer length... Which settings you use in Cakewalk for the audio device?

Also I think that 50-100ms is faster then you may need for any purpose. Everything you want to be "smooth" (motor fader movements,  volume automations, etc.) should be implemented inside your device by inter/extrapolation.

Note that some digital mixers I know (RME, Behringer) do not do this. If you ramp up volume you can easily notice that happens in "steps". And real reaction of the device on parameter changes seems like much slower then 100ms. For some purpose not nice, but that is by design. You can try to make it better, but that is a challenge. It is easy to have "usec" frequencies inside a chip, but it is not easy to keep that on a wire (Shannon and other slow us down...). F.e. you will need to communicate through USBv2 (or later) and forget about WiFi in case you need something with stable reaction under 50ms.

[norfolkmastering]

Hello Alexey

I was running Cakewalk on a buffer length of 23.2msec.
So I tried reducing the buffer length to 5.8msec and setting the controller refresh frequency to 25msec in Cakewalk.ini
Again the Cakewalk preferences display seems to accept the 25msec value but it makes no difference to the actual refresh rate.
I will check with Cakewalk (Bandlab) if this is a restriction they place on the system.

The control voltage (linear voltage derived from DAC converter) applied to analogue gain control elements (VCAs) will have a time constant of around 7ms to help smooth the step transitions but it would be valuable to get as much control resolution from Cakewalk as possible.  Part of that resolution comes from the refresh frequency.

I understand your point about using inter/extrapolation to smooth control inputs.  It should be possible to do this within my microcomputer but of course it introduces some delay as I have to buffer MIDI values in order to make the calculations.  If it was feedback to motor faders then that would not be an issue, but in my application it delays the control signal to the audio mixer which is not desirable.

Once I have built the small demo analogue mixer, I will experiment to see what is practical.

Again, thank you for your advice on this project.

Best wishes

Robert

[norfolkmastering]

Hello Alexey

I have been in communication with the development team at Bandlab concerning my digitally controlled analogue mixer design.

They have agreed to change the minimum refresh frequency from 50ms to 10ms in the next Cakewalk software update.

They also suggested I check out a few points with you regarding the AZ Controller:-

Assuming I use the 'Ultra' priority for a Parameter Value Monitor, will AZ Controller be able to perform its operations with the 10ms window?

Two situations I want to consider:-

1. Let us assume that the number of Monitor action messages within the 10ms refresh window is low, so that there is sufficient MIDI transmission time to output all the MIDI messages within a 10ms window (let's assume 1ms per 3-byte message).  Will AZ Controller be able to process within this 10ms window?  So I mean, what additional latency is likely to be introduced by AZ Controller?

2. If the total number of Monitor action messages within the 10ms refresh window exceeds the number of MIDI messages which could be outputted within a 10ms window, does AZ Controller have any processing functionally to deal with this?  e.g. a FIFO buffer?  So that the MIDI messages could be output when there is capacity on the MIDI output.

If AZ Controller does not have any coping mechanism for message volumes which exceed the available MIDI transmission time (per 10ms window), what happens to the MIDI messages which cannot be output within the 10ms window?

Of course there is the possibility to have multiple instances of AZ Controller and more MIDI links between Cakewalk and my PIC Controller but first I want to understand better how AZ Controller handles the Monitor action messages as above.

Once I receive messages at the PIC Microcontroller, there should be no problem processing within the 10ms refresh window.  I am writing the programme in C and onward transmission to the digitally controlled analogue circuitry will be a combination of I2C and SPI.  Data rates of at least 400kbps will be a available for both of these serial protocols.

Thanks for your continued support with my project.

Regards

Robert

[azslow3]

Hello Robert,

What will happened is really up to Cakewalk (and your preset). I have developed AZ Controller under Linux/Wine, on Centrino based notebook. And my major desktop was CuoDuo/Celeron. Both could barely run 2 synth without freezing. And so I have tried to hit CPU as little as possible (down to the level of lookup tables and precalculated maps, to avoid any "hash" calculations and reduce floating point math...). But that is on my side only, I have to call Cakewalk to get the information. Still, I do not remember any significant performance penalty even with most demanding presets (when I was hitting some slowness I was implementing workarounds). So I think modern computer can handle all that with 10ms cycles.

MIDI is sent to Cakewalk, so how that works is now known for me. From what I know, they handle it correctly. I mean probably they throttle when required, but I am not sure. There was at least one device which had problems handle everything sent, but I have just reduced the speed of corresponding monitoring without digging too deep.

In case you do not have your MIDI implementation yet, just test with any MIDI hardware loop. I mean draw sufficient number of envelopes and check what comes out (record output MIDI stream).

Alexey.
PS. One example what is not working without manual throughput control is Novation Nocturn + Linux + REAPER MIDI output API (for surfaces). The device itself is rather slow (10ms rate, 8bytes packets). 16 short MIDI messages sent in burst (with REAPER API) and the whole device is randomly illuminated. Sending just two messages every 10ms works reliable.
Not sure who is responsible: dummy Linux MIDI driver for the device or REAPER. I mean there can be some troubles along your way as well. 

[norfolkmastering]

Hello Alexey,

Thank you for the information and advice.

Once the next Cakewalk version is released, I will set the refresh time to 10ms and try the loop test as you suggest.

I will test:-

1. Response time from Cakewalk event, e.g. automated fade, to MIDI data output.

2. What happens when the number of monitor action messages (within a 10ms window) exceeds the MIDI capacity (so about 10 x 3 byte messages).

I will report back when I have findings.

Best regards

Robert

[norfolkmastering]

Hello Alexey

I have just downloaded an advance version of the next Cakewalk release which now supports 25ms refresh time via the Preferences\MIDI\Control Surfaces setup and 10ms by updating the Cakewalk.ini file

I have confirmation from the Bandlab team that 10ms is now supported.

I can get the 25ms setting to work but not the 10ms setting.

Let me explain how I did the refresh time test:-

I draw a single track fader volume automation which goes from -INF to +6dB within a 500ms time window.

I then use the AZ controller app to output the fader volume as CC control messages and monitor these via MIDI-OX.

When I set the refresh time to 25ms, then I get 21 CC values within the 500ms window, which is what I would expect.

When I set the refresh time to 10ms (by changing the Cakewalk.ini) then I still get only 21 CC values within the 500ms window, when I should be seeing 51 CC values (500ms divided by 10ms plus one).

I have asked the Bandlab team to double check, but could I please ask you to confirm that AZ Controller (with a Parameter Value Monitor set to 'Ultra') does not have a minimum response time programmed in to the software?

Kind regards

Robert

Hello Alexey,

Thank you for the information and advice.

Once the next Cakewalk version is released, I will set the refresh time to 10ms and try the loop test as you suggest.

I will test:-

1. Response time from Cakewalk event, e.g. automated fade, to MIDI data output.

2. What happens when the number of monitor action messages (within a 10ms window) exceeds the MIDI capacity (so about 10 x 3 byte messages).

I will report back when I have findings.

Best regards

Robert

[azslow3]

I do not limit anything.

But please check your buffer length in smaller then 10ms. You have mentioned one test with 5.8ms, but in case you have reverted settings to 20+ms that can explain the behavior.

Cheers,
Alexey.

[norfolkmastering]

Hello Alexey

I tried reducing the buffer length down to 2.9ms but I still get a measured refresh time of 25ms when the .ini is set to 10ms.

Thanks for confirming that AZ Controller is is not limiting the refresh time.

I will report back to the Bandlab team.

Regards

Robert

I do not limit anything.

But please check your buffer length in smaller then 10ms. You have mentioned one test with 5.8ms, but in case you have reverted settings to 20+ms that can explain the behavior.

Cheers,
Alexey.