Automation read/write bug

[Olivier Bilquin]

Randomly, when I want to record an automation with my QCon Pro X (Mackie Control mode), I no longer have control over the fader touch. While it worked fine, write mode enabled, suddenly Cakewalk records an automation even though I don’t touch the fader. In addition, in read mode activated, Cakewalk no longer plays automation. I note that the automation mode (contact) has not changed in the meantime. The only way to resolve the issue is to save and exit the session and then reopen it. This then works again until the next bug. Anyone have an idea to fix this problem? The Icon helpdesk sends me back to Bandlab because the signal the MIDI Qcon sends does not change over time. So the bug would come from Cakewalk.

I installed the last Cakewalk update and Qcon Pro X firmware is up to date.

Thank you very much for your help.

Olivier

Edited March 28, 2021 by Olivier Bilquin

[xaqmusic]

I am having a similar issue.  It seems that after writing automation in a certain mode, switching modes has no effect.  Or the bug could be in enabling automation write via Remote Control.

For example, I wrote a lot of automation in Touch mode using the mouse.  Then, with an Akai MidiMix, I am going back in Latch mode for refinement.   I also assigned the write buttons to button on the Midimix so I can punch in and out of write mode on the fly.   I can see the automation write button go red and show the L for latch, but the track is not actually going into write mode (no autmation is written even if I'm in Overwrite mode).  If I click the write button with the mouse, it works.  Also, if I click write on the lane I want to automate (channel EQ HPF freq for example), the selected lane will go into write mode.

Certainly seems like a bug.  Any ideas?

[tim grivas]

I am having the same kind of issue.

At first the automation is reading correctly.

The way it should work is, If automation is running while i am in touch, If I touch the fader. it overwrites, when I let go, the fader should fall back to the written data.

This almost always does not work

Then I go to "write" while in Touch.

When I write it, in touch, it records the data.

Then if I play it back, while still in write (Touch), the fader overwrites the existing data with a none moving fader level. Like it is in latch. this is an issue.

What this means is, Cakewalk users will have troubles recording automation with the QCON Pro G2. I hope this gets fixed soon. I am bummed.

This may not be a cakewalk issue but more of a qconProG2 issue. Qcon may have a bug in their Sonar mapping

Since this forum only lets you upload 5mb, I had to put the video of the issue on youtube. here is the YouTube Link.

https://youtube.com/shorts/wrCJ1v2MvUY

Edited April 5, 2023 by tim grivas

[msmcleod]

The QCON should be sending a Touch On message, either when you move the fader or when you touch the fader (if it's touch sensitive).  This should be followed by a Touch Off message, either when you remove your finger from the fader (if it's touch sensitive), or after a pre-determined timeout.

If it's not sending the touch on/off messages, then Cakewalk will auto punch-out if you've not moved the fader after 250ms.

However if it's sending the touch on message and no touch off message and/or the QCON is continuously sending fader levels, then you'll get the behaviour you're seeing.

I have similar issues on the Yamaha 01X, except in my case it's not automatically engaging automation recording when I move the fader.

If automation read is off, touch automation always works.  If it's on, then either its hit & miss, or I have to use the 01X's auto-edit mode - basically I have to hit the select button while 01X "auto edit" is on to punch in/out automation.

I hooked up MIDI-OX to monitor what the 01X was receiving/sending, and it looks like it's not sending fader movements shortly after receiving fader automation, and by this I mean there's literally no MIDI activity coming from the surface (so it's not the MackieControl.dll or Cakewalk). I suspect this is some internal protection mechanism to avoid the user fighting against the motor and breaking the fader.

Surfaces that have real touch-sensitive faders shouldn't have this issue, because as soon as you touch the fader it knows you're in control and it'll stop reacting to volume changes from the DAW.

When I get the chance, I'll try a real Mackie MCU and see if it shows similar results.

[tim grivas]

On 4/5/2023 at 7:59 AM, msmcleod said:

The QCON should be sending a Touch On message, either when you move the fader or when you touch the fader (if it's touch sensitive).  This should be followed by a Touch Off message, either when you remove your finger from the fader (if it's touch sensitive), or after a pre-determined timeout.

If it's not sending the touch on/off messages, then Cakewalk will auto punch-out if you've not moved the fader after 250ms.

However if it's sending the touch on message and no touch off message and/or the QCON is continuously sending fader levels, then you'll get the behaviour you're seeing.

I have similar issues on the Yamaha 01X, except in my case it's not automatically engaging automation recording when I move the fader.

If automation read is off, touch automation always works.  If it's on, then either its hit & miss, or I have to use the 01X's auto-edit mode - basically I have to hit the select button while 01X "auto edit" is on to punch in/out automation.

I hooked up MIDI-OX to monitor what the 01X was receiving/sending, and it looks like it's not sending fader movements shortly after receiving fader automation, and by this I mean there's literally no MIDI activity coming from the surface (so it's not the MackieControl.dll or Cakewalk). I suspect this is some internal protection mechanism to avoid the user fighting against the motor and breaking the fader.

Surfaces that have real touch-sensitive faders shouldn't have this issue, because as soon as you touch the fader it knows you're in control and it'll stop reacting to volume changes from the DAW.

When I get the chance, I'll try a real Mackie MCU and see if it shows similar results.

I look forward to your findings.

This issue has been present since day ove. I am dissappointed I can not read/ write automation using the G2 and Cakewalk.

[msmcleod]

26 minutes ago, tim grivas said:

I look forward to your findings.

This issue has been present since day ove. I am dissappointed I can not read/ write automation using the G2 and Cakewalk.

Sorry, I meant to reply to this sooner.

I did try automation out on a real MCU, and things were far more straightforward.  I didn't see the behaviour you're seeing with the G2.

The MCU faders are touch sensitive, so automation recording starts as soon as I touch the fader.  IIRC Cakewalk was correctly punching out as soon as I stopped touching the fader, however if I left my finger on the fader without moving it, it would automatically punch out after 250ms.  I spoke with Noel regarding this, and this is expected behaviour.

At no point did it switch to latch mode, or behave as if it was in latch mode like you are seeing.

[tim grivas]

8 minutes ago, msmcleod said:

Sorry, I meant to reply to this sooner.

I did try automation out on a real MCU, and things were far more straightforward.  I didn't see the behaviour you're seeing with the G2.

The MCU faders are touch sensitive, so automation recording starts as soon as I touch the fader.  IIRC Cakewalk was correctly punching out as soon as I stopped touching the fader, however if I left my finger on the fader without moving it, it would automatically punch out after 250ms.  I spoke with Noel regarding this, and this is expected behaviour.

At no point did it switch to latch mode, or behave as if it was in latch mode like you are seeing.

NP, Thanks for the reply,

Cake walk never switched to Latch mode (Visual from Write button (T to L), but the bahaviar did. I think you are spot on with the idea, touch command from G2 is being sent before it stops sending that kind of data, so from this, since no touch off cammand is being sent, the G2 remains in latch mode.

I understand, the G2 is only sending commands and not actually in latch mode, but underneith the YI, someting is not swicthing to touch when the finger is not on the fader anymore. This strangness may be a higher communication that is not triggering the display on cakewalk to shpw latch,,, so the isssue is latchiing but the SW does not set the correct info to switch the UI i guess....

Edited April 25, 2023 by tim grivas

[tim grivas]

OK All,

I am getting regurlar responses back from ICON Tech Support.
At first they could not replicate the issue, but then after digging deeper, he started seeing some anomalies that were concerning.

It was told to me that they are getting to the bottom of the issue. It is hard for them to argue with the video i created. 

Any way,,,  I will com back once they confirm a fix. I am sure this will need to be a new Formare update,,,  or, they will blame it on cakewalk (with evedence).

Edited May 2, 2023 by tim grivas
spellcheck

[tim grivas]

On 4/25/2023 at 11:47 AM, msmcleod said:

Sorry, I meant to reply to this sooner.

I did try automation out on a real MCU, and things were far more straightforward.  I didn't see the behaviour you're seeing with the G2.

The MCU faders are touch sensitive, so automation recording starts as soon as I touch the fader.  IIRC Cakewalk was correctly punching out as soon as I stopped touching the fader, however if I left my finger on the fader without moving it, it would automatically punch out after 250ms.  I spoke with Noel regarding this, and this is expected behaviour.

At no point did it switch to latch mode, or behave as if it was in latch mode like you are seeing.

I understand what your saying. At no point have I mentioned or have I left my finger on the faders. I always remove and it still writes. It is not punching out when I release the fader. This is the problem they are looking into.

[tim grivas]

OK Folks, I got news that the US ICON tech support is able to replicate the problem They contacted me this morning and said, they are writing it up in detail and will send it to china for them to resolve. They are very responsive with this issue once I got on their radar.

Now we wait.