When designing a virtual instrument in csound, the easiest approach is to create a single self-contained instr. Within this instr, any number of opcodes can be arranged in a near-infinite number of combinations. Each instance of the instr manages its own local memory space/variables/signals. Users customize the interface of the instr by utilizing p-fields.
With this fundamental model of instrument design, it is already apparent that Csound excels in terms of modularity. However, there are many other approaches that expand this concept even further.
Getting lost within a list of instrument events is sometimes less desirable than being able to place events on a grid or lattice. This is especially true when working with rhythms. I’m a firm believer that the interface influences the compositional process. This is why I’ve begun development on dseq, an instrument that allows me to input drum patterns in a manner that is much more user-friendly.
“It has been too long since the last Csound Blog. This is why I’m personally excited to announce this newest edition, ‘Adding Zak to the Mix.’
Today’s topic is how to model a studio mixer in Csound using Robin Whittle’s zak opcodes. I will actually be stretching this subject over an unspecified number of blog entries, as I couldn’t possibly cover every significant nuance in one write-up. What I’m presenting here today is merely an overview, while in the following issues I will break down everything into its respective modular components. Not only will I cover the design of this zak mixer, I will present new ways in which you can organize your orchestras, along with how to unlock the potential of your patches using control instruments.”