At the moment the new instr.design is just capable of basic modulation with no in depth synthesis methods …really sad
I think this is symptomatic of what goes wrong in a thread like this.
Synthesis? Yes, that is definitely interesting and relevant to R3, but only slightly related to the actual topic at hand.
I think Bit Arts have clearly demonstrated that he wanted to keep the discussion focused on one particular area, namely the potential redundancy of the modulation system.
Speaking of which: I personally do not think we have yet reached the best possible implementation. I voiced some criticism of Bit Art’s latest concept, because - once I understood it - I felt that the restriction to single modulation sets seemed unnecessary - I want to see aliased devices as a way to link the device and it’s parameters only, and not include the actual computed values flowing through the device (so basically, prioritizing flexibility and ease of use over a potential for CPU optimizations).
Unfortunately, during these past 8 pages or so, it seems that my approach has angered Bit Arts a lot. But one thing is sure: being called all manner of names doesn’t improve things.
Btw: here are some discussions related to other aspects of the modulation system
Better editing workflow for the modulation matrix - “Pattern matrix” alike drag and drop, alt+drag functionality
- http://forum.renoise…950#entry306950
- http://forum.renoise…post__p__306967
- http://forum.renoise…y-device-chain/
- http://forum.renoise…single-sub-set/
- http://forum.renoise…oard-behaviour/
Global/shared instrument modulation, enhanced ADHSRs (with custom curves)
Routing of modulation devices (modulation meta-devices)
Grouped modulation processing (a.k.a. bracket devices, also mentioned in this thread)
Free-running LFO devices
Routing modulation to FX devices