Forum rss-feed

Forum

Software: Setup upgrading / incremental loading etc.

Most Recent

written by: john

Hi 0beron

Setups are not Belcanto scripts, they are a copy of the internal state (the bits that can change) of the whole of EigenD and Agents it is running at the point you saved it. You can write a setup as a big Belcanto script (this is in fact how we create the starting point for the factory setups) but that takes a lot longer to run, and the save/load of setups (and the files it creates) are not implemented in this way, it would be way too slow in use.

When you move between two setups, EigenD does do a comparison between them and only changes those things that need to be changed. This is not that efficient at the moment (as you will see watching it happen in the progress bar) because the names of Agents are not in fact fixed, so one Agent that is called 'Sampler 1' might in fact be a different Agent than another in a similar setup, if that similar setup was not derived from the first. There is an underlying, invisible (and not human readable) name of an Agent that is used for the comparison and if this is different (which it will be if you created the Agent from scratch both times) then you may find the setup manager replacing one 'Sampler 1' with another 'Sampler 1', even though they are actually, to all intents and purposes, identical.

In the 2.X series we intend to change this so that we introduce both 'Proper Names' and 'Aliases'. This will make transitions between similar looking setups much faster, as the setup manager will be able to understand when an Agent is actually the same in each, rather than having to rely upon some very unclear clues.

Proper names will be immutable, ie, they cannot be changed after you have created the Agent, and Aliases will be the name one normally uses for an Agent. Proper names will also contain the name of the EigenD that the Agent resides in (to support multiple interconnected EigenD's and OSC in the future) and possibly also support a namespace convention for Rigs, to allow independent names inside those, which will become more important as we evolve Rigs to be more flexible.

To answer your last question, when we release a new version of the stable software, we write upgrade scripts so that the previous factory setups and setups derived from them will be migrated from the old software to the new. We do this when you open them, not at install time, as it can extend the time taken for an install considerably and we didn't think people would want to wait, especially is they had hundreds of saved setups. These upgrade scripts can be very complicated to write and test, so we don't support them while we're running the unstable branch, if we had to we wouldn't be able to have 'unstable' in public use as the release cycle time would have to be way too long, which I think would be a shame. Many changes don't require an upgrade script as they have minor effects on setups (and if the changes just include an addition to a setup, they don't need a script at all) so often things are fine, and sometimes we include the upgrade script in the unstable release anyway, to help us test it.

There have been quite a few changes (most of them invisible and connected with the Windows release) between, 1.1 and 1.2 but I think that by now the upgrade process should work fine, so that sounds like a bug, although it does depend a little on what exactly your setup is. Did you make changes to it? If you did, and they involve plumbing it is possible that you've got routing issues that cannot be upgraded. So yes, please report a bug, but if you could let us know what that setup involves as well that would be very helpful.

John

written by: 0beron

Sun, 14 Nov 2010 07:45:08 +0000 GMT

Just want to check if my understanding of setups is right.

- A setup is essentially a giant belcanto script that builds your setup from the ground up. (Is this completely true? Or are there additional parts of a setup such as plugin and drum loop paths on your file system?)
- Setups are loaded incrementally, i.e. if I load a setup based heavily on Alpha 3 when Alpha 3 is already loaded, EigenD does some kind of diff between the setups and loads/modifies any parts that differ?

- When you load a setup in a newer version of EigenD, an attempt is made to update any of the parts of the setup that need modifying.
- A setup successfully loaded into a new version of EigenD might then be unusable in an older version?

If I am having trouble loading a setup I created in 1.1.21-testing into 1.2.5-unstable, is there any point in attaching the setup to a bug report, since it references a batch of plugins and loops that are specific to my mac, or doesn't this matter? How do I go about finding my setup in the filesystem?


written by: john

Sun, 14 Nov 2010 11:19:46 +0000 GMT

Hi 0beron

Setups are not Belcanto scripts, they are a copy of the internal state (the bits that can change) of the whole of EigenD and Agents it is running at the point you saved it. You can write a setup as a big Belcanto script (this is in fact how we create the starting point for the factory setups) but that takes a lot longer to run, and the save/load of setups (and the files it creates) are not implemented in this way, it would be way too slow in use.

When you move between two setups, EigenD does do a comparison between them and only changes those things that need to be changed. This is not that efficient at the moment (as you will see watching it happen in the progress bar) because the names of Agents are not in fact fixed, so one Agent that is called 'Sampler 1' might in fact be a different Agent than another in a similar setup, if that similar setup was not derived from the first. There is an underlying, invisible (and not human readable) name of an Agent that is used for the comparison and if this is different (which it will be if you created the Agent from scratch both times) then you may find the setup manager replacing one 'Sampler 1' with another 'Sampler 1', even though they are actually, to all intents and purposes, identical.

In the 2.X series we intend to change this so that we introduce both 'Proper Names' and 'Aliases'. This will make transitions between similar looking setups much faster, as the setup manager will be able to understand when an Agent is actually the same in each, rather than having to rely upon some very unclear clues.

Proper names will be immutable, ie, they cannot be changed after you have created the Agent, and Aliases will be the name one normally uses for an Agent. Proper names will also contain the name of the EigenD that the Agent resides in (to support multiple interconnected EigenD's and OSC in the future) and possibly also support a namespace convention for Rigs, to allow independent names inside those, which will become more important as we evolve Rigs to be more flexible.

To answer your last question, when we release a new version of the stable software, we write upgrade scripts so that the previous factory setups and setups derived from them will be migrated from the old software to the new. We do this when you open them, not at install time, as it can extend the time taken for an install considerably and we didn't think people would want to wait, especially is they had hundreds of saved setups. These upgrade scripts can be very complicated to write and test, so we don't support them while we're running the unstable branch, if we had to we wouldn't be able to have 'unstable' in public use as the release cycle time would have to be way too long, which I think would be a shame. Many changes don't require an upgrade script as they have minor effects on setups (and if the changes just include an addition to a setup, they don't need a script at all) so often things are fine, and sometimes we include the upgrade script in the unstable release anyway, to help us test it.

There have been quite a few changes (most of them invisible and connected with the Windows release) between, 1.1 and 1.2 but I think that by now the upgrade process should work fine, so that sounds like a bug, although it does depend a little on what exactly your setup is. Did you make changes to it? If you did, and they involve plumbing it is possible that you've got routing issues that cannot be upgraded. So yes, please report a bug, but if you could let us know what that setup involves as well that would be very helpful.

John



Please log in to join the discussions