Three ways to use ACTThere are several approaches to use ACT with controller.
The original one is to map one parameter to one control (in one bank, with some mod keys, etc.), in other words predefine mapping between some control and parameter in plug-in. The mapping is permanent then and is called every time this plug-in is focused. While sounds good, there are several problems with that. First, you not always have sufficient amount of controls and you have to define many banks (in AZ Controller the number is not limited). Second, it is hard to remember which control doing what, especially in case you do not use them frequently. Third, it can be time consuming to make good ACT maps for all plug-ins you have. Forth, there is plenty of bugs in the assignment procedure.
The second approach is to map what you need when you need. You do not have to pre-map and the number of controls is not important. Once you want control some parameters with some controls, you switch "ACT Learn" mode and do the assignment. And you can reassign when you want. There are 2 problems: it is a bit time consuming every time you need the assignment ("ACT Learn", touch parameter, touch control, "ACT Learn", confirm mapping), and more important, when you reassign controls you change parameters to which controls was mapped before.
And now,
the third option exists. You can
"Speed deal" the parameter which was changed as last. So, you can have "Speed deal" encoder which will control the last parameter you have changed using mouse. No other operations required.
Please note that I do not claim I have "invented" any of these approaches, the third one inclusive. "Speed deal" is used in many devices and applications. Also note that "Speed deal" for previous parameter modified by AZC exists from the first version (was thought to make one dedicated control "precise tune" anything, in fact you can combine both functionality), but tiny addition to make it work for ACT was not there (in the Overview Tab you could always see the last changed ACT parameter, you just could not "Select" it).
Configuring ACT "Speed deal"Please complete "Quick start" tutorial first, I do not want to repeat how to add and assigned the encoder. I will show how to change the configuration.
- Switch to the "Logic" Tab
- Click on "Track Volume" Action (the first in the list)
- In the Action Configuration, change "Strip" to "Function". Select "ACT last change" "Select".
- So, you should have 2 Action now: "Select last changed ACT" followed by "Direct linear"
- Press "New". Change "Undefined" to "Monitor". Change "Monitor parameter value" to "Timer". Leave "Normal" speed.
- Change to the "Feedback" Tab. You should see "Rotor 1 : : Timer" here (with empty list of Actions)
- Press "New". Change "Undefined" to "Function". Change "Set status" to "ACT scan changes"
Focus (with mouse) some plug-in. And change some parameter. Now turn your encoder, you should see that you control the same parameter. If not:
- Switch to the "Overview" Tab. Do you see the name of selected plug-in in "ACT map" box? Please let me know if not.
- Again modify the parameter. Do you see it in the "Last changed ACT parameter"? If yes, check that you have no mistakes in configuration
- If no, there can be two reasons:
- There is no ACT mapping for that parameter. Check "ACT" tab, and try to "ACT Learn" it using the manual to some (any!) ACT control.
- Some parameters are not ACT mappable (plug-ins bug). Nothing we can do in addition to inform the producer that this parameter "can not be automated" (it is general property, not SONAR or ACT dependent)
ExplanationsEvery time you look at "Overview" Tab you see "Last changed ACT parameter", even in case you have not configured "Scan" in "Timer" yet. So, you can ask why we need the timer. As defined by SONAR CS API, scanning for changed parameter is CPU intensive. I am not concerned when the Property Page is opened. It is not optimized for speed in any case. But once you close it, there is no scanning by default. In case you do not want "Speed dial", there is no reason to keep your computer busy. So you should specify when you need this scanning.
In can happened that you have "Speed dial" control in some configuration mode. In this case, it make sense add corresponding condition to the Timer, so scanning is done in that mode only. It is too hard to automatically deduct from arbitrary configuration either it is currently required or not.
