@Jet you can see Audiomulch promotes vertical signal flow (inputs up outputs down) as opposed to Reaktor’s horizontal (left-right). A clever thing in AM is that the modules are on a macro level - you don’t need to mess about with their innards. In that sense it’s not a pure visual patching environment. Having a library at the right macro level is hard.
In Reaktor you’d find 3 (and lately 4) types/levels of objects - 1 the core objects (primitives e.g. a + block), 2 macros that don’t make whole usable instruments, 3 ensembles = instruments and effects, sometimes skinned in their own custom UI (4). And then presets. Automation is left to your DAW’s timeline. The overall UI is different but the same functionality is achievable (though not as integrated as in AudioMulch). There is however a giant user-contributed library.
In Max/MSP (and Bidule), in addition to the spartan interface, building blocks’ parameters are specified directly inside the blocks themselves (e.g. range 0.1 to 300).
At the opposite end of the spectrum, e.g. Buzz (and SunVox on iOS) exposes high level instruments, and UI much like AudioMulch but with tracker sequencing.
Audulus 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.
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.
I think an overall problem with patching environments is that they are essentially programming environments, e.g. at that point design dept starts asking why not code, and questioning having a large enough audience to justify developing such a specific product.
