FR: MUX / composer pooled copies

[masterjoe]

Currently every module in MuLab is independent from others.
When you design a useful MUX and want to use it multiple times you have to copy it.
It would be cool to be able to have pooled copies of MUX and composer modules so that changing one instance of such a pooled copy would also change the others. This would allow arrays of the same (complex) modules and still be able to change the inner workings of the original design.
Pins would allow to feed different data into each of the instance and produce individual effects. You could regard the pin input as instance data.

Of course you should be able select whether to use a pooled copy or a regular copy. Also the conversion of a pooled copy to a "real" copy shall be possible.

Hope you like the idea.

[fde101]

Not sure if this limitation still exists in ML9, but going by the free version of ML8, it does not seem to be possible to map a meta-parameter (MP1, MP2, etc. across the top of a Modular Area) to control a meta-parameter of a child modular area (one contained within that parent).

Another issue I ran into was not being able to show the Front Panel (UI view) from a child within the Front Panel of the parent - that is, if I design a Modular Area with a Front Panel, and I make three or four copies of that Modular Area to use within another Modular Area, there does not seem to be any way to present that Front Panel design, or even to copy/paste that Front Panel design, to use it within the parent's Front Panel. I need to recreate the whole thing from scratch each time.

This general lack of provision for reuse of designs and modules struck me as a rather strange limitation given the rest of how the program appeared to be designed, and is one of the primary things that is holding me back from making a purchase.

[masterjoe]

Not sure if this limitation still exists in ML9, but going by the free version of ML8, it does not seem to be possible to map a meta-parameter (MP1, MP2, etc. across the top of a Modular Area) to control a meta-parameter of a child modular area (one contained within that parent).

Another issue I ran into was not being able to show the Front Panel (UI view) from a child within the Front Panel of the parent - that is, if I design a Modular Area with a Front Panel, and I make three or four copies of that Modular Area to use within another Modular Area, there does not seem to be any way to present that Front Panel design, or even to copy/paste that Front Panel design, to use it within the parent's Front Panel. I need to recreate the whole thing from scratch each time.

This general lack of provision for reuse of designs and modules struck me as a rather strange limitation given the rest of how the program appeared to be designed, and is one of the primary things that is holding me back from making a purchase.

Well, that's interesting - but my OT is about something else...

[fde101]

Well, that's interesting - but my OT is about something else...

It is actually quite related.

Without being able to link to the "MP"s as I am suggesting, if you have a set of "pooled copies" as you are calling them and you have something in one of those copies that is being controlled by a front panel control of whatever you nest each copy inside of, but then go and change the definition of the copies in such a way that some other newly added node is being used to achieve the same effect, you would in theory still need to go through and change all of the individual things which are using those copies in order to point them to the new thing that is providing that effect.

If you could point to the MPs instead of to the individual nodes within the pooled copies, then by redefining what the MP does (which is within the section that is shared among all the "copies"), the need to update all of the individual containing things is eliminated (or at least significantly reduced).

Similarly, if the front panel of a contained node can be presented as a whole on the parent node's front panel, then when you have one of these pooled copies and update its front panel, everything which has one of those copies embedded has its front panel user interface updated to match. Without this, you would need to go through and update all of the front panels manually if you change, for example, the range of one of the controls.

[masterjoe]

Not sure if this limitation still exists in ML9, but going by the free version of ML8, it does not seem to be possible to map a meta-parameter (MP1, MP2, etc. across the top of a Modular Area) to control a meta-parameter of a child modular area (one contained within that parent).

Another issue I ran into was not being able to show the Front Panel (UI view) from a child within the Front Panel of the parent - that is, if I design a Modular Area with a Front Panel, and I make three or four copies of that Modular Area to use within another Modular Area, there does not seem to be any way to present that Front Panel design, or even to copy/paste that Front Panel design, to use it within the parent's Front Panel. I need to recreate the whole thing from scratch each time.

This general lack of provision for reuse of designs and modules struck me as a rather strange limitation given the rest of how the program appeared to be designed, and is one of the primary things that is holding me back from making a purchase.

Mapping MP parameters through a complete nested structure is possible now in V9.

I agree that the UI editor is currently very limited. You can't:
- multi select elements (e.g. with a selection rectangle)
- save and load presets
- copy and paste elements across designs
- easily edit properties of UI components
- link UI elements to module target manually or edit exisiting links

Personally I think the UI should itself be a module with input and output pins. With these pins you can connect stuff from the mudular area. The UI itself is just a processor like anything else.

I will place a FR about that

However I still think my OT is something complete different

[fde101]

Mapping MP parameters through a complete nested structure is possible now in V9.

Thanks, that is good to know.