MXXX: Combining devices?
-
- KVRist
- 452 posts since 21 Jul, 2018
I have created a number of device sections I would like to reuse in different devices. Each is saved as an MXXX preset with a built-out ez screen, but not saved for loading as a device. They all use the first 8-12 or so MP's.
So, for instance, I have a limiter/clipper section I would like to combine with an 808 builder section and then also separately combine for a different device that builds snares.
Is there a way to combine these sections and merge the EZ screens without having to (in the example above) separately open up the snare device and 808 device, and recreate the clipper/limiter section in each?
So, for instance, I have a limiter/clipper section I would like to combine with an 808 builder section and then also separately combine for a different device that builds snares.
Is there a way to combine these sections and merge the EZ screens without having to (in the example above) separately open up the snare device and 808 device, and recreate the clipper/limiter section in each?
- KVRian
- 1059 posts since 28 Jun, 2006 from Germany
Short answer: no.Annabanna wrote: Tue May 18, 2021 7:36 am Is there a way to combine these sections and merge the EZ screens without having to (in the example above) separately open up the snare device and 808 device, and recreate the clipper/limiter section in each?
You could think about loading MXXX inside MXXX (or the MXXX1 module for singleband version), which can have the easy screen available. Then you have to set up the MPs in the parent MXXX. It can need some work, but in the end it works.
System: Win 10 64 bit / i9 9900K (8x 3.6 GHz) / 16 GB DDR4-3200 RAM / 1TB M.2 SSD + 2x 500 GB SSD / RME Babyface / Reaper
Tagirijus.de
Tagirijus.de
-
- KVRAF
- 10375 posts since 2 Sep, 2003 from Surrey, UK
+1
Saving device component presets could save device designers a lot of time and lead to more devices for users. But it is almost certainly not straight-forward,
Saving device component presets could save device designers a lot of time and lead to more devices for users. But it is almost certainly not straight-forward,
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
Just had a thought: Maybe I don't need one EZ screen to rule them all. It's just me using the devices, and it's not a big deal to do a click or two if that's all it takes to get from one EZ screen to another, but the benefits of keeping it modular seem huge. After all, if I reuse one section in a dozen devices, all I have to do is load the updated submodule in each rather than recreating the steps a dozen times.
It does bring up some questions, though:
1) Are there significant cpu or ram penalties for this sort of nesting? Does it add latency vs if they were in a single (unnested) instance?
2) I guess getting from parent ez screen to any child ez screen is just one click of edit button, then one click on whichever module I want to see so long as it's saved with ez screen active, right? Is there any other trick to streamlining the process of working modularly WITHOUT rewiring from child to parent?
It does bring up some questions, though:
1) Are there significant cpu or ram penalties for this sort of nesting? Does it add latency vs if they were in a single (unnested) instance?
2) I guess getting from parent ez screen to any child ez screen is just one click of edit button, then one click on whichever module I want to see so long as it's saved with ez screen active, right? Is there any other trick to streamlining the process of working modularly WITHOUT rewiring from child to parent?
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
It seems to me that the benefits of working modularly far outweigh the drawbacks of having multiple nested ez screens, but... I'm wondering if the solution is actually simpler than it might seem to implement:
Correct me if I'm wrong, but if there was a simple option in MXXX to pass child ez screen manager data to the parent ez screen manager, then the sections would all still be modular, the modules could still be saved and updated individually, and styling could simply be over-ridden for the parent ez screen.
Maybe it's more complex than that, but it doesn't seem to be from what I can see. That would seem to be the optimal solution that doesn't break anything, is relatively straight-forward to program, and saves users lots of time.
Until then...
I've resigned to not using the parent ez screen at all, but rather lining up mxxx submodules within the parent where each brings up it's own ez screen when clicked on. That way, again, I can do things like update a module once, then quickly update it in every device that uses that submodule without rewiring anything. Since everything is present on the parent edit screen, each ez screen is just one click away (Unless I've nested them further for some reason, but that doesn't generally seem necessary.
So, in other words, if I have an 808 creator MXXX module, a limit/clip MXXX module, and an EQ/Filter MXXX module, and want to combine them into a single device (or just saved MXXX preset) it seems to me the best workflow at the moment is just to create each as a separate MXXX instance with it's own ez screen, then drop them into a parent that never gets it's EZ screen wired, but rather is saved with the edit screen open such that each of the submodules is visible, and when clicked on, their ez screens pop up. Does that sound optimized? Anything else I should consider?
Correct me if I'm wrong, but if there was a simple option in MXXX to pass child ez screen manager data to the parent ez screen manager, then the sections would all still be modular, the modules could still be saved and updated individually, and styling could simply be over-ridden for the parent ez screen.
Maybe it's more complex than that, but it doesn't seem to be from what I can see. That would seem to be the optimal solution that doesn't break anything, is relatively straight-forward to program, and saves users lots of time.
Until then...
I've resigned to not using the parent ez screen at all, but rather lining up mxxx submodules within the parent where each brings up it's own ez screen when clicked on. That way, again, I can do things like update a module once, then quickly update it in every device that uses that submodule without rewiring anything. Since everything is present on the parent edit screen, each ez screen is just one click away (Unless I've nested them further for some reason, but that doesn't generally seem necessary.
So, in other words, if I have an 808 creator MXXX module, a limit/clip MXXX module, and an EQ/Filter MXXX module, and want to combine them into a single device (or just saved MXXX preset) it seems to me the best workflow at the moment is just to create each as a separate MXXX instance with it's own ez screen, then drop them into a parent that never gets it's EZ screen wired, but rather is saved with the edit screen open such that each of the submodules is visible, and when clicked on, their ez screens pop up. Does that sound optimized? Anything else I should consider?
-
- KVRian
- 754 posts since 27 Nov, 2011
That makes sense to me. I think the problem with having a parent easy screen is that as you add / remove / update modules, you’d potentially need to rework the parent edit screen. Sure if M could do that it would be great, but it’s not happening today. So just having a fairly standard set of modules that you’re familiar with and can click in to, that sounds great.
