Sub Patch Global Update

[sephult]

I currently am using some custom subpatches that I use throughout a parent patch.
I found I need to make a modification for efficiency in the sub-patch.

Is there anyway to modify the sub-patch and inherit the changes throughout without having to modify each subpatch in the parent?
If not this seems like it might be an extremely useful function.

-S

[woodslanding]

Yeah, I asked for this before in v5. Max supports this, Reaktor doesn't.....

You can sometimes get this effect by using polyphony.... but only if you use the subpatch in the same way each time....

My wkp is based around a 16 ch mixer. I use poly to create it. Then when I fix a bug, I don't have to do it 16 times.

But I agree, this would be very powerful. I guess user modules work this way. But it would be nice to have subpatches be able to do the same.

-eric

[Thomas Helzle]

Could be an option in the module/subpatch etc. if it should be an "instance" or not.
If you set it to "instance", nothing can be changed inside, only the "master" can be changed which is reflected in all instances.
It's a pretty common idea in graphics, especially in 3D.
There you often have the option of making a copy or creating an instance/clone.

A more advanced form allows for local changes where only the unchanged parameters are inherited from the master instance and everything you change is kept local.

The latter could be too involved for Usine, but basic instancing would be very useful sometimes.

A typical problem arises, if you for instance have a custom mixer and use it in several workspaces. Now when you change the master - should it update throughout all projects using it (can be dangerous) or not (could defeat the purpose).
Quite a can of worms in the end

Cheers,

Tom

[woodslanding]

One thing you absolutely need to do is disallow changing any inputs or outputs on an instanced subpatch!

Unfortunately, usine does not allow you to specify the exact ins and outs you want on a subpatch, which complicates this. Certain objects always present ins and outs, whether you want them exposed or not--a long-standing complaint of mine..... so you can't exactly code to an interface in an OOP way. If you change a control type internally, it may change the ins and outs, even though the user's intended interface has not changed!

I think if you do not have absolute control over the subpatche's interface, instancing is a bad idea.

[Thomas Helzle]

Yeah, I guess you are right.
In Softimage XSIs very advanced node editor, you define in's and out's for compounds (=subpatches) by hand, dragging wires from your internal nodes to in and out-boards on the left and right, defining their data formate, order, names etc. This way you can change internal structures without problem.

Not sure if this would make Usine too complicated for the intended use, but it sure feels cleaner and more reliable.

Cheers,

Tom

[ceasless]

I agree with woodslanding that it is unfortunate not to be able to carefully design the ins and outs of subpatches. I'm new to this, but AFAICT I already need to route to a MIDI out from a 'Create MIDI' module in the sub-patch if I want to have it show up as an out when viewed in the parent patch. That feels inconsistent next to the various ins and outs that just appear in a seemingly random manner.

[Thomas Helzle]

I could be wrong, but I think Usine HH has a kind of logic to the auto-created inputs/outputs, where inputs that are further up the y axis are shown above inputs that are lower down on the y axis.
But don't quote me on that

But I agree, just user defined inputs and outputs would be preferable, even if the other things talked about in this thread shouldn't be possible.

Cheers,

Tom