Check Twinkle ChucK

The concepts of [6]'s first Chapter Basics: Sound, Waves, and ChucK Programming are condensed in 📂 Listing1.20.ck available at github. It defines two patches, i.e. sound signal chains, two float, and one dur variable.

// Twinkle, with two oscillators!
SinOsc s => dac;             // (1) Sine wave oscillator.
TriOsc t => dac;             // (2) Another oscillator (triangle wave).

// our main pitch variable
110.0 => float melody;       // (3) Sets initial pitch.

// gain control for our triangle wave melody
0.3 => float onGain;         // (4) Gains for note on.

// we'll use this for our on and off times
0.3 :: second => dur myDur;  // (5) Notes duration.

Then it initializes both voices – the melody with a gain of onGain, the bass with 0 – and increases the frequency of the melody, i.e., the TriOsc instance t, from 110 to \(220\,\text{Hz}\) in \(1\,\text{Hz}\) steps of \(10\,\text{ms}\) resulting in a duration of

onGain => t.gain;            // (6) Turns on triangle oscillator.
0 => s.gain;                 // (7) Turns off sine osc. 

while (melody < 220.0) {     // (8) Loops until pitch reaches 220.
    melody => t.freq;
    1.0 +=> melody;          // (9) Steps up pitch by 1 Hz. 
    0.01 :: second => now;   // (10) Every 1/100 of a second.
}

In the context of the book's chapter the technical advancement of this code snippet is the realization of a “sweeping pitch upward” by using a while loop. The next loop is a for loop and advances the time 0.6 seconds twice for both voices and switches the melody note on and off.

// turn both on, set up the pitches
0.7 => s.gain;               // (11) Now turn on sin osc too.
110 => s.freq;               // (12) ...and initialize its pitch.

// play two notes, 1st "Twinkle"
for (0 => int i; i < 2; i++) { // (13) Use a for loop to play two notes.
    onGain => t.gain;        // (14) Turn on triangle.
    myDur => now;            // (15) Let note play.
    0 => t.gain;             // (16) Turn off triangle.
    myDur => now;            // (17) Silence to separate notes.
}

This loop is repeated three times. The result of the first for loop: the bass plays a \(110\,\text{Hz}\) sine wave with a volume od 0.7 while the triangle wave puts two 0.3-gain melody stacatto quarters of \(220\,\text{Hz}\) above it. The second for loop is prepared by another set of frequencies for melody and bass

138.6 => s.freq;            // (19) Sets up next "twinkle" frequency.
1.5*melody => t.freq;

From these sets of frequencies I can't guess the note names. I could look them up in tables. chuck offers frequency to midi conversion. To get the pitch from a frequency I'll introduce the R packages seewave, soundgen, tabr, and tuneR in Section 3. In the current section I just finish collecting all frequencies and durations used in the sequence.

The frequencies of the bass line and the next two quarters for the word “little” are set by

146.8 => s.freq;            // (20) Sets up next frequency for "little".
1.6837 * melody => t.freq;

They are again played with the same for loop. Bass and melody for the word “star” is set and played by

138.6 => s.freq;            // (22) Sets up next frequency for "star".
1.5*melody => t.freq;
onGain => t.gain;           // (23) Plays that note...
second => now;              // (24) ...for a second.

The sequence is terminated by decreasing the frequency of the TriOsc instance t from 330 to \(0\,\text{Hz}\) in \(1\,\text{Hz}\) and in parallel the SinOsc instance s from 440 to \(0\,\text{Hz}\) in \(1.333\,\text{Hz}\) steps per \(10\,\text{ms}\), i.e. a duration of

for (330 => int i; i > 0; i--) {  // (25) Uses a for loop to sweep down from 330 Hz.
    i => t.freq;                  
    i*1.333 => s.freq;
    0.01 :: second => now;  // (25) Uses a for loop to sweep down from 330 Hz.
}

Table 1 shows the single steps. I tried to design it to illustrate some kind of symmetry. The playing time adds up to a total of exactly 9.0 seconds.

The R packages I mentioned above offer tools related to sound. I've collected a few items about these packages with a focus on frequency-to-notename conversion. As the first entry I also mention an emacs solution. The first seewave list item presents the Math for equal temperament. For me the last, not least at all, entry tabr is a very recent discovery.

• The calc mode² of the emacs calculator is switched on and off by C-x * c. In this mode the user can enter a frequency value with a unit introduced by the algebraic-mode apostrophe selector as ' 440 Hz [RET], then hit l s (ell .. ess) to get A_4 representing the scientific pitch notation. The usage of the emacs calculator for the frequency estimation is demonstrated in the next list item about seewave in Table 2.

• The R package seewave doesn't provide frequency-to-notename conversion, but the seewave author's book [14] discusses some alternatives³ and the documentation of notefreq() shows the equation for equal temperament, which could be solved for n to get something like a freqnote() function.

  The function notefreq() accepts (1) a note n entered as a number or as a string like Ab, B, or C#, (2) an octave index i, and (3) a ref frequency r. The resulting frequency f is

  \begin{equation*}\begin{split} f(n,i,r) &= r\cdot2^{i-3}2^{\frac{n-10}{12}}; \quad\text{use}\quad x^{\frac{m}{n}} = \sqrt[n]{x^{m}} \\ &= r\cdot2^{i-3}\sqrt[12]{2^{n-10}} = r\frac{2^{i}}{2^{3}}\frac{\sqrt[12]{2^{n}}}{\sqrt[12]{2^{10}}} \approx \frac{2^{i}r\sqrt[12]{2^{n}}}{14.2544} \end{split}\end{equation*}

  Approximated with an accuracy of six significant numbers. Table 2 shows the emacs calculator keystrokes for \(1/(2^{3}\sqrt[12]{2^{10}})\) in the frequency estimation.

  Table 2: The emacs calculator keystrokes in calc mode, switched on and off by C-x * c. The [TAB] key swaps the last two entries; see Section Stack Manipulation Commands in the calc Manual.

  keystrokes	result
  1[RET]12[RET]/	→ 0.0833333333333
  2[RET]10[RET]^	→ 1024
  [TAB]^	→ 1.78179743628
  8[RET]*	→ 14.2543794902
  1[RET][TAB]/	→ 0.0701538780196

  For the default i=3 the function can be reduced to

  \begin{equation*} f = r\cdot2^{\frac{n-10}{12}} = r\frac{\sqrt[12]{2^n}}{\sqrt[12]{2^{10}}} \approx r\sqrt[12]{2^n}\cdot0.561231 \end{equation*}

  For C3 with \(n=1\) that's 261.626 or the F^♯3 from Table 3 the \(n=7\) delivers 369.994. According to the corresponding code the chuck'ers offer 370.414. Cool, I've gathered enough knowledge to enter the nitpicking stage.

  For the note A3 which has a rank of \(n=10\) I can reduce the first term's \(n-10\) to 0 and with \(a^{0}=1\) this reduction is further simplified to \(f=r\), with an r default of 440.

  With the help of these elaborations the dear reader might figure out any frequency with a handheld calculator. Note that the rank number n is neither confined to the range \([1..12]\) nor to integers.⁴ So, for example, it can map to any of the semitone functions below. Potential decimal parts are representing the musical cent unit which is supposed to change the logarithmic distance of two consecutive notes into a hundred equidistant pieces.

• seewave also offers a related octaves() function. It's invoked like octaves(f,b,a) and returns the frequency values of b octaves below and a octaves above a specific frequency f; octaves(220, b=1,a=2) gives the numeric vector 110 220 440 880 – bold emphasis added.
• soundgen .. HzToSemitones() and semitonesToHz() convert a frequency in Hz into a halftone position and vice versa along a full scale of musical notes, that is, a scale starting with a C note at \(16.4\,\text{Hz}\) in the infrasound domain and ending with a B note at \(31608.5\,\text{Hz}\) in the ultrasound domain. With the soundgen dataset notesDict the user can turn a soundgen semitone into a pitch.

• tuneR .. noteFromFF() returns an integer valued semitone difference to A3.⁵ The function noteFromFF() transforms the frequency value x to the integer valued 12th root of a frequency-to-diapason relation including a logarithmic tweaking variable roundshift.

  notesFromFF <- round(12 * log(x / diapason, 2) + roundshift)
  

  For example, the frequency \(493\,\text{Hz}\) yields 2, the B note of the third octave or b'.

  The notenames() function translates this numeric difference to a note name's string like c'. Moreover the function lilyinput() – and a data-preprocessing function quantMerge() – can prepare a data frame to be presented as sheet music by postprocessing with the lilypond. The lilyinput() help includes a maturity caveat. For this purpose the features of tabr seem much more advanced.

• tabr .. freq_pitch() turns a frequency into a pitch. With the parameter octaves the user can choose tick or integer output, the accidentals can be set to flat or sharp, and a4 is offered to be set to something different from the default of 440. A vector input can be collapse'd.

  tabr defines its semitones along the midi numbers. The corresponding freq_semitones() function delivers numbers with expanded range above 127 and below 0.

Table 3 shows a selection of the R functions. The corresponding R code starts from the values in the chuck script 📂 Listing1.20.ck. The rows of Table 3 are

• tuneR – tuneR's notenames() which depends on input from noteFromFF()
• tfpt – tabr's outputs of a sharply ticked freq_pitch()'es, which match the lilypond representation
• tfpi – tabr's the sharp integer version of freq_pitch()
• midi – the tabr freq_semitones() that represent the midi values
• sghs – the soundgen HzToSemitones()
• sndp – the lookup result in soundgen's notesDict

f <- c(110,138.6,146.8,220,1.5*220,1.6837*220,440);
n <- tuneR::noteFromFF(f);
p <- tuneR::notenames(n);
t <- tabr::freq_pitch(f,ac="sharp");
i <- tabr::freq_pitch(f,ac="sharp",o="integer");
s <- round(tabr::freq_semitones(f));
g <- round(soundgen::HzToSemitones(f));
d <- soundgen::notesDict[1+g,1];
rbind(Hz=round(f,1),tuneR=p, tfpt=t, tfpi=i,
                    midi=s, sghs=g, sndp=d)

In formal music the first event of the Twinkle impro, the upward pitch, already leads into trouble. It has to be related to the song it is part of. How long is it compared to a quarter note of the song's rhythm? How do I translate the subsequent sound constructions of the chuck script to beats and bars?

To get a clue I first go to the score of the Twinkle song at musescore.com or musicsheets.org. These pages trigger some other thoughts about the piece of music and the composer's intentions. musicsheets.org identifies the two names W.A. Mozart and C.E. Holmes, an Andante tempo of 100 quarters per minute, and a B^♭ major key for 14 instruments extended by some snare-basedrum percussions. While the musescore.com example is an “easy” version in C major with two voices. The wikipedia entry for Twinkle confirms the C major key.

Usually the key of a song can be derived from the pitch of the last melody note. In the case of Twinkle the melody also begins with this root note. The chuck composers choose the frequency \(220\,\text{Hz}\), i.e., an A_3 in scientific pitch notation. They, however, introduce a “main pitch variable” as melody and assign a value of \(110\,\text{Hz}\) to it. This melody frequency doesn't show up in the melody, only in the decorations of the snippet and in the bass line.

Comparing the chuck sequence illustrated by Table 1 to both scores at musescore.com and musicsheets.org a quarter note is 0.6 seconds and the quarter notes of the melody are played staccato.⁶ For the tempo information near the clef I choose quarters per minute; see Figure 1. If one quarter takes 0.6 seconds one minute contains …

For the melody I use a treble or G clef transposed one octave down, the bass line is fine with a bass clef. The glissandi need some more effort. And the duration of the last Twinkle melody note has to be fit in somehow. In the order of appearance I discuss three topics.

• The \(1.1\,\text{s}\) of the upward glissando, expressed in terms of \(0.6\,\text{s}\) quarter pieces, has a lenght of one quarter plus one quaver plus two 16ths of a 16th triplet. Or a half note minus a 16th triplet note. And it consumes the position of an upbeat. I decide to transfer this glissando to a length of \(1.2\,\text{s}\).
• The last note of the seven-note Twinkle sequence should be a half note and would take \(1.2\,\text{s}\) then, but the chuck'ers decide for a length of one second. In the context of the song's beat I could mix the last note with the subsequent downward glissando. But I decide to expand it to a half note and push the glissando to the next bar.

• The decreasing unit after the short last note raised the question if I should construct the glissandi to be parallel or should I exactly reproduce the downward pitches no matter of their musical context? What about the fact that the upper decrease is played with the bass wave, and the lower one with the melody wave?

  The end sequence with two \(3.3\,\text{s}\) downward glissandi can be matched to five quarters plus one quaver. I expand this duration to one and a half note, so the relation from up to downward pitch is maintained. The whole sequence then takes exactly four bars.

  The downward pitches ar much harder to translate. Each of the final glissandi ends with \(0\,\text{Hz}\); nobody can hear or play that. For an exact replication of both glissandi I'd have to calculate the time when the glissando which controls the loop from \(330\,\text{Hz}\) to \(0\,\text{Hz}\) arrives at, say, C₀, i.e., \(\approx16.35\,\text{Hz}\). And transfer this result to the glissando from \(440\,\text{Hz}\) to \(0\,\text{Hz}\) which probably leads to a slightly later moment, I guess. The time series illustration in Figure 2 only shows the moment for the fundamental frequency of the whole sound, i.e. the louder bass line.

  I decide to call the situation indeterminable and interpret the glitches as glissandi beginning at \(330\,\text{Hz}\) E₄ and \(440\,\text{Hz}\), A₄. I construct them to be parallel and to consume a range of two octaves, which end at E₂ or A₂, respectively. The bass-above-melody issue stays untouched.

The lilypond code below generates the sequence shown in Figure 1. From C3 upwards the lilypond note names match the tuneR output of notenames(), while the lilypond declarations a,|a,,|a,,,|a,,,, translate to A|A,|A,,|A,,, in tuneR. The lilypond script below should be reproducible after studying the sources in the Learning⁷ and the Notation Manual.⁸'⁹'¹⁰'¹¹'¹² Then – after installing lilypond, including it as babel source code language in the 📂 .emacs file,¹³ and getting the lilypond helpers for emacs¹⁴ – with the listing named #+Name: lst1-20muProScore in the org source, available at bitbucket, the interested reader can get an impression of lilypond at work in an org mode source block with the :noweb feature applied.

\parallelMusic melody,base 
    { \tempo 4 = 100
    % bar 1                   % bar 2             
    r2  a,4\glissando a       a4     a      e'  e' |
    r1                        a,2           cis    |
    % bar 3                   % bar 4             
    fis'4  fis'   e'2         e'1\glissando e,2 r2 |
    d             cis         a'1\glissando a,2 r2 |
  }
    \new StaffGroup <<
      \new Staff { \clef "treble_8" \key a \major \melody }
      \new Staff { \clef bass       \key a \major \base }
    >>

To configure a short score snippet without the lilypond default of a surrounding page like shown in Figure 1 I included a preamble with the :noweb switch. The Notations Manual's Spacing Issues Chapter¹⁵ deals with the value of its page-breaking attribute. While the markup settings are part of the Chapter General Input and Output.¹⁶

\version "2.20.0"
\paper{page-breaking = #ly:one-line-breaking 
  indent=0\mm        %  line-width=170\mm
  oddFooterMarkup=##f   oddHeaderMarkup=##f
  bookTitleMarkup=##f   scoreTitleMarkup=##f }

Developing the skills for managing lilypond in emacs may take years but I think I named all the essential parts for this special purpose.

For the graph in this section I use results from Section 7 which analyzes the wav file produced in the next section. Note that this section, Frequency-versus-Time Graph, doesn't reproduce the fine-tuned musical score from the previous section. Instead it gets frequency and time information from the recorded output of the original 📂 Listing1.20.ck employing the tuneR function FF() without further explanation. Section 7 then delivers more insight but still doesn't touch much of the theoretical basics.

The inspiration for this section is to find a programmatic counterpart of ableton's warping feature or its audio-to-midi converter. audacity offers similar ideas in its beat finder, regular interval labels, and label track at manual.audacityteam.org. And methods outlined by Advances in Musical Information Retrieval [10] deliver much more inspiration.

The attribute “frequency versus time” should lead to the undecorated appearance of a piano roll, of illustrating a song like a Gantt Diagram. The common nominator for the illustration of timely events like music is something in the realm of time series. Time series usually concentrate on continuous signals with high data or sampling rates resulting in immense data traffic. Reducing this sea of data to events made the atari notator the tool for the digital evolution of musical ambitions.

In contrast, expanding the realm of digital workstations to real time sound design makes the current software constructions eating up every bit of memory they manage to grab. Freezing the results of this additional work has become a main feature of the software. With this procedures the software could be scaled back to on and off events with dynamic settings and probably run easily on a 8086 processor or an arduino. For chuck the users can compare their expectations of the software in the virtual machine processes, discussed in 3.5 Properties of [15]'s ChucK Chapter and introduced by Section 3.4 System Design and Implementation. I consider wavetable synthesis as a link between freezing and in-situ processing. Its purpose is introduced in Section 2 The Evolution of Sound Synthesis of Peter Manning's contribution [8] to Dean's Oxford Handbook of Computer Music: “The processing overheads involved in repeatedly calculating each waveform sample from first principles are significant, and it occurred to Mathews that significant savings could be produced in this regard by calculating the required waveform only once and then using a suitable table lookup procedure to extract this information as the required frequency.” Manning is referring to Mathew's Technology of Computer Music [9]; no specific passage.

For a start I'll enjoy the graph and discover the data for note-on and note-off events. On the way I hope to get some hints for control parameters in sound design or for note decorations. The graphs melodyplot(), quantplot() and their data are the targets of the event task. The process should motivate digging deeper into Fourier and spectral analysis.

The frequency versus time plot in Figure 2 is made with the help of periodogram() and FF(). With an anticipation of Section 7 about the main tuneR example it delivers 774 frequency values for my wav file. I don't ask why.

All I need the 774 parts for is to construct a proper time series. The plot() function recognizes the time series and connects to plot.ts(). The experienced org mode babbler knows how to transform these lines into a png plot and include it in this document; see the org source of this blog entry at bitbucket.

oldPar <- par(mar=c(2,2,0,0)+0.1);
plot(ts1.20,type="h",col="grey85");
abline(h=c(110,220,440),col="grey50",lty="dashed");

While the time series class delivers an appropriate plot, the usual time series functions seem unappropriate for making an event list, but I'm not an experinced time series analyst. I'll go with exploratory data analysis. Provided with the graphical feedback I can read 6 ranges into the raw data. The limit indices of the ranges indicate time data; each second contains \(774/9=86\) values, that's about \(11.6\,\text{ms}\) per value. The first and the last range can be least square fit to linear slopes, the other four ranges can be feed into boxplots. Then I can change the parameters of periodogram() or FF() systematically to see the effects.

The code below shows the patch line definitions from the chuck script 📂 lst1-20rec.ck which records to 📂 lst1-20rec.wav. It produces a mono track at the left channel.

The analysis below in Section 7 prefers to recognize the bass line. For now there are enough procedures to discover, so I don't offer the procedures to split the melody and the bass line to different channels. It's more interesting to discover the functions' preference for the bass line. Stereo sound is one topic of [6]'s second chapter.

First I have to change the patch lines. The original file 📂 Listing1.20.ck begins with

SinOsc s => dac;             // (1) Sine wave oscillator.
TriOsc t => dac;             // (2) Another oscillator (triangle wave).

For recording I put the SinOsc instance s through the Gain instance named master into the WvOut sound buffer instance named w which then disappears in the blackhole nirwana. Then I can connect the melody line to the master track.

SinOsc s => Gain master => WvOut w => blackhole; // (1) melody chain
TriOsc t => master;                              // (2) bass chain

After that I copy the definitions of the variables melody, onGain, and myDur and the settings of the .gain attributes for melody and bass lines. This is exactly like in 📂 Listing1.20.ck, line 7-21, so I can insert these lines without comments and don't show them here.

The next part prepares for recording. It reads the current path of the record script, names the output file, connects path and file name, assigns the result to the .wavFilename attribute of the WvOut instance w, and finally turns on the .record feature of w.

me.dir() => string path;             // (3) get file path
"/lst1-20rec.wav" => string fileRec; // (4) target file
path+fileRec => fileRec;             // (5) add the path
fileRec => w.wavFilename;  // (6) choose the record file
w.record(1);               // (7) press the record button

After inserting the rest of 📂 Listing1.20.ck, line 22-end, the recording has to be finished and the file to be closed.

w.record(0);   // (8) press the stop button
w.closeFile;   // (9) close the record file 

For invoking chuck in linux it's important to set the sampling rate to \(44100\,\text{Hz}\); on linux the default is \(48\,\text{kHz}\).

cd musRoot/chuck
chuck --srate44100 lst1-20rec.ck

The patch ending in the blackhole still takes as long as the regular output to dac. But there's a tremendous time warp for using the --silent option.

cd iMuMy/Chuck
chuck --srate44100 --silent lst1-20rec.ck

Both execute the task properly but terminate with a warning. I think I recognized this warning generally in the context of using WvOut, but it also maybe with LiSa or generally with sound buffers.

terminate called without an active exception
Aborted (core dumped)

Timing the commands confirms my manual measurement of 11 seconds. And it shows \(0.4\,\text{s}\) for the silent version.

For filing I compress the resulting wave file to flac. After taping I've got three new files to work with. A 3k chuck script, a 794k wav, and a 246k flac file. And I'm all set for the …

I refrained from calling this section “sound analysis” because it just provides a coarse introduction to collected tools without scientific distraction. The collection is a set of functions picked from the main example for tuneR.¹⁷ I've chosen tuneR instead of seewave, because tuneR seems closer to the programmatic background. While seewave offers plenty of parameters to avoid the ... channel to the underlying functions and includes switches for optional plots it also makes it hard to customize very basic settings, because it hides the structure. Meaning that – for the matter of skill building – I prefer tuneR's unix like aproach of many small programs to the highly integrated seewave solutions. After this learning phase I will probably acccept seewave's help. I don't asssume this as a better way, it's just my way; greetings from Frank Sinatra.

On my way to a notation compatible with lilypond I skip some distractions from the tuneR example. I don't

• have to produce a sine wave, because I produced my own wav source with chuck in the previous section.
• pay attention to downsample() or the interactive extractWave().
• dig into spectral density theory and smoothing techniques which usually should be helpful for understanding the tuneR functions periodogram() and FF().

In the subsections I look at tuneR plots and I offer some bridges which are about to help me arriving at sound design. The code below delivers the data for the rest of the main tuneR example, employing the functions readWave(), normalize(), mono(), periodogram(), FF(), noteFromFF().

tmpfile <- "./iMuMy/Chuck/lst1-20rec.wav";
wn1.20 <- tuneR::normalize(tuneR::readWave(tmpfile));
wnm1.20 <- tuneR::mono(wn1.20, "left"); # str(wSpec);
wSpec <- tuneR::periodogram(wnm1.20, normalize=TRUE,
                            width=1024, overlap=512);
ff <- tuneR::FF(wSpec); # print(ff); str(ff)
notes <- tuneR::noteFromFF(ff, 440);

Unfortunately the main example for tuneR is unsufficiently commented. Comments usually come as a tautology like “the function periodogram() produces a periodogram.” Fortunately the author of [14] seems to follow the same track18 without explicitly referencing the main tuneR example but with more detailed explanations. At least he follows the line of applying periodogram(), FF(),19] noteFromFF(), notenames(), melodyplot(), quantize(), and quantplot(). He puts these tuneR functions into a dominant and fundamental frequency context's comparison of seewave's dfreq() and fund() phonTools's pitchtrack() soundgen's analyze().20

With these tools at hand I began to translate the modules of ableton live – the live devices including instruments, audio and midi effects – into one view of sound synthesis. Another view is Peter Manning's Evolution of Sound Synthesis³⁰. His “evolutional” sequence is, for example, wavetable synthesis → additive synthesis → frequency modulation → physical modelling → granular synthesis. And the next section of this Manning reference, 3 Resources for Software-Based Sound Synthesis, discusses plenty of tools for the tasks. The Chapter A History of Music and Programming in the chuck PhD thesis [15] offers similar insight. The thesis itself which promotes chuck as a “strongly-timed” audio programming language with a time-based concurrent programming model³¹ gives rise to the assumption that there's something missing in the text based sound languages nyquist and supercollider.

My experience of the terminal execution of chuck scripts in pulse audio installations of ubuntu and endeavoros is a hick up after about half a second of every listing I played.³² When I record the script and play the resulting wav file with an audio player like vlc there's no problem. This might be an issue of my linux configuration. Or perhaps I missed some warnings in the compilation feedback of chuck. The chuck flag --blocking might help but it's not available in chuck versions ≥ 1.4.x. Any configuration of --bufsize didn't affect the hick up. I didn't check --adaptive and I also didn't try to run the scripts in audicle.

Perhaps I'd get some hints from the entry Getting an ALSA program (ChucK) to work with Pulseaudio? and one of its references Command line multitrack audio looper for Linux?, both at superuser.com. Or from a 2018' phd work which expands on live coding and classifies chuck's processing mode as a

“style of intra-process communication [which] has been adopted by many live-coding environments including chuck, impromptu and fluxus. Being both effcient and flexible, intra-process communication offers an attractive option for integrating live-coding languages with extant low-level audio-visual frameworks – opengl, stk, core-audio, quicktime, directx, alsa, jack, portaudio, and portmidi to name a few.

There is however, a serious disadvantage with the tight coupling of language with framework; the tight coupling of failure!”

— Section 3.1.2 Language and framework coupling of Extempore: The design, implementation and application of a cyber-physical programming language [12], p.47

The quote can be seen as a commercial for the extempore software, or as incentive for new ideas about live coding.

Anyway my hick up experience gives rise to the suspicion that nyquist or supercollider are at least worth trying. Or impromptu, fluxus, extempore? All these software is nothing but a toolbox for working with sound. So I might be better off to discover the gnu linux empire which embraces the unix philosophy of using small and highly advanced programs which are maintainable? For example I could employ mpc, the command-line client of the Music Player Daemon mpd for a DJ scenario. The emacs multimedia system emms supports it. But has emms access to the three crossfading related flags crossfade, mixrampdb, and mixrampdelay? What about employing SoX? Ecasound?

There are lots of programs, services, and devices which may add to an individual tool set. unix command line programs and libraries, their gui representatives, and wrappers in any coding language. Online offers and services. Looks like the users are pushed into responsibilty for their own actions. No wonder most of them decide for the proprietary thread. I voted against integrated audio software like CuBase, Magix, Rosegarden, Garageband, Muse, TuxGuitar, Frescobaldi. But I'm still interested in discovering

• Online platforms – Bandlab, Soundcloud, Funkwhale, musicBrainz (audio fingerprint, recording ids)
• Command line players or synths – ffmpeg/ffplay/ffprobe, ecasound, sox, mpd. Melt? See the Melt article by Bruce Byfield at linux-magazine.com.
• Ip3 tagging – mp3tag → puddletag, exiftool (reading metadata), mutagen (writing id3tag) → exFalso/quodLibet, musicBrainz → picard,
• Composition tools – ProChords, a framework of a usage database instead of music theory for selecting chords.
• Guitar effects – Looking up Guitar Effects Pedals [5]. Get inspiration from Guitar Tone [4] or Electric Guitar Science [7] and then dive into Julius Smith's online books to synthesize a Hendrix sound.³³
• lilypond's extended notation scores for fingering, percussion, fret diagrams – how to note the playing technique, of latin percussion for example, and use it as input for a music program.
• Streaming configured audio results as a mumble or mpd audio session – for example a radio show or a podcast might be considered to be transferred to Worlds for Collaborative Social Audio Programming; see Section 7.2.2 in 7.2 Future Work of [15]'s Conclusion Chapter. Get hints from libmms, a library for downloading (streaming) media files using the mmst and mmsh protocols.
• Electronic circuit simulation for sketching analogue modules discussed in Handmade Electronic Music: The Art of Hardware Hacking [3] – mainly inspired by ngspice, based on spice, the Simulation Program with Integrated Circuit Emphasis. The arch linux user repository, for example, provides bridges to Spice3f5, Ciber1b1, and Xspice. The Science of Electric Guitars and Guitar Electronics [7] uses ngspice and Jimmie Cathey's Schaum textbook [2] provides spice scripts for basic electronics.

That are some pieces of some big picture. But with – the recorded results of – chuck I first try the different forms of compositions from [6] and explore the live sampling expansion LiSa of chuck's sound buffer handling³⁴ to advance my recording skills; perhaps inspiring streaming scenarios.

Even the first step can be a daunting task when I want to employ lilypond notation to drive a chuck composition. The R package tabr seems to deliver the tools for these bridges; see the initial vignette Noteworthiness: “tabr provides a music notation syntax system represented in R code and a collection of music programming functions for generating, manipulating, organizing and analyzing musical information structures in R. While other packages focus on working with acoustic data more generally, tabr provides a framework for creating and working with musical data in a common music notation format.”

And I'm also confident that my experience with notator's event handling for sequencing will be a valuable source of inspiration. Or the astonishing simplicity of notator's transform form – see Figure 10 – which is extensively discussed in the Manual [1], chapter 24, 3 Structure of the Transform Window. Looks like retro? Hmm. Guess again.

I think the very first move is employing chuck to note the events into a csv file. Or json for complex data like a glissando or a set or variables for a sound or program change. I guess both, or the good old database with normalized tables? Employing chuck should be the fastest way to a piano roll.

I already put up an org mode file for all of tabr's elaborated vignettes. Just to understand the scope of the package. But I'm still undecided if all these tools are really helpful. For they obscure a big deal of insight if used without understanding lilypond. And lilypond in turn – for me – is a hard nut to crack either. Even if I also worked with its predecessors musictex and musixtex. So I think my entry toolset presented in this blog has still a lot to offer.

Supplements of this blog entry: I provide the pdf here at pjs.netlify.app and a reduced version of the org source at bitbucket.org.

The online help for the installation of chuck offers installers and source files for windows and macos. For linux systems the help is reduced to the statement that the library libsndfile (linked to www.mega-nerd.com) is somehow involved and that the user should have gcc, lex, yacc, and make; see the release page at chuck.cs.princeton.edu. On this release page the link which says “access all versions here” also offers a cygwin version, and the most recent manual.

• 2022-02-18, ubuntu 20.04.3 LTS: chuck-1.4.1.0 doesn't install, chuck-1.4.0.1 works, but shows some warnings; ubuntu itself offers the installation of version 1.2.0.8.dfsg-1.5build1, same at 2022-11-20.
• 2022-12-04, chuck-1.4.1.1 released in June 2022. The release page announces that the chucK-1.4.x.x versions are part of the NumChucKs releases of chuck which allow embedding any number of virtual chuck machines.

Satellite ccrma is an entire customized version of linux that includes a number of applications for computer music and physical computing, including chuck. — A hint from Section Installing on Ubuntu Linux in [6]'s Appendix A /Installing ChucK and miniAudicle/

The org mode source code for starting a single chuck process (shred) in the emacs buffer looks like

#+header: :noeval
#+begin_src bash :exports none :results none
  chuck iCkBkEx/chapter1/Listing1.20.ck
#+end_src

I'm starting the script by disconnecting³⁵ the :noeval header from the source code, i.e., arming the code, and then evaluating it with C-c C-c. To stop the script I use C-g.

I once happended to notice a missing up-beat glissando while playing the script. But I couldn't reproduce the error on the next restart. I remember that the usage of vlc often leads to awkward behavior of the linux audio system when switching to another program. The PhD [15] only mentions internal latency problems of a sound calculation that takes longer than playing.36.

Another mode for working with chuck code from within an org file is tangling.³⁷ I demonstrate this feature with some short code example from the sidebox Chuck is a real programming language³⁸ in [6]. Its realization as org mode source code block is

#+begin_src chuck :tangle ../iMuMy/Chuck/lst1p22.ck :noeval
  Impulse imp => ResonZ filt => NRev rev => dac;
  0.04 => rev.mix;
  100.0 => filt.Q => filt.gain;
  while (1) {
      Std.mtof(Math.random2(60,84)) => filt.freq;
      1.0 => imp.next;
      100::ms => now; }
#+end_src

The default way to tangle this block would be arranged with the header argument :tangle yes. This argument in the a code block's header of the file 📂 xx.org copies the code to 📂 xx.chuck; changing #+begin_src chuck to #+begin_src ck leads to 📂 xx.ck; no major-mode hacking.³⁹ For more than one blocks in an org file with the same target file the argument :padline controls empty line insertion between the source blocks. Permissions for the file are set like :tangle-mode (identity #o755). After tangling with an explicitly given file name, like show in the code above, the script can be processed⁴⁰ with the bash command

chuck ../iMuMy/Chuck/lst1p22.ck

imho the book Programming for Musicians and Digital Artists Creating Music with Chuck [6] offers the most comprehensive and vivid approach for the first contact with chuck. Unfortunately its distribution as a $30 book doesn't meet the requirements of free software → free documentation, unless the authors wouldn't consider their book as documentation. In 2021 the publisher offered the free chapters 0 Introduction, 3 Arrays, and 6 UGens at manning.com,⁴² while the program page chuck.cs.princeton.edu links to an amazon dp url. The examples of this book are provided in the directory 📂 examples/book/digital-artists of the source zip or tar 📂 chuck-1.X.Y.Z. After installation I found it in the folder above at 📂 /usr/share/doc/chuck. It's also mirrored at github. For free documentation the dear reader may turn to

• the Web pages at Princeton and Stanford,
• the Manual for the 1.3.x.x versions from 2007, 191 pages, linked at the tutorial page, other Manual versions can be extracted from the previous versions at the release page, probably version 1.2.0.8, 2004, with 159 pages.
• the PhD thesis, connected at the language section of the documentation's root page,
• A chuck archive.flossmanual pointing at lick which is a github “shared repository for various bits of reusable chuck code.”
• most articles from Ge Wang's publication page linked at chuck.cs.princeton.edu, and
• some of the Princeton SoundLab publications page which was maintained until 2010.

The other examples are planted at a structured example page. It's structure may be interpreted as a parallel view-of or approach-to chuck programming.