4Devs: Migration Manager (Include) v1.2

Migrate script parameters between different script versions using the supplied ‘Migration Manager Include’ script snippet.

The Problem
————–
One can easily state-safe a script and reload its full settings including the scripts source
into another Mozaic instance – but if you change the source and do an ‘upload’ or load a
newer version of the script, all your precious settings are lost.

The Solution
————–

The ‘Migration Manager Script Include’ adds version independent script-to-script parameter transmission to any of your scripts, with minimal support from your code (add 3 event calls, and define 4 events for callbacks)

Migration Demo
—————-
* Load two Mozaic instances containing this demo script. Both will show differnt
random IDs on the right and have different pad colors. The SEL knob toggles the
display the three migrated arrays, all based on the ID.
* Save a new preset of the instance you want to transfer.
* In the receiver instance, double tap the IMPORT knob to start waiting for data
* Reload the saved preset in the sender instance.
* The ‘receiver’ will pick up the values of the arrays and the color scheme of the
‘sender’, but keep its ID (because that’s not transfered)

Migration Instructions for ‘End Users’
—————————————
* Before loading a new script version, save the to-be-preseved configuration to a new
preset name (either in the host or in Mozaic)
* Update the script to the new version by loading the script – this will come up with
the scripts default settings
* Turn the IMPORT knob of the script
* Open a second Moazic instance and load the save configuration, you have
ten seconds to do this
* The new version will pick up the configuration and you are ready to go

Use-Case for Script-Devs
————————-
If you are a script dev, you can use this feature to fast-restre your settings after
you minimally changed code and hit ‘UPLOAD’. Just keep the ‘sender’ instance open
and reload it when importing to the receiver.

Suitable Scripts
——————
– Your script should have many parmeters, more than you would like to dial in manually
either when updating or for every test during development the script
– Updating of the script should be intended

Adding the ‘Migration Manager’ to own scripts
———————————————–
You just need to add the ‘include part’ from the end of this script starting below the line
>>>>>>>> MIGRATION MANAGER INCLUDE <<<<<<<<
to the end of your own script.

Add an 'IMPORT' knob in your scripts GUI and call two MigrationManager event functions,
one at the end of your @OnLoad and the other when the 'IMPORT' knob is turned.

Your scipt also needs to define the 4 event functions @MigrateSend, @MigrateRead, @MigrateImportDone
and @MigrateExportDone that will be called be the Migration Manager. The comments
in these demo scripts functions point out what these functions need to do.

Other examples for Migration Manager Usage
———————————————–
* The 'MIDI MultiCast' script transfers its up to 7×16 routing scenes and config variables
* The 'MutatoR' transfers around 12KB of data in 13 migration steps

.

More Info
———————————————–
The blue ‘source code’ button to the right links to a in depth description containing the source code and instructions on how to add the snippet to own scripts

5 comments on “4Devs: Migration Manager (Include) v1.2
  • -ki on said:

    Updated to v1.1
    ==============
    + Support for scripts with various OnTimer handlings.
    + Added a lot more in-script documentation
    + Added logging during the migration steps on sender and receiver
    + Demo showcases the more complicated script type c)
    ….. Using an own OnTimer, but intended with slower timer interval
    ….. and not running after OnLoad
    ….. In that case the timer must be temporary re-configured.

  • -ki on said:

    Updated to v1.2
    ==============
    + Better support for multiple active instances of the Manager in
    … several different scripts in one host session

  • -ki on said:

    Re-Upload of the script with a minor modification:

    I removed the state-saving of the id variable so that each instance will always come up with a different random id.

    If you loaded two instances of the previous version, these came up with the same id (due to state-saving) making it quite unclear that data is transported from one instance to the other.

    Thanks to Andy Honeybone for pointing this out.

    The Include itself didn‘t change, so i kept the version number v1.2

  • -ki on said:

    Added link to source code and documentation on Audiobus Forum Wiki

  • -ki on said:

    Another minor update (no version number change as the Include Snippet code is still the same v1.2 as before)

    I changed the value used for mmScriptId of this demo to not interfere with the id used by the new script “MS6 SysEx Performance Editor” and added some comments regarding the need for unique mmScriptId’s to the source.

    The Audiobus Forum Wiki dokumentation now contains a short section about mmScriptId and a list of already reserved id ranges.

  • Leave a Reply

      1941 PM
    • Platform:
    • Category: Utility
    • Revision: 1.2
    • License: Creative Commons Attribution Share Alike 4.0
    • Modified: 3 years ago
    • Views: 114
      Likes: 4
      Downloads: 12
    Download