Completed: 2016.08.09
Duration: 2:44
Ensemble: Electronic (blue, Csound)

MP3: Click Here
OGG: Click Here
FLAC: Click Here
Project Files – Click here (.blue, .csd)

“Transit” was inspired by listening to the music of Terry Riley to create a work that involved long feedback delay lines. I began with a mental image of performers in a space working with electronics and worked to develop a virtual system to mimic what I had in mind. Once the setup was developed, I experimented with improvising material live and notating what felt right. I then continued this cycle of improvisation and notation to extend and develop the work.

Pink 0.3.0

Hi All,

I’d like to announce the release of Pink 0.3.0:
[kunstmusik/pink “0.3.0”]

Pink is an audio engine library for making music systems and compositions.

The ChangeLog is available at:

This release introduces Pink processes. It reuses the state machine
macro system from core.async to allow writing event generation code
using loops and waits.  The state machine execution is wrapped in a
Pink control function and run synchronously with the engine.  Waits
may wait upon a given time value in seconds, a Pink Signal (i.e. cues
or latches), or upon a predicate function.  The use of signals and
predicates provides a means for interprocess communication, enabling
things like Lutoslawski-style aleatory (i.e., ad libitum writing)
where performers and conductors signal one other.  Further information
is available in the documentation for processes [1] and example code
is shown in [2]. (For those unfamiliar with Lutoslawski’s writing, the
performance instructions given at the bottom of pages 1 and 2 of his
3rd Symphony [3] may shed some light.)

This release also provides a translation of Scott Van Duyne’s piano
model from Common Lisp Music, biquad-based filters, and a number of
other audio, control, and utility functions.

Many thanks to Timothy Baldridge and other core.async contributors for
making the core.async ioc_macros easily extensible and reusable, and
again to Tim for the wonderfully clear videos on YouTube explaining
the design of the macros.


[1] –
[2] –
[3] –

Reflections after a Thesis Submission

After a very long and tiring week, I managed to finish (with great support from my advisor, Victor, and my wife, Lisa) and submit my thesis for the PhD this past Friday. I flew back home on Saturday and have been focusing on getting myself organized and resting.  I am waiting now for the Viva Voce (thesis defense), which should be in November or December, depending upon the availability of the examiners. If that all goes well, I’ll have to do revisions to the thesis, then can submit the final hardcopy and will be done.

I haven’t had much time to write on this site for a very long while.  I’m happy to have a free moment now to sit and breathe and reflect. I think more than anything, after spending a long time developing and creating music systems, I have been extremely happy the past few days to spend time using those programs for composing.  I imagine it will take some time to integrate music making back into my daily life, to make it a real practice, but so far it is going well and I am excited to just to continue on and see where it all goes.

I have a number of projects for the short term, and should be busy through the rest of the year.  The weight of writing the thesis is now absent, and all the rest of the work seems much more manageable now.  If all goes well with the Viva, I will certainly enjoy this coming December, and I am looking forward to it already.


Pink 0.2.0, Score 0.3.0

Hi All,

I’d like to announce the release of Pink 0.2.0 and Score 0.3.0:

[kunstmusik/pink “0.2.0”]
[kunstmusik/score “0.3.0”]

Pink is an audio engine library, and Score is a library for
higher-level music representations (e.g. notes, phrases, parts,

ChangeLogs are available at:

The quick version is Pink now has some new effects (ringmod, freeverb, chorus) as well as some new filters and delay-based audio functions.  Score has a new sieves namespace for Xenakis-style sieves. (An example of sieves and freeverb is available in the music-examples project [1]).

For any questions, please feel free to email me or post on the pink-users list.  For issues and PR’s, please use the facilities on Github for each of the projects.

[1] –

Pink 0.1.0, Score 0.2.0

Hi All,

I’d like to announce the release of Pink 0.1.0 and Score 0.2.0:

[kunstmusik/pink “0.1.0”]
[kunstmusik/score “0.2.0”]

Pink is an audio engine library, and Score is a library for higher-level music representations (e.g. notes, phrases, parts, scores).

For more information, please see the projects’ docs at:

and examples of using both at:

To note, this is the first stable version of Pink.  I got into a bit of “let me add just one more feature…” but decided it was time enough to issue a release. Score’s changes since 0.1.0 are primarily a better organization of files, as well as organizing music into measured and/or timed scores.  See [1] for an example of measured score use.

Next steps planned for Pink are some more unit generators (i.e. comb filter, convolution) and effects (i.e. reverbs). Next steps planned for Score are currently just adding Xenakis-style sieves.  I’ve also been using plotting code enabled as a separate Leiningen profile in Pink, which I am planning to move to an additional library (tentatively called pink-viz).  The plans for pink-viz are to collect useful functions for helping to write unit generators (i.e. oscilloscope, bode plot, FFT spectrogram).


[1] –

Csound: adsr140

I’ve put together a UDO called adsr140 that is based on the Doepfer A-140 envelope generator[1].  It uses code by Nigel Redmon for its ADSR[2], but has been ported to Csound ORC code as well has the added ability to take in a retrigger signal.

To note: adsr140 uses positive values from signals for gate and retrigger as a gate on.  (The examples use the lfo opcode with default sine as a gate and retrigger signal.)

The first example sounds use instr 1 which only uses the gate signal to trigger the adsr.  The second example that comes in at 18 seconds uses instr 2 which uses both gate and retrigger.

Also to note, the code for adsr140 is using a-rate signals for gate and retrigger.  It also requires Csound 6.04 as it uses a while-loop.


[1] –
[2] –

p.s. – Life’s been busy lately, but I plan to add this to Pink as soon as I have a chance.

Developing Music Systems on the JVM with Pink and Score

My talk at Clojure/Conj 2014, entitled “Developing Music Systems on the JVM with Pink and Score” is now available online at:

I was a bit dismayed afterwards that I had mismanaged my time on stage and that my final example did not run (ended up being a small bug that was introduced while practicing the presentation earlier that day; now fixed in the code repository). However, I think overall I was able to cover enough of the systems. I also got some good feedback from people, both as compliments as well as great notes and questions that I look forward to incorporating back into the work.

I’m happy now to be back home and look forward to collecting my thoughts and figuring out next steps for everything. I am extremely grateful to have had the opportunity to present my work at the conference; many thanks to Cognitect for the opportunity and their incredible support.  I’m also blown away by the other speakers at the conference, as well as all the people I met there.  It’s a wonderful community, one which I hope continues to grow and keeps on being as positive a group as it is today.




Extending Aura with Csound Opcodes

Last week at the International Computer Music Conference 2014/Sound and Music Computing 2014 joint conference in Athens, Greece, I gave a paper entitled “Extending Aura with Csound Opcodes”.  The paper discusses work to allow using Csound opcodes by themselves, outside of the normal Csound engine, within Roger Dannenberg’s Aura interactive music framework. I’ve placed a copy of the paper here:

Download Paper (PDF)

The paper may be of interest to those involved with music systems design, particularly focusing on unit generators, and those wanting to know more about Csound’s internals. In the presentation, I focused on looking at all of the other things involved with Unit Generators besides just the processing algorithm, and gave a demonstration using an Aura-based application, using the Serpent programming language to create a short generative example using temporal recursion and dynamic allocation of Csound and Aura unit generators working together.

While the conference was exhausting, and certainly had technical issues due to the scope of what was scheduled, I had a great time at the conference. I saw many old friends and made a few new ones. 🙂 I’ll certainly be attending next year’s SMC 2015 in Maynooth, and hope to attend the ICMC 2015 in Denton, Texas too!

Announcing Pink and Score: libraries for music systems design and composition, written in Clojure

Hi All,

I’d like to announce two Clojure libraries for music systems design and composition called Pink[1] and Score[2].

Pink is a library for music system design. It currently contains code for an audio engine, events processing, and signal processing. It is heavily influenced by Music-N systems (i.e. Csound, SuperCollider), but explores some novel areas of music system design, such as using audio-rate functions as arguments to instruments.  This allows such things as reusing an instrument whether it has a fixed pitch, a glissandi, randomized frequencies, etc., depending on what the user decides to pass in as an argument (rather than encoding that within the instrument design).  Events are also generalized as delayed function applications, which allows a great flexibility for the user to decide what will happen when an event is processed.

Score is a higher-level library for music score generation.  This library contains two primary score generation models–one based on CMask[3], the other on SuperCollider’s Patterns[4]–each of which solves various score generation use cases. Score also contains some useful functions for converting units to frequencies and working with non-standard scales that have scale degrees different than the western standard of 12 tone equal temperament. The library is designed to stand alone and work with various other systems.  I currently use it in my integrated music environment Blue[5] to generate Csound scores, as well as starting to use it with Pink.

I’ve also added a music-examples[6] project that I’m using to explore use of Pink and Score together.  There is also an example there using Incanter to plot the audio signals generated from a French Horn model as well as the output of an envelope generator. (This was useful for debugging some instrument code that went awry. 🙂 )

Some notes:

* In the Clojure world, most people working on music probably use Overtone. I think Overtone is an excellent project and will probably handle many people’s use cases. However, I am interested in use cases which are–as far as I understand–not possible with Overtone, particularly crossing the event boundary with audio-rate functions as arguments.  (I believe that’s a limitation of SuperCollider rather than Overtone though; if that situation has changed since last I looked into it, then please let me know.)  I am also very much interested in encapsulating projects as fully as possible, for the purpose of having higher preservation of musical works.  This made me curious to explore a pure-JVM solution.

* Most of the experimentation so far has been done using the REPL and Vim.  You can check out the code in the demo folders in Pink/src and Score/src for some hints.  I hope to get around to documentation and tutorials soon.

* I have not yet fully benchmarked Pink, though it has so far been adequate for the various test musical ideas I have run.  I don’t expect it to run as quickly as C/C++ based systems such as Csound and SuperCollider, though I do expect to push things as fast as it can go on the JVM.  To that end, if you look at the code of Pink, you’ll find lots of typehints, as well as a design that reuses arrays between function calls. These are done to perform as quickly as possible as well as minimize memory usage. I’ll be continuing to explore optimizations; any suggestions would be very welcome!

* For those who might know me from my work on Csound, I am very much planning to continue my work there.  Working on Pink has helped to experiment with engine design ideas that would be more difficult to do with Csound’s code. I hope to bring back some of the architecture and design ideas back to Csound when I have a chance.

* These projects are not yet mature, but I felt they have reached a point where I could invite others to take a look.  At this point, I have some short-term plans (i.e. working with audio samples, engine code for writing to disk), but the longer-term is still a bit nebulous.  As it is, the libraries are not in a shape to submit to clojars. If you are interested to experiment with them, you can do so by checking them out with Git and running ‘lein install’, then adding dependencies (see the music-examples project.clj for an example).


[1] –
[2] –
[3] –
[4] –
[5] –
[6] –

Netbeans RCP: LazyPlugin and LazyPluginFactory

In working with the  Netbeans Rich Client Platform in building Blue, I have created a number of plugin types for the program.  Following a standard Netbeans convention, I have implemented plugin registration by having plugins register themselves with the System Filesystem. This is done either through XML (layer.xml) or through annotations I have created for each plugin type.

This works very well, but over time, I found two things I wanted to address:

  1. I was using a lot of boilerplate code for loading plugins and wanted to encapsulate that into an API to simplify things.
  2. I needed a way to lazily load the plugins, such that each are only instantiated only when they are requested for use.

To those ends, I wanted to share a couple of classes I have recently worked on: LazyPlugin and LazyPluginFactory. The code for these two are as follows:


package blue.ui.nbutilities.lazyplugin;

import java.util.HashMap;
import java.util.Map;
import org.openide.filesystems.FileObject;
import org.openide.filesystems.FileUtil;

 * Lazy Plugin class that wraps a NB FileObject.  
 * @author stevenyi
public class LazyPlugin<T extends Object> {
    private final String displayName;
    private final String path;
    private final Class clazz;
    private final Map<String, Object> metaData;

    public LazyPlugin(FileObject fObj, Class c) {
        this.displayName = (String) fObj.getAttribute("displayName");
        this.path = fObj.getPath();
        this.clazz = c;
        metaData = new HashMap<>();

    public String getDisplayName() {
        return displayName;
    public T getInstance() {
        return (T) FileUtil.getConfigObject(path, clazz);
    public Object getMetaData(String key) {
        return metaData.get(key);

    public void setMetaData(String key, Object value) {
        metaData.put(key, value);


package blue.ui.nbutilities.lazyplugin;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import org.openide.filesystems.FileObject;
import org.openide.filesystems.FileUtil;

 * @author stevenyi
public class LazyPluginFactory {

    private LazyPluginFactory() {

    public static <T> List<LazyPlugin<T>> loadPlugins(String folder, Class z) {
        return loadPlugins(folder, z, null, null);

    public static <T> List<LazyPlugin<T>> loadPlugins(String folder, Class z, MetaDataProcessor processor) {
        return loadPlugins(folder, z, processor, null);

    public static <T> List<LazyPlugin<T>> loadPlugins(String folder, Class z, Filter filter) {
        return loadPlugins(folder, z, null, filter);
    public static <T> List<LazyPlugin<T>> loadPlugins(String folder, Class pluginClass,
            MetaDataProcessor processor, Filter f) {
        List<LazyPlugin<T>> plugins = new ArrayList<>();

        FileObject files[] = FileUtil.getConfigFile(

        List<FileObject> orderedFiles = FileUtil.getOrder(
                    Arrays.asList(files), true);

        for (FileObject fObj : orderedFiles) {

            if(fObj.isFolder()) {

            if(f != null && !f.accept(fObj)) {
            LazyPlugin<T> plugin = new LazyPlugin<>(fObj, pluginClass);

            if (processor != null) {
                processor.process(fObj, plugin);


        return plugins;

    public static interface Filter {
        public boolean accept(FileObject fObj);
    public static interface MetaDataProcessor {
        public void process(FileObject fObj, LazyPlugin plugin);

LazyPlugin encapsulates the plugin and defers loading until the plugin user calls getInstance().  This allows the plugin’s displayName to be used for displaying to the end-user (i.e. “Add GenericScore” for a GenericScore plugin).  There is also a metadata map that is useful for storing additional properties.  To note, the class does not itself hold on to any references of the FileObject.

The LazyPluginFactory is used by giving a folder name to load plugins from, as well as the type of plugin to load.  This then returns a List<LazyPlugin<T>> of the plugins found.  The loadPlugins() method does allow taking in a Filter as well as MetaDataProcessor.  The Filter class can be used to inspect a FileObject and skip over it or not.  (I have a pre-made AttributeFilter class that checks if a given attribute name is set to true. I also have a pre-made ClassAssociationProcessor that reads an attribute string assumed to be a fully qualified class name, loads the class, and adds to the LazyPlugin’s metadata as “association”.)

Having LazyPlugin as a class has–in my opinion–made my code a little clearer.  It’s easy for me to see the code and say “Oh, I’m dealing with plugins here, and I’m lazily loading them.”  The classes are also generic enough that I can handle two scenarios that appear in my program:

  1. I need to lazily load plugins that are model classes.
  2. I need to lazily load plugins at are view/controller classes and need to have an association with the model class. (i.e. this is an editor for class X)

Using generated XML, the following are two fragments, one for a model class, the other for a view/controller class:


            <file name="blue-orchestra-BlueSynthBuilder.instance">
                <attr intvalue="50" name="position"/>
                <attr name="displayName" stringvalue="BlueSynthBuilder"/>


<file name="blue-ui-core-orchestra-editor-BlueSynthBuilderEditor.instance">
                <attr name="instrumentType" stringvalue="blue.orchestra.BlueSynthBuilder"/>

When loaded within the program, I would get a LazyPlugin<Instrument> and a LazyPlugin<InstrumentEditor>.  The former would get used when adding an instance of an Instrument to the project’s main model class. The latter is used when the Instrument is selected. Note the metadata for the LazyPlugin has an association class loaded via a ClassAssociationProcessor that reads in classes using “instrumentType”. It has enough information then to setup the application’s cache of editors for instruments without having to load the actual editor until requested.

So far I have been happy with this design and it has served all of the use cases I currently have.  I imagine these classes may get further refined in the future as other uses cases come up.  I hope others may find these classes useful in the Netbeans RCP programs.