Csound Opcodes

[Mariela Coxon]

Theopcode and endop statements allow defining a new opcode that can be used the same way as any of the built-in Csound opcodes. These opcode blocks are very similar to instruments (and are, in fact, implemented as special instruments), but cannot be called as a normal instrument e.g. with the i statements.

A user-defined opcode block must precede the instrument (or other opcode) from which it is used. But it is possible to call the opcode from itself. This allows recursion of any depth that is limited only by available memory.

Similarly to instruments, the variables and labels of a user-defined opcode block are local and cannot be accessed from the caller instrument (and the opcode cannot access variables of the caller, either).

Modifying the note duration in the opcode definition by assigning to p3, or using ihold, turnoff, xtratim, linsegr, or similar opcodes will also affect the caller instrument. Changes to MIDI controllers (for example with ctrlinit) will also apply to the instrument from which the opcode was called.

These opcodes actually run only at i-time. Performance time copying is done by the user opcode call. This means that skipping xin or xout with kgoto has no effect, while skipping with igoto affects both init and performance time operation.

name -- name of the opcode. It may consist of any combination of letters, digits, and underscore but should not begin with a digit. If an opcode with the specified name already exists, it is redefined (a warning is printed in such cases). Some reserved words (like instr and endin) cannot be redefined.

intypes -- list of input types, any combination of the characters: a, f, k, O, P, V, K, i, o, p, and j. A single 0 character can be used if there are no input arguments. Double quotes and delimiter characters (e.g. comma) are not needed.

The input parameters can be read with xin, and the output is written by xout opcode. Only one instance of these units should be used, as xout overwrites and does not accumulate the output. The number and type of arguments for xin and xout must be the same as in the declaration of the user-defined opcode block (see tables above).

The opcode call is always executed both at initialization and performance time, even if there are no a- or k-rate arguments. If there are many user opcode calls that are known to have no effect at performance time in an instrument, then it may save some CPU time to jump over groups of such opcodes with kgoto.

If i.e. we want to make some simple c/c++ application where we would like to filter or generate something, is it possible to benefit from well written c-algorithms from csound src code and then use them directly without making a .csd design?

So when using Csound API the basic principle, if I understand it correctly, is something like this; you make your csound design and then you make an object, compile it and then you interact with it using API. But what I mean is, is it possible to use only csound algorithms without creating an csound design?

Also it seems very easy to expand the system with own code, even low level c routines from shared objects, which can augment with the whole big library of opcodes already there. Exactly what I was looking for all the time.

This looks like a real hard gamechanger for my plans. Thank you so much for pointing into this direction. Also it seems very easy to expand the system with own code, even low level c routines from shared objects, which can augment with the whole big library of opcodes already there. Exactly what I was looking for all the time.

Yesterday I installed CSound on my Win10 laptop. Today I went to open a Renoise song and all of my tools failed to load. The error message included references to the CSound install dir. WTF, I thought.

Of course, start date and duration could be defined with the Renoise timing system (with line and note delay). But in Csound, p4, p5, p6 are assignable to anything ; i mean, p4 could be the pitch defined between 0 127, but also the distortion rate between 0 and 1.

I am looking to resurrect development and ideas around integration of Csound in Renoise. Did any of your earlier experiments during 2016 to '17 lead to a drafted tool or a working demo that can be polished to a full fledged tool? My interest would be something like CsoundVST by Michael Gogins (I just sent him an email today), which he had to take down during 2018 due to licensing issues. It is like running Csound inside Renoise as a regular VST where you can load the .csd Csound files inside the VST IDE and then trigger it just like any other instrument or effect. That means all the sequencing can be done via Renoise for the most part and all the Csound specific stuff can be handled directly in the VST IDE. To make this abstraction using a Lua tool would be a good step forward if the VST binary with embedded Csound is not going to be available anymore.

The other feature we would have to build around Renoise is the decision to either use the Lua tool or VST with its own independent IDE or to develop a Renoise tool to utilise the score feature beyond realtime midi playability or sequencing instruments via default Renoise midi I/O.

Lua is not my main language either, but I think its going to be a good learning experience for all of us regardless (I still hate Python and prefer Lua anyday even with my current minimal usage of it). Can we roll in a constructive project plan internally?

According to Michael, he strongly suggests using Cabbage to build a custom VST for all our needs. I think that would be the way to go. Unfortunately, Cabbage is not compiling easily on Arch based arm architecture systems such as Raspberry Pi, which I happen to use a lot. I think we should have both options, a VST and a Lua tool that uses Csound to make it platform agnostic.

So, apparently Michael Gogins is experimenting with a widget feature request that is pretty much in the line of what I was inquiring him with earlier recently. Its not as simple or easy as it looks, the good thing is that he is taking a look first before we go in the rabbit hole ourselves.

Rory, the lead developer of Cabbage however mentions going the more generic route of using an IDE such as VSCode along with autosave (Emacs does all this better, for other platforms too) . Considering both their points, if Raspberry Pi for Renoise is to be included, I think the Lua tool is the best way to go forward with the Csound API, since vst will not work in RPi without some serious plumbing (box64?), whereas both Csound (bash, Emacs, VSCode, Csound API, Lua bindings, REPL etc) and Renoise work perfectly in Raspberry Pi.

How to plumb midi from Renoise to a Lua tool is going to be my first question obviously. Secondly, a shell executive function to instantiate csound with respective arguments for realtime midi is already a provision inside csound (rtmidi). That means for the most part all we need is a custom Lua based editor with csound syntax map or just a regular $EDITOR call to external environment editor in Linux and pass the file name to csound for midi input. All we need to focus is on the midi input plumbing from Renoise to Lua Csound tool.

This is a basic example and might need adjustments based on your specific requirements. Ensure you have the Csound API properly configured, and refer to the Renoise and Csound API documentation for more detailed information.

Note: Writing plugins for digital audio workstations like Renoise requires in-depth knowledge of both the Lua scripting language and the specific APIs provided by the software. Consider consulting the Renoise and Csound documentation, as well as seeking support from their respective communities for more advanced implementations.

This example uses the diskin2 opcode to read an audio file, applies parallel compression using two compressors with different envelopes (aenv1 and aenv2), and then mixes the compressed signals. Adjust the parameters (e.g., compression ratio, attack, release) to suit your preferences.

In this example, we use the keytrk opcode to select different audio samples based on keyzones. Adjust the keyzones (kzone1 and kzone2) and corresponding audio file paths ("sample1.wav" and "sample2.wav") to match your specific requirements.

Replace the file paths with the actual paths to your audio samples, and customize the keyzones and parameters as needed. This example assumes two keyzones, but you can extend the approach for more zones if necessary.

Creating a Cabbage VST plugin with Csound integration and a CSD file input feature involves a combination of Cabbage and Csound code. Below is a basic example that uses an embedded Csound engine and allows loading a CSD file in real-time:

Creating a Lua script for a Renoise tool to display MIDI note data in sequence from the current pattern involves using the Renoise API to access and display the notes. Below is a simple example script to get you started:

Certainly! To send MIDI data to a loaded instrument in Renoise using a Lua tool, you can use the following example script. This script assumes that you want to send a specific MIDI note to the currently selected instrument on the currently selected track:

This script sends a MIDI note to the currently selected instrument and track in the pattern editor. Adjust the note, velocity, and channel parameters in the sendMidiNoteFromTool function based on your requirements.

Sending real-time MIDI input from an external source to a loaded instrument in Renoise involves handling MIDI input events and triggering notes accordingly. Below is a simplified example of a Renoise Lua tool to achieve this:

This script listens for incoming MIDI Note On events and triggers notes in the pattern editor of the currently selected instrument and track. Adjust the MIDI device name and other parameters as needed.

Creating a Renoise Lua tool that executes Csound with parameters (such as a CSD file) and captures real-time MIDI input involves a few steps. Below is a basic example to get you started. Note that this is a simplified example and might need adjustments based on your specific setup.

3a8082e126