Let's have a huge overhaul in automation/control surface mapping

I've never heard anyone express their love for ACT. It's horrible, counter-intuitive, unreliable, inconvenient and just plain DOES NOT WORK PROPERLY. Every time I try to use it I end up wanting to headbutt the screen. And I have an A-800 PRO, which in theory should work great with ACT. It doesn't! 
 
I get the idea and motive behind it. To be able to have your control surface automatically map to Sonar transport and mix controls. To be honest I haven't used it for this because I'm quite happy clicking at mix controls on screen during mixing. What I really want to do is map my control surface to synths and plugins so that I can perform the controls, for instance the cutoff filter on a synth. I want to be able to set up the mapping, write enable the track, and perform some automation data to an automation lane. ACT is horrible for this because oftentimes the mappings just don't work. And while you can also set up controls on the synth rack and remote control them, again this doesn't always work depending on the synth and besides it's just too many steps. 
 
I believe you should be able to make quick and easy mappings from your control surface to automation envelopes. Sonar can input data from your control surface, synths & plugins make their parameters visible to Sonar automation envelopes, so why not just connect the two and have a mapping from control surface to envelope? I believe you should be able to set a mapping on the automation lane itself and it should be as easy as clicking a MIDI learn button on the lane and twiddling your control. From then on, whenever that MIDI track has input echo enabled, the mapping is active. 
 
Performing synth and effect controls with control surfaces is a huge part of modern music (and synth music in general) and should be quick, intuitive, hassle free and foolproof. Right now it's not, and I feel like this is one area in which Sonar needs to improve immensely, especially if it wants to win favor with the emerging breed of electronic musicians. 

BobF
Hopefully somebody will merge all of the control surface support FRs ...

I hope not because this thread is about ACT, which is hopefully still of interest to Cakewalk
 
Control surfaces are dead outsourced to hardware vendors who don't do anything either unfortunately put as much effort into it as Cakewalk did in recent works

+1000
 
It's unreliable and I can't trust it.  I've had to delete the config file (can't remember it's name) to get it to stop trying to map duplicate settings - of course losing all the mapping I did etc. 
 
It tries to do too much and anticipate what I want to do.  Just give me  a text file or something I can edit and setup the mappings instead of the "live" config that doesn't work.

 
I would like to use ACT to quickly map a few parameters so that I can twist a knob during a performance. I am not super interested in creating permanent mappings because I can never remember what's mapped to what. Unfortunately, ACT (particularly the ACT MIDI Controller) is so unreliable that I can't use it this way. I mainly just use Automap for the task.
 
The biggest issues that I encounter are:

• ACT tries to combine the UI for configuring the MIDI input and mapping to the plugin. Let me see the MIDI CC coming from the hardware and verify that this works
• ACT consistently frequently fails to recognize the parameter being changed on the plugin. This is particularly noticeable in Reaktor Ensembles.
• ACT gives no way to manually set a parameter when it is having trouble picking up the motion of that parameter in the plugin

This works perfectly with Automap and it also works perfectly in Studio One. (Honestly, S1's implementation of this whole area is an amazing bit of work. Very fast, accurate, intuitive, and makes the details visible enough to troubleshoot with but not so visible that they overwhelm the real work going on.)
 
Edit: ACT not recognizing the parameters happens often, but not every time.

AndyDavis
I would like to use ACT to quickly map a few parameters so that I can twist a knob during a performance. I am not super interested in creating permanent mappings because I can never remember what's mapped to what. Unfortunately, ACT (particularly the ACT MIDI Controller) is so unreliable that I can't use it this way. I mainly just use Automap for the task.

http://www.azslow.com/index.php/topic,206.0.html
 

The biggest issues that I encounter are:

• ACT tries to combine the UI for configuring the MIDI input and mapping to the plugin. Let me see the MIDI CC coming from the hardware and verify that this works

AZ Controller shows you incoming MIDI messages and what it does with them
 

• ACT consistently fails to recognize the parameter being changed on the plugin

I have never seen that, except with VST3 (Sonar has nasty bug) and parameters not exposed by plug-ins (there are several examples, and Automap is also can not work there)
 

• ACT gives no way to manually set a parameter when it is having trouble picking up the motion of that parameter in the plugin

AZ Controller does. You can use either ACT way (ACT Slider 7) or "direct" way (Track 5, FX 2, parameter 8). Tracks and FX/Synth can be referenced by name.
 

This works perfectly with Automap and it also works perfectly in Studio One. (Honestly, S1's implementation of this whole area is an amazing bit of work. Very fast, accurate, intuitive, and makes the details visible enough to troubleshoot with but not so visible that they overwhelm the real work going on.)

AZ Controller can not compete in simplicity with Automap. Its good side is flexibility, I do not think any other technology can beat it there. But that has a price, if you can do everything you can do nothing simple...
 

Mystic38
Also have tried ACT several times over the last 6yrs+ and each time gave up in frustration.. lost connections, lost mappings, you name it, its happened to me.. 

Read the link I have posted in #6. Once you understand where the bug is, you can work around it.
 

So a very large +1 to a reliable improved, updated or replaced control surface mapping feature with bidirectional communication.

I am just asking to fix several obvious bugs on Sonar side... I still see nothing in the Everett changes list. The rest I can do myself. And just for completes, AZ Controller is bidirectional.
 
I know that this post sounds like a self advertisement. But I do not sell anything. As you, I have found existing Sonar Control Surface mapping/integration/features not capable/not working/outdated. And I have asked myself either I can do that better (I am n00b in mixing, but not it programming, at least I think so). Simplicity was not my target (so far). But I like the freedom. I have realized that one-to-one mapping (as with "Midi learn" or MIDI mapping matrix in Synth) is not a good solution for general DAW control. After a year, something was ready to present in public. You can now see far advanced version of that. And the work is still in progress, thanks to ideas, requests and suggestions from other.
 

AndyDavis
Although I do appreciate the effort you have put into developing and supporting AZ Control, I consider it a workaround for functionality that is badly broken in Sonar. My particular workaround is Automap.
 
I'd like Cakewalk to fix things so workarounds are not needed. They have such a wonderful core, it's distressing to see this sort of rot around the edges.
 
 

I would love for Cake to adopt az's work.  Work-arounds are fine but I always consider continuity to be equally as important as functionality.
 
I'm not interested in investing effort into something that might be obsolete the moment az is.

The problem is that Cakewalk's integration with hardware is very poorly done. That's the topic of the thread.
 
AZ and Automap address this problem differently, but you probably wouldn't have developed AZ and I probaby wouldn't use Automap if Controller integration worked well (or at all) in the first place. That's what I meant by workaround. It's not that either AZ or Automap are bad, it's that we really shouldn't need them at all.
 
All that said, I think that further discussion of either is a distraction from the topic of this thread.

I think it speaks volumes that Cakewalk have put all the data for Control Surfaces out into the public domain.

Let someone else develop the software, and while that's happened with Alexey, Cakewalk still need to do work at the back end to make it properly workable for anyone that does that. I can't see them spending the time to do it. I wish it were different