- chuck-users - lists.cs.princeton.edu

language-chuck package for Atom
by Szilveszter Tóth 19 Feb '17

19 Feb '17

Hello everyone, A new version of the language-chuck syntax highlighting package for the Atom editor has been released. I have also contributed to it, it recognizes all the latest built-in classes (Chugins too) and works pretty well. https://atom.io/packages/language-chuck The only issue I am aware of is that it does not recognize => style one parameter function calls (it highlights them the same as variable assignments). Regards, Hillaby

1 0

2017 CCRMA Summer Workshops
by Romain Michon 12 Feb '17

12 Feb '17

[apologies for cross posting /\ please distribute widely] Greetings, The 2017 CCRMA (Stanford University) summer workshops have been announced. Please, find the detailed schedule below. More information @: https://ccrma.stanford.edu/workshops or by contacting Nette Worthey (networth(a)ccrma.stanford.edu). We look forward to see you there! Cheers, Romain 6/19 - 6/23 *Mobile Synth I - Mobile App Development for Sound Synthesis and Processing in Faust <http://ccrma.stanford.edu/workshops/mobilesynthi-2017>*: Romain Michon 6/19 - 6/23 *Virtual Analog Models of Audio Circuitry <https://ccrma.stanford.edu/workshops/virtualanalogmodeling-2017>*: François Germain, Kurt Werner 6/26 - 6/30 *Mobile Synth II - 3D Printing and Musical Interface Design for Smartphone Augmentation <https://ccrma.stanford.edu/workshops/mobilesynthii-2017>*: Romain Michon and John Granzow 6/26 - 6/30 *Programming Max/MSP <https://ccrma.stanford.edu/workshops/maxmsp-2017>*: Structuring Interactive Software for Digital Arts: Matthew Wright, Christopher Jette 7/3 - 7/7 *Algorithmic Composition with Max/MSP and Open Music <https://ccrma.stanford.edu/workshops/algocomp-2017>*: Andrew Watts, Davor Vincze 7/10 - 7/14 *Electronic Arts Ensemble <https://ccrma.stanford.edu/workshops/eae-2017>*: Constantin Basica, Alex Chechile 7/24 - 7/28 *Music Information Retrieval* <https://ccrma.stanford.edu/workshops/music-information-retrieval-2017>: Steve Tjoa and Jeff Scott, Gracenote 7/31 - 8/4 *Deep Learning for Music Information Retrieval <https://ccrma.stanford.edu/workshops/deepmir-2017>*: Irán Román 8/7 - 8/11 *Formalized Score Control: Using Python and Abjad in Music Composition <https://ccrma.stanford.edu/workshops/abjad-2017>*: Jeff Treviño, Trevor Bača and Josiah Wolf Oberholtzer 8/13 - 8/17 *SuperCollider <https://ccrma.stanford.edu/supercollider-2017>*: Fernando Lopez-Lezcano and Bruno Ruviaro 8/21 - 8/25 *Designing Musical Games: Gaming Musical Design <https://ccrma.stanford.edu/workshops/designingmusicalgames-2017>*: Rob Hamilton and Chris Platz TO BE SCHEDULED: *Perceptual Audio Coding <https://ccrma.stanford.edu/workshops/perceptual-audio-coding-2016>:* Marina Bosi, Richard Goldberg -- Romain Michon PhD Candidate Center for Computer Research in Music and Acoustics Stanford Universityhttp://ccrma.stanford.edu/~rmichon

1 0

Call for Papers: Algorithmic Electronic Dance Music
by Nick Collins 10 Feb '17

10 Feb '17

[apologies for cross posting] CFP: Algorithmic Electronic Dance Music Special edition of Dancecult: Journal of Electronic Dance Music Culture Guest Editors: Shelly Knotts and Nick Collins http://dj.dancecult.net/ Algorithms are at the heart of the virtual studio software applications underwriting so much contemporary dance music, but are normally the prior preserve of music engineering teams rather than musicians. This special issue, however, engages with algorithms as musical material, and especially with music which is inherently founded on computer programming technique. A recent manifestation of this is the algorave, an explicit site of live algorithmic electronic dance music (EDM), produced through such means as on stage computer programming (algorave.com). Creators of EDM have vast amounts of software at their disposal, including specific musical programming languages; modern digital audio workstations now often include the capacity to utilise a programming language, such as Python and Max/MSP embedded within Ableton Live, or Logic’s MIDI Scripter. The history of algorithmic techniques within mainstream and experimental fringe dance music predates the coining of the term algorave (Collins and McLean 2014). Powerful computer music coding environments have been co-opted for use in club contexts, by such well known figures as Autechre (Max/MSP), BT (Csound, Composer’s Desktop Project), Cylob, Aphex Twin (SuperCollider), and Holly Herndon (Chuck), amongst many others. Some artists have written their own software from scratch, such as the generative gabba-techno artists slub, or commissioned others to supply it, as with Coldcut and the VJamm and Coldcutter programs. Research in this area extends from the introduction of new algorithmic techniques for the production of dance music, to the computational analysis of existing EDM, via critical appraisal of algorithms in the wild. Live realtime systems, as well as offline studio software, have been developed. An increasingly algorithmically literate culture will see increasingly algorithmically literate music, and the rise of music-oriented computer programming has great implications for future directions within EDM. (2014) Nick Collins and Alex McLean “Algorave: live performance of algorithmic electronic dance music”. Proceedings of NIME 2014, London // SUGGESTED THEMES // Potential themes for articles include (but are not limited to): - Analysis of the work of algorithmic EDM artists - Computational analysis procedures for EDM - Surveying algorithmic techniques in EDM production - Algorithmic composition projects based on EDM styles - Live coding and EDM - Web browser based dance music systems (e.g., via Flash, HTML5, Web Audio API et al.) - Music Information Retrieval (MIR) systems and EDM content creation - The programming of interactive systems for EDM creation - Music pedagogy through coding of EDM (e.g., Sonic Pi, EarSketch et al.) - Gender, ethnicity and social trends at the crossover of computer music and club culture - Collaborating with and through algorithms; EDM groups of musical programmers - Algorithmic audiovisuals for club performance - Performance and audience reception of Algorithmic EDM // SUBMISSIONS // Feature Articles: Feature Articles will be peer-reviewed and are 6000–9000 words in length (including endnotes, captions and bibliography). For policies, see: https://dj.dancecult.net/index.php/dancecult/about/editorialPolicies#sectio… “From the Floor” Articles: This special edition will also include articles in From the Floor format (750–2500 words), which are very suitable for an artist to critically evaluate their own practice, or an academic to discuss new experiments. This format will be of particular interest to scholars and practitioners who wish to share some of the insights of their work, but are unable to devote the time necessary for a feature-length article. See guidelines at the Section Policies link above. Articles must adhere to all style and formatting rules stipulated in the Dancecult Style Guide (DSG). Download it here: https://dj.dancecult.net/public/journals/24/dancecult_styleguide.pdf Multimedia Submissions: Dancecult encourages authors to complement their written work with audio and visual material. See the DSG for style and formatting requirements. // DATES AND DEADLINES // This special edition is proposed for publication in Dancecult on 1 November 2018. If interested, send a 250-word abstract (along with a one hundred word maximum author biography) to Shelly Knotts (knotts.shelly(a)gmail.com) by 23rd March 2017. If your abstract is accepted, the deadline for submission of a full article draft to the guest editors for their comments is 1 October 2017. Beyond that, the deadline for online submission to Dancecult (for blind peer-review) is 1 February 2018. Please send enquiries and expressions of interest to Shelly Knotts: knotts.shelly(a)gmail.com A PDF version of this call, with live links and editor biographies, is available from: http://composerprogrammer.com/algoraveCFP.pdf

1 0

Re: [chuck-users] ChucK => internet audio stream
by Stuart McDonald 05 Feb '17

05 Feb '17

Ok, so after a lot of fiddling (mostly around making documentation and audio processing work for generic installation) I've gotten chuck => darkice => icecast running in docker on a raspberry pi using ALSA snd-aloop loopback module. Some links: * https://hub.docker.com/r/concretemixer/cm-rpi-internet/ # docker image * https://github.com/concrete-mixer/cm-rpi-docker-internet # git repo for docker image with instructions on installation * https://github.com/concrete-mixer/concrete-mixer # about what you are hearing http://concrete-mixer.venturus.io/concrete-mixer.mp3 # a live implementation (hopefully running; the pi sits dangerously close to my feet). As originally mentioned my original intention was to run this on AWS, but the pi seems to accommodate chuck + darkice + icecast reasonably well (4 processors helps!). Since the setup doesn't rely on sound hardware, there's no reason an AWS machine couldn't run a similar rig. Hopefully this is useful to someone who may want to go down this path in future :). Stuart

1 0

inheritance question
by Voytek Lapinski 23 Jan '17

23 Jan '17

Hi All, Just getting into ChucK and have a language question. I have some base classes which I have written and am struggling with how to get the inheritance to do what I want. I have a class Voice, and a class Polysynth which contains an array of Voices as data, like so: public class Polysynth { { Voice voices[]; // methods which work on the objects in 'voices', // .. } I want to be able to set up a patch which defines (for example) a MySynth_Voice (subclassing Voice) and MySynth (subclassing Polysynth). MySynth objects will thus contain an array of Mysynth_Voice objects. I want to then be able to call methods on MySynth that are defined in Polysynth, that uses the array of MySynth_Voices as data. The problem is, because they are expecting Voice objects, they aren't happy to receive MySynth_Voices instead (even though MySynth_Voice inherits from Voice). I can't cast them in the Polysynth methods that use it because it won't compile unless 'voices' is declared. It has to be declared as 'Voice', and if I try to override it in the subclass (eg. "MySynth_Voice voices[]"), it won't compile saying saying it "has already been defined in super class 'Polysynth'". I tried a bunch of different ways to do this, but the only way I can find to do it was to cast the voices array in the subclass as follows. class MySynth extends Polysynth { fun void init (int num_voices) { MySynth_Voice voices_temp[num_voices]; Voice voices_temp2[num_voices]; for (0=>int i; i < num_voices; i++) { voices_temp[i] $ Voice @=> voices_temp2[i]; } voices_temp2 @=> voices; } } Firstly, is it possible to do this without having to do this casting bit? It seems like a common inheritance set up, so am wondering if I have just missed something. Failing that, is there a better way to do the casting step? I tried to do in obvious ways like 'MySynth_Voice $ Voice[] @=> voices' but that, and other possible permutations I could think of, wouldn't compile. The iterating over the whole array and doing each member explicitly seemed to be the only thing that worked. It's certainly no big deal and I can live with it, but am just curious if there's a nicer way to do it. Thanks all... -voytek

1 0

Re: [chuck-users] chuck-users Digest, Vol 138, Issue 8
by Stuart McDonald 21 Jan '17

21 Jan '17

HI Mark, Ok, some news from the front: I've got what I want going on a pi with alsa's snd-aloop module (see https://www.alsa-project.org/main/index.php/Matrix:Module-aloop). This sets up an input device which loops back to an output device. So I used chuck --probe to get the corresponding dac number for the input, sent chuck into that by specifying --dac, and then set up darkice to listen to the output device. >From there the data gets sent to icecast on the same pi. The whole system seems to run stably and generate audio constantly (I've got a shell script restarting the chuck process after it finishes (c. half an hour for each go). Since I now have an rpi with a bunch of cobbled together configuration I'd like to formalise it and make it repeatable, so I'll be looking at your and mheuer's docker work :) Thanks, Stuart > ---------- Forwarded message ---------- > From: Mark Cerqueira <mark.cerqueira(a)gmail.com> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Cc: > Date: Mon, 16 Jan 2017 20:01:24 -0800 > Subject: Re: [chuck-users] ChucK => internet audio stream? <snip> > Stuart - I think you could accomplish your idea with some work over my Docker image. AFAIK, the --silent flag does not mean no sound is produced; it just means no audio is outputted during the running of the program. You could set something up like: > > 1. Let ChucK produce 30 seconds of audio (with --silent it should take less than 30 seconds to produce 30 seconds of audio) and save it to an audio file. Look at export.ck in the chuck-renderer repo for how to do this. > 2. Streaming clients grab this 30 seconds of audio and start playing it. > 3. While the above is occurring, you produce another 30 seconds of audio. > 4. Send the next audio file to clients and they queue it up after the first segment ends. > 5. Rinse, repeat. > > This has the added benefit of letting ChucK shut down between producing segments to do garbage collection. :) You might need some annealing to get the separate audio to sound "together" but this should get you a "Hello, World ChucK stream." > > Good luck! > > mc

1 0

Re: [chuck-users] ChucK => internet audio stream?
by Stuart McDonald 16 Jan '17

16 Jan '17

Thanks to those who responded; will look at Jack, DarkIce and Liquidsoap. What I was ideally hoping to do is running chuck => DarkIce/Liquidsoap => Icecast on an Amazon EC2 appliance, but a lack of soundcard on these machines complicates things. Cheers ears, Stuart

5 6

Re: [chuck-users] ChucK => internet audio stream?
by Stuart McDonald 16 Jan '17

16 Jan '17

Oh nice, I was looking at possibly using my project as a way of teaching myself Docker. The problem I have is I want to operate ChucK continuously, basically like an internet radio station. I get around memory leaks by restarting the ChucK process periodically, so in itself it should be steady state. This means I can't really use --silent -- unless I'm not understanding how that flag works. I'm not looking for answers to these questons, just sort of stating what I'm up to in case it is of interest. :) I haven't started on the streaming part of this project yet (still working on core app), but will advise if anything interesting comes up. Thanks Stuart > ---------- Forwarded message ---------- > From: Mark Cerqueira <mark.cerqueira(a)gmail.com> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Cc: > Date: Fri, 13 Jan 2017 17:16:54 -0800 > Subject: Re: [chuck-users] ChucK => internet audio stream? > I set up a Docker image this week that lets you pass it ChucK source code or file, it runs it for up to 30 seconds (with --silent flag so it does this step much faster than 30 seconds), saves the output to .wav, converts the .wav to .m4a to make the file smaller, and then hosts the file for download/streaming. > > Demo container running Docker image: http://chuck-renderer.4860ca31.svc.dockerapp.io:9000/debug > > Source code: https://github.com/markcerqueira/chuck-renderer > > Image on Docker hub: https://hub.docker.com/r/markcerqueira/chuck-renderer/ > > Cheers! > > mc

1 0

Cannot assign array of Oscs to UGen[]
by Karim Sumun 07 Jan '17

07 Jan '17

Given the following declarations: SinOsc s0; SqrOsc s1; TriOsc s2; The following gives an error: [s0, s1, s2] @=> UGen A[]; $ ... cannot resolve operator '=>' on types 'Osc[]' and 'UGen[]'... But the following works fine: [s0, s1, s2] @=> Osc A[]; It is not a problem, but would like to understand this behaviour. It would seem that assigning to UGen[] would be ok because it looks like a superclass of Osc[]. Aaah! Is this to do with co/contra-variance?

2 1

ChucK => internet audio stream?
by Stuart McDonald 07 Jan '17

07 Jan '17

Hi, I'd like to send ChucK's audio output to an internet streaming application (like icecast). Ideally ChucK wouldn't write to the dac at all, but to an IP:port or socket or similar. The only info Google provides is a note in passing for the documentation for chuck --silent: "This is useful for synthesizing audio to disk or network" ...which makes it sound like this is possible, but provides no information on how to do it. Has anyone been down this path? Was it fun? Thanks Stuart

5 4