Instrument modulation concept

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

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