General > Control Surfaces/ACT

ACT mapping feature order bug (obsolete, simpler solution is published).

(1/1)

azslow3:
UPDATE: see "How to make ACT Lean button work in any Sonar version" thread.

UPDATE: after more tests...
UPDATE: thanks to icontakt in Official Forum, I have understood that for some people the mapping works ok. In fact they only think it works ok... read on.

SONAR saves new mapping in two different files: genericpluginparams.xml (Generic mapping) and sonaract.xml (Surface mapping) files, but it reads all "*.xml" files in the directory. When something "clash" (for example SONARX1act.xml with sonaract.xml), Sonar no longer work as expected.
Leave at most sonaract.xml and genericpluginparams.xml in the directory, DELETE all other XML files there!

The information in the first one is auto-created (according to the rules which can be written at the beginning) once you ACT focus new plug-in. Information is the second one is updated in case you ACT Lean in some particular plug-in.

The problem is that the information is not saved the same way. In the Generic file:

* only parameter name to ACT control type mapping is saved.
* last mapped controls are put as FIRST in the list
* each parameter is mentioned only once (after Sonar restart, the subject of other conditions...)
In the ACT file:

* mapping between parameter and concrete control is saved, in addition to the type
* ordering in the file is not important since the mapping is to concrete control
* only surface in which you have done the mapping is considered, for other surfaces the information is updated throw Generic (and so, the order will be different)
* each parameter appears as many time as it was assigned, even when assigned within the same or different control type
At some point Surface file can be corrupted and it is no longer influencing the mapping, which has bad and good consequences.
When Surface file is still in tact:

* + there is no visible "ordering" bug after Sonar restart (order of control assignments during ACT Learn is saved incorrectly)
* - in other surfaces you still observe the ordering bug
* - moving parameter to different type does not remove previous assignment (for this surface!)When Surface file is corrupted or zeroed:

* - you always have ordering bug
* + what you see is consistent for all surfaces
* + moving parameter remove it from the previous location (after Sonar restart)

Taking that into account, in case you have just one surface and use only one ACT control type for mapping, you can prefer to keep the file working. For me, it is better when it is NOT working.

Both files are auto-created in case they are removed. But when Surface file is corrupted it stay corrupted, without other indications apart from ordering bug after Sonar restart. So, the file with zero size will stay with zero size (not recreated since "currupted").

To "disable" surface file create empty text file on place of sonaract.xml

Workaround for ordering in case of corrupted Surface file:
1) move all parameters to destination control types (rotor/slider/btn)
Restart SONAR for clear picture (remove act file if you do not use it, or keep it corrupted)
2.a) start ACT Learn
2.b) touch ALL parameters within one control type, starting from the LAST in the
virtual ACT controls sequence using your CS (not mouse!)
2.c) stop ACT Learn and save the result
That will put the result right into genericpluginparams.xml
3) restart SONAR to check

Navigation

[0] Message Index

Go to full version