Cellular Automata Streams

Download CSD Project Here

Implementation of 1-dimensional (Elementary) Cellular Automata as a
stream using feedback and circular buffer delay line. Stream
generates 1 (Live) and 0 (Dead) values, according to initial state
and rule.

Initial state may be any length array. Different array lengths
affects the rate of mutation, comparable to classical cellular
automata implementations that use a fixed array as value between CA
processing steps.

Rule numbers are implemented using Wolfram-style encoding where
number is interpreted as bits. This allows user to use Wolfram rule
numbers. For example, Rule 30 gives bit value of 00011110.

For this project, the CA stream values are used to turn and off a
held note of a specific frequency and amplitude. Actions occur only
when the stream values has transitioned from 0 to 1 or vice versa. The project runs indefinitely but was capped off at ten minutes here.

Using a feedback+delay-based approach could be interesting to allow for user input. The ca_stream user-defined opcode here could be modified to take in input and use bitwise-or with a generated value before writing it back into the stream. This could allow users to “play” the stream, and could make the Class 1 rules that evolve to 0’s be interesting for generating a limited amount of output in time to the user input. (I am curious to know if this could be useful, and will plan to investigate shortly by implementing an interactive web application.)

Shimmer Reverb

Download Csound CSD Project here

Exploration of Shimmer Reverb effect, inspired by Brian Eno’s feedback reverb with pitch-shifter effect. This example uses the following Csound opcodes:

References

Resonant Impulses 2

Download Csound CSD Project here

Further explorations into resonant impulses.  This version is modified in two primary ways:

  1. Additional band-pass filters used to add resonance to the impulses
  2. Gesture generator parameters further randomized to get larger range of textures to listen to.

The zdf_2pole bandpass filter is once again used here, but using mode=3 (Unity-Gain band pass) is used for the second two filters in the series.

Resonant Impulses

Download Csound CSD project file

A study of class synthesis technique of using an impulse generator with resonant filter.  Implemented using Csound with:

  1. gbuzz opcode for bandlimited impulses
  2. zdf_2pole for band-pass filter with high Q setting; filter center frequency swept with exponential envelope
  3. Additional declicking and exponential envelope use to shape gesture
  4. reverbsc opcode used as always-on reverb effect
  5. Temporal Recursion Player instrument used to randomly initiate gesture playback with various, slightly randomized parameters

Special thanks to Eugenio Giordani and Alessandro Petrolati for discussion of VCS3 implementation in this paper, which inspired me to use gbuzz as the impulse generator for this example.

Live Code – Modular-esque

Live code session using csound-live-code and https://live.csound.com.

Initial code happens for about 2m40s, then sound begins.

For those interested in the code, the session uses:

1. start UDO for working with the different always-on instruments
2. vco2 square wave for enveloping (has a nicer quality to it than
using lfo with type 3, IMO)
3. portk for frequency glide
4. chnset for immediate setting of a channel value as part of performance
5. chnset within an always-on instrument (“Mod”) together with k-rate
randh to show how to approach using continuous values with channels

reface DX style FM Feedback (Saw, Square)

I have long avoided FM (Frequency Modulation) synthesis in my own musical practice as I never felt connected with the results I was able to get myself. However, I recently had the great pleasure to attend a talk about the 50th anniversary of FM synthesis, given by its creator, John Chowning, and I was very inspired to explore FM once again. In so doing, I came across the Yamaha reface DX synthesizer and became fascinated with reproducing its feedback system to morph an operator’s output from a Sine to either Saw or Square waveform.

Now, I do not own a reface DX, so most of my research into it was through looking at manuals and watching video demonstrations on YouTube to try to get an idea of how it might be done. I knew from going through literature on FM and PM (Phase Modulation) that using PM with feedback could get an operator’s signal to move from a Sine to Sawtooth wave, depending upon the amount of feedback. I was quickly able to setup a PM instrument in Csound and test this out and it sounded much like what I had heard for the reface DX.

;; feedback PM - feedback moves towards saw
instr PMFBSaw
ifreq = p4
iamp = p5

kfb = linseg(0, p3 * .5, 0.3, p3 * .5, 0)

aphs = phasor(ifreq)

; init for feedback
acar init 0
acar = tablei(aphs+(acar*kfb), 1, 1, 0, 1)
acar *= linen:a(1, 0.1, p3, 0.1) * iamp

outc(acar, acar)
endin

In the code above, one can see that the acar output from tablei is also used as input into the opcode. The code above runs in a single-sample context (in Csound parlance, with ksmps=1).

Now, the part I could not find anywhere in literature or discussion online was how to use operator feedback to morph from Sine to Square. (This is done by using 0 to -127 range for feedback on the reface DX.) After a couple days of research and exploration, I stumbled upon a calculation that sounded to my ears very much like what I had heard on the reface DX videos.

The code below shows the entire instrument:

;; feedback PM - feedback moves towards square
instr PMFBSquare 
  ifreq = p4 
  iamp = p5

  kfb = linseg(0, p3 * .5, 0.3, p3 * .5, 0)
  
  aphs = phasor(ifreq)

  ; init for feedback
  acar init 0 
  acar = tablei(aphs+(acar*acar*kfb), 1, 1, 0, 1)
  acar *= linen:a(1, 0.1, p3, 0.1) * iamp

  outc(acar, acar)
endin

This instrument is virtually the same as the first instrument with the exception of one additional calculation: the multiplication of the acar feedback by itself. (This is seen in the acar*acar calculation.) Adding this one additional multiplication made the signal move from Sine to Square.

I posted this to the Csound User list and Iain McCurdy gave great feedback that the waveform could be morphed between Saw and Square by interpolating between acar and 1. This made a lot of sense as when one of the acar‘s becomes 1, it reduces back down to the normal feedback addition to produce a Saw sound. After some further emails, I did some experiments to use a cosine-based mapping for the interpolation that resulted in a nice transition.

;; feedback PM - feedback moves from square to saw 
;; Based on Iain McCurdy's comments on Csound User List
instr PMFBSquareSaw 
  ifreq = p4 
  iamp = p5

  kfb = 0.25 
  ;;kfb = linseg(0, p3 * .5, 0.5, p3 * .5, 0)
  kwaveshape = linseg(0, p3 * .5, 1, p3 * .5, 0) ;; range 0-1 for saw->square
  kwaveshape *= kwaveshape ;; adjust curve
  kwaveshape = $M_PI * (kwaveshape + 1) ;; adjust from PI->2PI
  kwaveshape = (cos(kwaveshape) * 0.5) + 0.5  ;; adjust to 0-1
  
  aphs = phasor(ifreq)

  ; init for feedback
  acar init 0 
  acar = tablei(aphs+(ntrpol(acar, a(1), kwaveshape)*acar*kfb), 1, 1, 0, 1)
  acar *= linen:a(1, 0.1, p3, 0.1) * iamp

  outc(acar, acar)
endin

I do not know if these calculations are what are used in the reface DX, but regardless, the sine->square sounded good to my ear and I felt it was usable for the kind of sound work I was interested in doing. For now, I have posted the Csound CSD project file here. The audio example at the top of this post is an MP3 version of the output rendered from this project.

Cheers!
Steven

Hex Beats

Hexadecimal (base 16) has been used in various forms of computer music for a very long time, generally as a condensed way to notate values within a power-of-two range.  For example, rather than write out “15” as a decimal value (base 10), one can use “F”, and rather than write out “255”, one can use “FF”. The notation of hexadecimal numbers, in general, take up less horizontal space on the screen than its base 10 counterpart.

The differences in screen real estate is even more pronounced when comparing the binary value (base 2) to the decimal and hex values.  Let’s compare some values here:

Binary:  1101
Decimal: 14
Hex:     E

Binary:  11001111
Decimal: 207
Hex:     CF

A chart showing the binary, decimal, and hex values for number 0-255 are available here.

Now, one of the interesting challenges in live coding pattern-oriented music for me has been trying to have a very condensed notation for expressing beats (onsets).  One way I’ve seen used is to notate values in a binary form within a string, such as “1000100010101000” which would mean “play notes where there are 1’s, but don’t play notes where there are 0’s”. In this case, on beat 1, 5, 9, 11, and 13.

Binary values in a string, on the one hand, quite clearly notates when an instrument should play. On the other hand, I’ve found it visually takes up quite some space and can be a bit slow to parse mentally.

One thing I’ve found rather useful is to notate onset patterns using hexadecimal strings.  I first explored this in my Clojure systems Pink and Score, but recently translated the function I was using to Csound code.  The Csound code turned out to be quite simple:

opcode hexbeat, i, Si
  Spat, ibeat xin

  ;; 4 bits/beats per hex value
  ipatlen = strlen(Spat) * 4
  ;; get beat within pattern length
  ibeat = ibeat % ipatlen
  ;; figure which hex value to use from string
  ipatidx = int(ibeat / 4)
  ;; figure out which bit from hex to use
  ibitidx = ibeat % 4 
  
  ;; convert individual hex from string to decimal/binary
  ibeatPat = strtol(strcat("0x", strsub(Spat, ipatidx, ipatidx + 1))) 

  ;; bit shift/mask to check onset from hex's bits
  xout (ibeatPat >> (3 - ibitidx)) & 1 

endop

And an example of its use is shown here:

  if(hexbeat("f0d0d0f0", ibeat % 32) == 1) then
    schedule("Synth1", 0, p3, inScale(48, 0) )
  endif

The above is saying: “within the hexadecimal beat string of f0d0d0f0, and given the current beat value between 0 and 32, check if the onset is a 1 and, if so, perform Synth 1”.

The code above may be a little tricky to grok at first glance. I’ve started a Github repository for this code and made an online web app for live coding with Csound and this library. The live web site is available at:

https://kunstmusik.github.io/csound-live-code/

and the source code is available at:

https://github.com/kunstmusik/csound-live-code

In working with the hex beat patterns, I found it took a little practice but the meaning of various hex values started to become intuitive over time.  Hexadecimal works really well, in my opinion, for notating pattern onsets as each hex value maps to 4 bits, which works perfectly for 4 16th-notes.  With this, 4 hex values can be used to notate a single measure of 16 16th-notes, 8 hex for 2 measures, and so on.

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.

Enjoy!
steven

[1] – http://www.doepfer.de/a100_man/A140_man.pdf
[2] – http://www.earlevel.com/main/2013/06/02/envelope-generators-adsr-part-2/

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

Announce: New Score Library in Clojure

Hi All,

I’d like to announce a score generation library written in Clojure called “score”:

https://github.com/kunstmusik/score

This library is currently a work in progress. I am planning to put all general composition functions that I use or plan to explore within this library.

Some notes:

The library currently offers two styles of score generation. One is styled after SuperCollider’s Patterns. Patterns in SC generate values without context, and map directly to standard Clojure sequences. gen-notes and gen-score in src/score/core.clj are functions for use with the score generation style. With this it is simple enough to emulate any feature in SC Patterns using standard Clojure sequence-related functions.

The other score generation style is CMask-based. In CMask, rather than have sequences, generator functions are used that function within a context of time. (The start time of the current event being generated is passed-in as an argument.) That difference of having time as an argument allows to express things like time-varying masks, frequencies, etc. So far, I have completed porting all of the features of CMask and have done light testing.

As for the future of this library, I will be using this in my pieces moving forward, and expect to maintain this library, adding features as required. I would warn that the library is still a little volatile, so functions may move namespaces and users may need to update code between these early versions. I hope to clean up and stabilize the API soon so backwards compatibility can be maintained. (The library is version 0.1.0 at the moment; it will be bumped to 1.0.0 when the API is stable.)

Also to note, the library is purposely designed to be generic. I am targeting Csound score generation at the moment, but the core of the library works to generate simply lists of lists (see core.clj, and note the difference between gen-notes and gen-score, or gen-notes2 and gen-score2). This allows the library to be used beyond Csound. For example, you could always create a formatting function to send the notes as MIDI, OSC, etc. (I have some plans to do some interesting event exploration using score with a Clojure music system I’m working on.)

For examples, I have some demo clj files I used while developing within a REPL (https://github.com/kunstmusik/score/tree/master/src/score/demo).They show a bit of what using the library would look like.

Comments and contributions would be very welcome.

Thanks!
steven

Clojure and Blue/Csound Example

I have started to work on a new composition and wanted to move from using Python to Clojure as the scripting language for my music.  I was experimenting yesterday and was pleased to be able to write a score generation function that was fairly flexible, allowing for easily using hardcoded values as well as any sequence for filling in p-fields of generated Csound Score.

From my work session I came up with some fairly condensed code I was happy with:

(require '[clojure.string :refer  [join]])

(defn pch-add  [bpch interval]
      (let  [scale-degrees 12
                       new-val  (+  (* scale-degrees  (first bpch))
                                                      (second bpch) interval)]
                [(quot new-val scale-degrees)
                          (rem new-val scale-degrees)]))

(defn pch->sco  [[a b]] 
      (format "%d.%02d" a b ))

(defn pch-interval-seq  [pch & intervals] 
    (reduce  (fn  [a b]  (conj a  (pch-add  (last a) b)))  [pch] intervals))

(defn pch-interval-sco  [pch & intervals] 
    (map pch->sco  (apply pch-interval-seq pch intervals)))

(defn score-arg  [a]
      (if  (number? a)
                (repeat a)
                a))

(defn gen-score  [& fields]
      (let  [pfields  (map score-arg fields)]
                (join "\n"
                                  (apply map (fn [& args] (join " " args)) (repeat "i") pfields))))

;; EXAMPLE CODE

(def score 
      (gen-score 1 0 1 
                         (pch-interval-sco  [6 0] 12 8 6 2 6)
                         (pch-interval-sco  [6 0] 12 8 6 2 6)
                         (range -10 -100 -1) 0 1))

(print score)

The output from the print statement is:

i1    0.0    1    6.00    6.00    -10    0    1
i1    0.0    1    7.00    7.00    -11    0    1
i1    0.0    1    7.08    7.08    -12    0    1
i1    0.0    1    8.02    8.02    -13    0    1
i1    0.0    1    8.04    8.04    -14    0    1
i1    0.0    1    8.10    8.10    -15    0    1

The key part is the gen-score function.  It can take in either a number or a sequence as arguments.  If a number is given, it will be repeated for each note.  For a sequence, they can be infinite or finite. The only important part of using gen-score is that the at least one of the arguments given is a finite list.

This is fairly similar to SuperCollider’s Pattern system, though it uses standard abstractions found in Clojure. To me, it is a bit simpler to think in sequences to generate events than to think about the Pattern library’s object-oriented abstractions, but that is just my own preference.  Also, the Pattern system in SC is designed for real-time scheduling and also has an option for a delta-time generator.  I think the delta-time aspect could be added fairly easily using an optional keyword-argument to gen-score.

As for making this work in realtime, gen-score would have to be rewritten to not format the strings but instead return the list of p-field values. A priority-queue could then be used to check against the time values of the notes and pause and wait to generate new notes when the scheduling time demands it.

Ultimately, I was very pleased with the short amount of time required to write this code, as well as the succinctness of it.  One thing that has been on my mind is whether to use a CMask/PMask kind of approach to the p-field sequence generators.  In those systems, what would be comparable to the sequence generators–I think they’re just called Fields in those systems–actually take in a time argument.  That gives the generators some context about what to generate next and allows the ability to mask values over time.  I am fairly certain I will need to update or create an alternative to the gen-score function to allow generator functions.  I’ll have to consider whether to use a Clojure protocol, but I may be able to get away with just testing if the argument to gen-score is a function, sequence, or number and act appropriately.  (Something to look at next work session. 🙂 )