Time to resurrect this gem once again!
So I'm back in this same project after all these years, using ACE 1.4 (rev 3896) in Live 9.7.2 64 bit... the parameters being automated are weird again, not what they should be (see post #2)...
What's my best move to bring this project up to date once & for all, so that it's always going to work with future versions of ACE?
ACE 1.1 - automation changes breaking old projects
-
- KVRian
- Topic Starter
- 607 posts since 23 Jun, 2005
-
- u-he
- 30192 posts since 8 Aug, 2002 from Berlin
Honestly, I don't know what to do.
The culprit is that publicparams file which is installed on the Mac version but it isn't installed on the Win version. This file was however installed on our test systems, so that it never occurred to us that this was missing, i.e. we couldn't reproduce it. We thought it was single cases where this file was missing, but it's actually all installations on Win.
Unfortunately we have no answer to this issue which just solves it. Our current idea is to replace ACE with a 2.0/XL version, but there is no time frame for this.
The best way would be using the current publicparams text from the Mac version, but it involves updating all project files. Which I guess isn't an option for everyone. However, we might have to release an update with a fixed installer during our next round of updates.
The culprit is that publicparams file which is installed on the Mac version but it isn't installed on the Win version. This file was however installed on our test systems, so that it never occurred to us that this was missing, i.e. we couldn't reproduce it. We thought it was single cases where this file was missing, but it's actually all installations on Win.
Unfortunately we have no answer to this issue which just solves it. Our current idea is to replace ACE with a 2.0/XL version, but there is no time frame for this.
The best way would be using the current publicparams text from the Mac version, but it involves updating all project files. Which I guess isn't an option for everyone. However, we might have to release an update with a fixed installer during our next round of updates.
-
- KVRAF
- 1645 posts since 12 Dec, 2012 from Switzerland
Not sure if Live features such a thing, but in Logic you can transform existing automation data to any other type of data: automation, MIDI, etc. pretty easily.
Sure, this is a manual task and can be very tedious to do, if you have a lot of different automations.
Generally: There is always a risk when reworking older projects on a system, where you always update apps. The older it is, the higher the risk gets it won't play back properly anymore. Sadly I don't know of any easy solution to that. Total recall is not 100% sure on DAWs.
Sure, this is a manual task and can be very tedious to do, if you have a lot of different automations.
Generally: There is always a risk when reworking older projects on a system, where you always update apps. The older it is, the higher the risk gets it won't play back properly anymore. Sadly I don't know of any easy solution to that. Total recall is not 100% sure on DAWs.
stardustmedia - high end analog music services - murat-
- u-he
- 30192 posts since 8 Aug, 2002 from Berlin
Well, it is utterly depressing.
We had hoped that we could fix it in a similar way as the Presswerk ID mismatch, by providing a tool which converts project files. But this doesn't work since we can't distinguish which version of ACE in combination with which publicparams txt was used to create the file (among other things, such as the sheer number of host project file formats). Similarly we discussed auto-detecting the version on project load, but again there is no way to determine the parameter layout used to save the project.
We discussed making the parameter layout a user choice. But that doesn't reflect reality in that many hosts don't allow for updates of the parameter list, and if, might change automation with it. Also, a choice might break more projects than it fixes.
In the end, only two solutions are possible:
a) make a new ACE with a new binary that sits side by side with old ACE, ensure compatibility in future projects
b) include final, ultimate publicparams txt in Win version as well, but break *all* existing automation on Win
IMHO a) would be the best solution. It's the one we opted for some time ago, but it obviously takes years to materialize. It has the advantage that its the least work for existing users. OTOH b) is a quick solution, but it involves a lot of work on users side, probably much more than not doing anything. Which is why we went with a) in the first place.
As an intermediate solution - while waiting for a) to happen - we could provide publicparams txts with the parameter layout from each version we ever released. So that, if an old project doesn't open, one can close the host, pop in the right txt file and reopen the project.
We had hoped that we could fix it in a similar way as the Presswerk ID mismatch, by providing a tool which converts project files. But this doesn't work since we can't distinguish which version of ACE in combination with which publicparams txt was used to create the file (among other things, such as the sheer number of host project file formats). Similarly we discussed auto-detecting the version on project load, but again there is no way to determine the parameter layout used to save the project.
We discussed making the parameter layout a user choice. But that doesn't reflect reality in that many hosts don't allow for updates of the parameter list, and if, might change automation with it. Also, a choice might break more projects than it fixes.
In the end, only two solutions are possible:
a) make a new ACE with a new binary that sits side by side with old ACE, ensure compatibility in future projects
b) include final, ultimate publicparams txt in Win version as well, but break *all* existing automation on Win
IMHO a) would be the best solution. It's the one we opted for some time ago, but it obviously takes years to materialize. It has the advantage that its the least work for existing users. OTOH b) is a quick solution, but it involves a lot of work on users side, probably much more than not doing anything. Which is why we went with a) in the first place.
As an intermediate solution - while waiting for a) to happen - we could provide publicparams txts with the parameter layout from each version we ever released. So that, if an old project doesn't open, one can close the host, pop in the right txt file and reopen the project.
-
- KVRAF
- 37405 posts since 14 Sep, 2002 from In teh net
I always felt having a seperate text file for this was gong to cause problems, it's been a constant pain trying to maintain my Kore template for ACE, eventually ended up making 2 versions. Why not put a legacy compatibility switch in the plugin?
-
- u-he
- 30192 posts since 8 Aug, 2002 from Berlin
It's not just one switch... it might be many.aMUSEd wrote:I always felt having a seperate text file for this was gong to cause problems, it's been a constant pain trying to maintain my Kore template for ACE, eventually ended up making 2 versions. Why not put a legacy compatibility switch in the plugin?
But yes, the text file is cause of the issue, but it was also the solution for it. Back in the days when some hosts only made a limited number of parameters available for automation, it seemed like a good idea making it a user option. It opened a can or worms.
However, the same issue isn't one for Zebra2, which has relied on a similar text file for as long. But there, it always got installed on both platforms.
-
- KVRAF
- 24411 posts since 7 Jan, 2009 from Croatia
Interesting that that text file never worked for renaming automatable parameters here with Reaper... 
-
- u-he
- 30192 posts since 8 Aug, 2002 from Berlin
Yeah... I think that feature was short lived for whatever reason. It worked once, then never again. It was always merely meant to be a way to edit the order.EvilDragon wrote:Interesting that that text file never worked for renaming automatable parameters here with Reaper...
-
- KVRAF
- 24411 posts since 7 Jan, 2009 from Croatia
Too bad. I'd appreciate being able to rename parameters
-
- KVRian
- Topic Starter
- 607 posts since 23 Jun, 2005
I quickly tried a brute force fix yesterday - manually moving the automation from the incorrect parameters to the correct ones... this particular project only has 3 parameters being automated on this ACE instance so I'm cool with manually creating a "2017" version so it can work with ACE 1.4 (and hopefully future versions)...
...but when I was done, it didn't sound the way it should... something else must be going on (and not necessarily related to ACE either).
Urs - is there a repository of previous ACE builds online somewhere? Next step is to try & find the exact version I used to make this project in the 1st place, so I'm starting from the right place.
...but when I was done, it didn't sound the way it should... something else must be going on (and not necessarily related to ACE either).
Urs - is there a repository of previous ACE builds online somewhere? Next step is to try & find the exact version I used to make this project in the 1st place, so I'm starting from the right place.
-
- u-he
- 30192 posts since 8 Aug, 2002 from Berlin
Try this:mustgroove wrote:Urs - is there a repository of previous ACE builds online somewhere? Next step is to try & find the exact version I used to make this project in the 1st place, so I'm starting from the right place.
https://uhedownloads-heckmannaudiogmb.n ... rchive/ACE
-
- KVRian
- Topic Starter
- 607 posts since 23 Jun, 2005
Thanks so much Urs!