Updating and Linked Sub-patches

[sephult]

I was just sitting here thinking about how I have a widely used sub-patch. More and more I am trying to organize better using polyphony, etc...

I realized I wanted to adjust some offsets to make this sub-patch more accurate, however now I need to go in each patch and modify or re-do each sub-patch used within.

I think it would be the most useful method to specify that a sub-patch to be updated and include a source path of the sub-patch. This way the most recent sub-patch is always used when the patch is loaded, and will reflect the changes.

By using this method various patches can be just opened and always include the latest changes, without complete rewire and/or patch editing.


-S

[CREDO]

+1
Yes, this would be great! (as an option, not default)

[sephult]

I agree, this should be optional, I would like to see this for both Sub-Patches as well as FastScripts

-S

[gurulogic]

+1 from me too. I use multiple copies of the same base patch in my racks too and it is a serious headache when I have to make some changes to my "template". I would like to see this option for main patches in a rack too.

[cmodica]

+1 YES ! the same for me

[ceasless]

This would be so very useful to have.

[senso]

this suggestion has been discussed many times.
And I'm still unable to find a solution and a good compromise between maintenance and backward compatibility.
I'm still thinking about it. be patient.
senso+++

[woodslanding]

You might want a completely different 'virtual' subpatch object, so there's no backwards compatibility issue at all.

Store the data in a specific subfolder in modules. Maybe an option in a normal subpatch to convert it to virtual. If you change the ins or outs in a virtual, it will break all your wiring, so I'd be in favor of disallowing that--create a new virtualpatch (save as) if you need different ins and outs. Then you can wire the new one in on a case-by-case basis.

But, since Usine exposes controls by default, you also wouldn't be able to add or remove any UI objects without risking breaking wiring.

Just thinking out loud, probably nothing you havent thought already....

[sephult]

Wouldn't this be an option that would work through IML almost like a linking file?

So once you build a user Patch, you could associate a new Module User ID with the name of your module.
(Not sure the limitations of the Module ID within the IML, but I assume it could be expanded with additional numbers for User?)
This module can then be actually placed within the Usine Library as a Common User Module that the IML can reference.
As an example a folder User can be made and Module ID 400-500 reference to this folder for modules)

An additional function IML of Replace Module (similar to how a Fader can be dropped over a Knob maybe).

So addition of User Defined Module ID, and an additional Replace Function. The only question is how to execute this.
Maybe a patch would have an option to Read associated IML file on load?

If the file does not exist it would ignore, this way once a patch is shared from a designer to the community it would just load the one in the .pat file.

Also a Patch Design rule would be to disable the patch load option before sharing with the community to prevent Cross-Load problems?

Just some suggestions

-S