I think a 'document adder' could save allot of time and increase AudioMulch's creative flow, by allowing users to add entire projects to their existing project. This way: if you have a combinations of contraptions that you want to use in the future compositions, you could save them as a projects to be added in real time during future composition or performance.
A document adder function could be thought of as an advanced function, as it would require the user to understand how to manage their cpu load and anticipate possible glitches in the audio caused by the loading of audio files. However: if used properly it could potentially allow Mulchers improvise more efficiently by adding macro elements that have been created in advance.
Importing controller setting with the document might be a helpful optional, as would an option to automatically connect an added document to the output contraption.
If Mulch kept track of what had been added from where: a parallel 'Delete Added Document' function could remove specific added documents. This would allow users to begin their set with nothing but an add/delete document window open and proceed to take their audience through a vast array of pre-composed elements and complex sound shaping components.
A work around might be to allow copying and pasting between simultaneously open AudioMulch documents. This way: one document could be used as a pallet, while the other could function as the performance environment.
Joseph
Hi Joseph
I agree this kind of thing would be good.
What I'm thinking is that it would be possible to drag patch fragments back into an area of the new contraptions palette where they could be given unique names (and probably stored somewhere as separate documents). Then you can just drag new fragments out of the list in the same way as you currently create new contraptions.
Some kind of grouping feature (select some contraptions and group them together) would allow you to delete them all at once.
>>>
A work around might be to allow copying and pasting between simultaneously open AudioMulch documents. This way: one document could be used as a pallet, while the other could function as the performance environment.
<<<
If you launch two copies of AudioMulch you can already do this.
Ross.
Thanks for your response Ross. I see now that the copied contraptions were just out of view.
I find your solution to be very elegant.
A few design ideas occur to me:
1) It would be really nice to have the standard 20 presets on these contraption groups.
2) The replace command would be helpful to switch between groups without messing with patch cords.
3) It would be great to be able to drop aux ins and outs into the pallet so that the grouped device could have an assignable number of inputs and outputs.
4) It would be really nice if each grouped device could have its own Metasurface, so that the amount of midi mapping could be reduced and more intricate control could be obtained.
5) Lastly if there were multiple Metasurfaces from these devices, it would be amazing to have a full screen Metaspace mode, that allowed a third controller to move between the various layers of surfaces. This way three midi controllers could handle the bulk of AMs midi with little need for mapping. If a contraption group is in the project, it's Metasurface would show up as a layer in Metaspace mode.
My latter thoughts may be more suited to a longer time table, but I thought I'd share them none the less.
Cheers,
Joseph
Some of this has been discussed before, here:
http://www.audiomulch.com/content/contraption-groups-macros
The way I see it, there are two possible ways to go with the "groups" idea.
A. A "group" - much like what you get in a graphics program like illustrator. Once contraptions are grouped they can be moved around the patcher together. Added/deleted together. Perhaps all contraptions in the group can be assigned a color. Probably they can be "collapsed" into a smaller sized block in the patcher and zoomed in/out. Contraptions can also be easily ungrouped or regrouped with other contraptions. Conceptually this is a relatively simple mostly patcher-only concept.
B. An "embedded sub-patch" - this is the idea of creating a kind of aggregate contraption made out of other contraptions. It would appear in the patcher just like any other contraption but you could open it up to see what was inside it. You could create a custom control panel for it. It would have presets etc. It would be a kind of "user built contraption". Personally I think this concept is more useful in environments which provide low level building blocks like max/msp or bidule than in AudioMulch.
(A) is simpler to understand and implement than (B). My current feeling is that (A) may be more appropriate since I don't really want to take things too far towards the visual-programming max/msp / bidule direction. I'm not sure there is really a point to aiming for something in between. In theory both concepts could be implemented as separate features.
I think your point (3) above would require approach (B).
The issues you raise regarding presets and the metasurface are also being discussed in other threads and I agree that it would be nice if it all came together -- except that sometimes you want different control options to cross-cut abstractions. For example, the fact that Metasurface snapshots can be separate from contraptions Presets or individual MIDI and Automation parameter control can be useful. If there were multiple metasurfi you might want to assign individual parameters to different surfaces, not just on a per-contraption or per-group basis.
In the end, the final solution will need to bring all of these disparate pieces together into some kind of unified whole.
Ross.
Thanks for this detailed response. I’ve never communicated directly with a developer about things I’d like to see, so it’s a real honor to be heard about this stuff. Ultimately it seems like you know what needs to happen. The above are not feature requests, but rather ideas that occur to me as I develop my Audiomulch live set.
In the performance of electronic music we are handling a lot of information, sometimes too much so to the point where we either end up reducing our level of musical quality or risk forgetting or mishandling some crucial element. I think your approach “A” will do a great deal towards lightening the load on our human memory banks.
Point 3) is an attempt on my part to suggest a way to keep a midi mapped mixer consistent throughout ones set as various groups are replaced or changed. So in theory the group could contain SGains that would be set at appropriate levels for its interior contents. With multiple outs those SGains could go to a main mixer outside the group that would be consistent throughout the set. This mixer would be for finessing the mix as opposed to presetting the ‘ballpark’ levels for a particular portion of the set contained within a group. This is an attempt to express the ‘why’ of point 3, not to argue for its inclusion, as even since my first posting here, I am comprehending new and better ways to accomplish my goals within Audiomulch exactly as it is.
I think your statement articulates the essence of my suggestions nicely: “In the end, the final solution will need to bring all of these disparate pieces together into some kind of unified whole.” An ambitious statement, especially within the context of what we are discussing here: the consistency of midi maps, the transitioning of macro elements, the Metasurface, and of course Audiomulch itself.
Joseph