at that point design dept starts asking why not code, and questioning having a large enough audience to justify developing such a specific product. I think an overall problem with patching environments is that they are essentially programming environments, e.g. I’d argue there’s sufficient parallel between these and modular, so maybe it’s worth examining VCV Rack (keeping in mind the associated risks : ) with the same caveat that Automation is “outsourced” to other tools. Buzz (and SunVox on iOS) exposes high level instruments, and UI much like AudioMulch but with tracker sequencing.Īudulus is nice but for me has the same “danger of obsolescence” problem as AudioMulch - except if with AM you could roll out an old OS on a newer device, or emulate an AM-compatible environment in a VM, to do the same on iOS is much much harder. range 0.1 to 300).Īt the opposite end of the spectrum, e.g. In Max/MSP (and Bidule), in addition to the spartan interface, building blocks’ parameters are specified directly inside the blocks themselves (e.g. There is however a giant user-contributed library.
The overall UI is different but the same functionality is achievable (though not as integrated as in AudioMulch). Automation is left to your DAW’s timeline. a + block), 2 macros that don’t make whole usable instruments, 3 ensembles = instruments and effects, sometimes skinned in their own custom UI (4). In Reaktor you’d find 3 (and lately 4) types/levels of objects - 1 the core objects (primitives e.g. Having a library at the right macro level is hard.
In that sense it’s not a pure visual patching environment. A clever thing in AM is that the modules are on a macro level - you don’t need to mess about with their innards. You can see Audiomulch promotes vertical signal flow (inputs up outputs down) as opposed to Reaktor’s horizontal (left-right).
0 kommentar(er)
