Long-time user of Csound, Max, and Pd (& have spent a little time with ChucK & Supercollider).
Max & Pd are fantastic for incorporating sensors & other physical interfaces, real-time interactivity, routing signals, creating visualizations, & all that. Supercollider is fantastic for generative music & using control flow compositionally.
Csound, on the other hand, is really, really great for creating beautiful & nuanced electronic compositions. The sound quality is unrivaled (emphasis on accuracy over interactivity), the interface is great (plain text, which, as a programmer, I prefer), and GEN routines plus the myriad opcodes allow you to do some heavy, intricate aural spelunking.
As a bonus (& as mentioned by others), it’s highly performant & fairly easy to integrate with other languages & environments (including Max & Pd!).
The syntax is a bit strange, but once you get over that, Csound is an amazing piece of software.
There's no real reason to consider csound any different from any other synthesiser in this respect: someone who understands how to program a synth just needs to know "which knobs and switches" there are - whether they're physical hardware, a virtual instrument's GUI, or xml statements doesn't matter all that much... the only thing that matters is being able to set and control VFOs/LFOs, ADSR, resonance, unison, etc. =)
Youtube is actually an excellent resource here - search for "intro to Synthesis" or "intro to synthesizers", and move up to "advanced synthesis" (or related terms) and there are boatloads of excellent videos teaching you more than you ever thought was possible.
It might give you a feel for how you can create compositions that sound very remote from what most people would think of as musical. The whole piece is synthesized sound with "instruments" consisting of various types of signal generators composed together.
I've used CSound for a university project some years ago, to manipulate a bunch of files to play together - adjust volumes, modify speed of playing without modifying tonality, etc.
I then wrote a GUI to manage CSound. After 8 years, here's what I remember:
- It was very complicated to wrap a C library in Java, at least for a new graduate like me.
- There was no learning material for the kind of things I needed to do (manipulating wav files). learing CSound at the time was a mess - no blog posts in 2010.
- If I read the CSound source file I wrote in 2010 I'm sure I would not understand a single line.
Some years later, when Coursera was just starting to offer free courses to the world, I encountered another musical programming language called ChucK (https://chuck.cs.princeton.edu/). The course was very well done and ChucK too, was so simple that I almost decided to rewrite the whole project with it. I wrote some very nice pieces of music while studying ChucK.
I don't know what the state of CSound's SWIG support was when you integrated it with Java by hand, but CSound now uses SWIG to generate Python and Java wrappers. (I know what you mean: writing wrappers for something as complex as CSound for any language is an enormous tedious error-prone pain in the wazoo, which is why it's so nice to have a tool like SWIG that does it automatically for you.)
The cool thing about SWIG (Scripting Wrapper and Interface Generator) is that it supports multiple scripting languages (and other kinds of languages, since it's debatable if Java is a "scripting language"). It understands most of C++, so it can automatically read in header files and generate wrappers from them, but you can also tailor and customize the interfaces and how it marshals different data types back and forth, to create more efficient, convenient wrappers, too.
>David Beazley is an American software engineer. He has made significant contributions to the Python developer community, which includes writing the definitive Python reference text Python Essential Reference, the SWIG software tool for creating language agnostic C and C++ extensions, and the PLY parsing tool. He has served on the program committees for PyCon and the O'Reilly Open Source Convention, and was elected a fellow of the Python Software Foundation in 2002.
Choices like wrapping a C library from Java in order to use CSound and using CSound to play WAV files in the first place seem very against the grain.
A project about playing back recorded audio with interactive control should be feasible in Java, dispensing with CSound and JNI complications entirely, while a project to do something with CSound could focus on the strong points of CSound and avoid technical hurdles (e.g. Java programs that generate highly complex CSound code for highly complex music).
Yeah this piece was a huge piece of inspiration for me when I was learning Csound. I actually had a chance to ask BT about this particular piece once and if the rumors were true about it being all done in Csound. The guitar riff you hear halfway through the piece is actually sampled and played via the diskin opcode. Other than that, all Csound. Still a very impressive feat, especially considering the fact that the piece itself was originally mixed in 5.1.
Nice! I'd wondered about that guitar, it sounds impossibly real to be pure Csound. Thanks for the insight. And yes, I had the opportunity to listen to the whole album on a decent 5.1 system at uni a while back and it's pretty spectacular.
There's also ChucK from Princeton which I find more intuitive than Csound or alternatives such as Supercollider. Much smaller community that Supercollider, though, I guess.
Csound is a fantastic sound design tool. It was my main composition tool for many years, before I started building my own system. The score/orchestra paradigm is incredibly powerful. It's something I miss quite often in my current system. When I was in music school, I learned how to program by writing programs in Python to generate scores that could then be played by Csound. Scores are so trivial to generate, that you actually don't need to learn that much programming to generating very satisfying algorithmic compositions.
I appreciate that the title of this post calls it a "sound and music computing system" rather than a "musical programming language". In truth, Csound is more of a text-based modular synthesis environment than a programming language.
As others have said, the orchestra syntax is a bit strange at first, but you do get used to it. Writing Csound code feels more like patching a modular synthesizer rather than writing a computer program. It's basically a DSL for connecting small sound/signal modules (called opcodes) together. Most of the time one thinks about things in terms of signal flow and not computer logic. A common mistake I see new Csounders make is to immediately reach for the conditional statements and loops. They often don't behave the way you expect, so people get frustrated.
The Csound dev team has a very strong emphasis on backwards compatibility, to the point where the older opcodes do not get bugfixes in case someone is exploiting the bug in the compositions. The programmer in me groans a little bit, but the composer takes great comfort in the fact that pieces I write now will be playable for many years or even decades (some of the Csound test pieces, like Trapped In Convert by Richard Boulanger or Xanadu by Joeseph Kung, are over 30 years old and still run).
I've been told that many works written in MusicN languages (a precursor to Csound) have been ported to run in Csound, which means that the legacy of Csound includes computer music written in the 60s! I wish I knew where to find those, as I quite enjoy computer music history.
> Writing Csound code feels more like patching a modular synthesizer rather than writing a computer program.
I agree with this point. I am using Csound for creating VST plugins (with Cabbage framework[1]) for which is Csound extremely productive. I can have working prototype (which I can actually play on my keyboard) ready in something like 15 minutes.
Once you get over somewhat strange syntax[2] and understand difference between k-time and i-time[3] you can do any DSP processing without actually diving into hard math.
Cabbage has nice beginner documentation on Csound[4].
I’ve been learning Csound for about a year now, and I’ve documented my experiences in my blog at https://jasonhallen.com/blog. My first three blog posts talk about 1) why I chose Csound over Max/MSP, SuperCollider, and ChucK, 2) how mysterious the online presence of Csound is, and 3) what resources have been most helpful for me as I’ve learned Csound.
I love Csound, but it has been very challenging to learn. The first two or three months were an uphill battle where I thought about quitting a few times. Admittedly, I was brand new to both computer programming and digital audio generation. I’m sure if I had more experience with those then picking up Csound wouldn’t have been as painful. The biggest early challenge for me was understanding how the three variable rates (initialization rate, control rate, and audio rate) work. I felt like I had to hit my head against a wall for three weeks before that clicked. But once you become familiar with the basic principles and syntax of Csound you start picking up other topics and opcodes quicker.
I’ve used both CsoundQt and Cabbage as Csound development environments. They each have their pros and cons and best use cases. I’ve been using Cabbage more because it has an ingenious way of controlling the instrument interface within the Csound code itself.
There are a ton of opcodes available to do many sound design techniques out of the box, or you can code your own opcodes to do anything you’d like. The user community is very responsive and helpful on the Csound listserv (http://csound.1045644.n5.nabble.com/). And the developers have made it so you can integrate Csound with all sorts of other languages and software.
Does anyone use Csound for Live? It's no longer working since the Ableton 10.1 update and the Developers do not respond to emails. Incredible set of audio tools.
Sonic Pi (IMO) is very quick to get started with because it's batteries included - you have everything needed in a single installer. Within the UI are tutorials, samples, synths, effects, a language reference, metering, 10 code buffers, and an OSC server built in - so once you config audio/MIDI devices you should be good to go. Sonic Pi is based on a subset of Ruby (though it's not clear which Ruby version, and what's left out) and Sam Aaron (dev) has indicated he's considering moving to another language. Though I haven't played around with Raspberry Pi, Sonic Pi integration is another benefit if you're into hardware.
I remember trying to install Tidal Cycles a few years back and having some difficulty - IIRC it's a library that requires other components/config. Same for Overtone [1] (Clojure frontend to SuperCollider), it took a bit of time to configure Leinengen at first.
Cabbage [2] interface to CSound would probably be closest to Sonic Pi, rather than straight CSound iteself.
Also worth investigating is Pyo [3] - a Python interface to DSP code written in C.
So many interesting (and free) choices - it really just comes down to your language preference. I make a lot of music in DAWs like Ableton Live & Apple Logic, but I have some fairly original, very specific ideas around exploring pitch, rhythm & harmony that a text-based language is better suited for.
"One of the motives for being an artist is to recreate a condition where you're actually out of your depth, where you're uncertain, no longer controlling yourself, yet you're generating something, like surfing as opposed to digging a tunnel. Tunnel-digging activity is necessary, but what artists like, if they still like what they're doing, is the surfing" — Brian Eno
(Aurora Musicalis. ArtForum Magazine. 24:10. 1986)
At its base, it is a system that takes a programmatic score, as well as programmatic descriptions of synthesized instruments or processors, and produces audio output. Other tools in this category include CLM, Supercollider, and STK, though Csound has a history that predates all of them.
What makes it different from popular music tools is that you are in control of the instruments' guts, and can create custom instruments, so you can apply virtually any form of synthesis, any type of audio transformation or generation, you can imagine. This makes it ideal for experimenting with synthesis and algorithmic composition.
"Electro-acoustic" is an academic term that encompasses various forms of experimental music and research involving artificial sound sources, including electronic music, electric instruments, tape loops and manipulation, computer-generated music, and so forth. Roughly: "any avant-garde music that requires loudspeakers to perform." You can of course use Csound for more popular music applications as well, but you would typically find traditional DAW tools to be more convenient in those cases.
Basically it's for creating music programmatically, conceptually it's solid although it does lack some major features (you have to convert frequencies to notes, and as far as I'm aware there's no inherent option to use the note itself).
You can use different ways to enter pitch [0].
A common way is to use the "octave.pitch" format, such as 08.04, where 08 is the central octave (if I remember correctly) and 04 is the note E. It's common to use a score generator such as PythonScore [1, 2], and some people (myself included) like to use a regular programming language to generate the scores. I've used Common Lisp, Tcl, and Python in the past. Csound has a few frontends [3] that people may like.
AFAIK, Csound can read notes from a MIDI keyboard as well.
If you've ever seen a modular synth, like a Moog, it's basically a programmatic version of that. You wire the outputs of signal generators to the inputs of others to create instruments. Then you create a score, which triggers the instruments with input parameters at specified times, simulating the performance of your instruments or conducting of your orchestra. The output is either live sound or a sound file.
You often find it in the heart of VST/AU plugins, within ios and android apps. Now it can work from the web. Its also heavily used in games for programmatic sound effects. But its more of a library or framework for audio/midi rather than a full blown user facing system like Max/MSP.
VST/AUs are more likely to be written from scratch, often inside a wrapper like JUCE to abstract away the OS-specific details.
CSound is a grab-bag of mediocre DSP algos hacked together from various sources by academics who have no interest in professional production values.
While you can build your own synths with Csound, they don't usually sound very good.
Games are actually more likely to use PDLib, although there's also a lot of custom C++ in some games.
There's a significant difference in sophistication between the crude algos in Csound and the algos in successful commercial VSTs like Serum, Uhe's synths, the Roland Cloud collection, SoftTube, UAD, and FabFilter mixing tools, and so on.
> There's a significant difference in sophistication between the crude algos in Csound and the algos in successful commercial VSTs like Serum, Uhe's synths, the Roland Cloud collection, SoftTube, UAD, and FabFilter mixing tools, and so on.
I don't know about "crude," but yeah. And honestly? There is no comparison between the components in Max/Pd/sc/ChuCK and any of this stuff either (I joke with my art-music friends that I like everything about Max except the sound ;). You'll never hear something like Cytomic's The Drop (a filter that can crush your CPU) or serious tape saturation, or sophisticated EQ curves with lots of warmth and character.
It's true that you could create any kind of filter, oscillator, DSP-whatever you want with these systems, but in practice, the people working with these tools are not U-he-level DSP programmers, and it shows.
I wish that weren't true, because I'd much rather code stuff csound-style than work in a DAW with a bunch of expensive plugins.
But is it true that you can run VSTs in csound? Could you use commercial VSTs, but write fancy controllers in csound?
I don't know much about this, but sure did like seeing this in the description:
"One of the main principles in Csound development is to guarantee backwards compatibility. You can still render a Csound source file from 1986 on the latest Csound release, and you should be able to render a file written today with the latest Csound in 2036."
I wish more "modern" languages and frameworks put in the effort on this point as well.
Puredata and Max/MSP are great, but programmed in a visual dataflow style rather than a source-code style. Imo that makes some things much more intuitive and other things really complex.
The visual dataflow style is especially good for interactive stuff, where you're taking inputs and running them through chains of synths and filters, but it gets really hairy if you want to do non-interactive composition. People use it for that too, but you end up with huge banks of delay lines to simulate control-flow constructs, which in other languages could've just been a for loop.
Yeah ! So much this. Iterations / branches / arrays ... in Max is pure nightmare. Supercollider is a breeze to work with hundreds / thousands of audio buffers and the multichannel / polyphonic capabilities are incredible. I found it very hard to build a stable complex patch in Pd / Max if you are not that much experienced with the opaque control flows.
> but you end up with huge banks of delay lines to simulate control-flow constructs
I'm not sure what you're referring to. Pd has a whole category of control objects for routing arbitrary message data. This includes branching and looping in zero logical time.
Have you used it? I usually don't use proprietary software but I've been thinking of giving it a go. Supposedly bitwig has a language as well but I haven't used it either
Bitwig uses JavaScript for MIDI controller scripting [1], then in version 3 they released The Grid [2] - which is a modular (but not low-level/basic DSP) visual environment allowing the creation of custom synths/effects. You can go deeper with Max for Live which is bundled with Ableton Live Suite. There is apparently a somewhat-hidden Ableton Python API. [3]
REAPER is probably the most-scriptable DAW of all, with an API using EEL, Lua, and/or Python. [4]
Miller Puckette originally created Max at IRCAM (Institut de Recherche et Coordination Acoustique/Musique) in 1985, which is now marketed by Cycling '74.
Then he later developed the open source Pure Data (PD) in the 90's, which also included real time signal processing features (flowing streams of high frequency audio over wires whose samples are at a much higher rate than the frame rate of the visual program's control signals).
Max/MSP and PS are both visual data flow programming languages, where data flows along wires between icons, but some data (like audio stream samples) flow much faster than others (like messages, logic, and control signals).
Cycling '74 Max later adapted Puckette's work on Pure Data and called it "Max/MSP", which stands for both "Max Signal Processing" and his initial "Miller Smith Puckette".
>Max is named after composer Max Mathews, and can be considered a descendant of his MUSIC language, though its graphical nature disguises that fact. Like most MUSIC-N languages, Max distinguishes between two levels of time: that of an event scheduler, and that of the DSP (this corresponds to the distinction between k-rate and a-rate processes in Csound, and control rate vs. audio rate in SuperCollider).
> flowing streams of high frequency audio over wires whose samples are at a much higher rate than the frame rate of the visual program's control signals
Pd's "control" classes are probably confusing to programmers coming from other computer music environments. There's no control rate in Pd.
The "control" classes (the ones without a tilde at the end of their name) send messages in zero logical time and may be triggered sporadically. Building diagrams out of them is like building an immediate-mode Rube Goldberg machine.
There are some conversion classes that allow control <-> signal object communication. Some of the control-to-signal classes do conversion at what you could call "control rate"-- e.g., they might compute a single value and copy it to the rest of the samples for output. Others do sub-sample accuracy bounded by the precision of floats (single or double as Pd can be compiled to use either).
If you're weird you can use [bang~] to emulate a control rate diagram-- it will literally output the "bang" message at each block which you can then feed to a downstream Rube Goldberg machine in order to do arbitrary message passing each block. But that's less ergonomic than just using signal objects which a) all send the same type of vector data and b) get automatically ordered by the graph builder and are therefore easier to read. (The irony being that signal diagrams generally deal with DSP, so the readable part of the diagram is the most conceptually complex and the simple stuff like branching or counting to 10 tends to end up looking like a plate of spaghetti.)
There's also overhead in the control message dispatch which would probably undo any imagined efficiency gains. Signal diagrams on the other hand get sorted into an array of function callbacks (as needed during runtime or editing time), so there's no chasing of pointers or type-checking to eat up cycles.
I've been using MaxMSP for a few years and I highly recommend it! There are tons of built in examples and pre-loaded modules. Their plugin and app store has a similar feel to Arduino's and also full of hundreds of free sketches by other users.
Opening someone else's sketch and playing around with the different components has been a great way for me to learn some of the more advanced features.
If you end up using it and making something cool, please share!
Csound is the music and audio signal processing language originally developed by MIT's Barry Vercoe and now expanded and maintained by a world-wide community, as Free Software. Csound will provide audio services for the XO computer. Csound is both a programming language and a sound synthesis engine. Csound, as included in the OLPC project, can be used by Activities or directly by children and teachers. It can be accessed in a variety of ways. In the XO platform, two basic ways are provided:
Through the Python programming environment: eg. programmed in Activities.
Through its 'classic' command-line frontend, directly invoking it from the Terminal activity.
Further information about Csound can be found on its official website: http://csounds.com/. The canonical Csound sources and multi-platform binaries are hosted by Sourceforge.
Activities
Csound Editor - view, edit and perform Csound files
TamTam - Tam Tam uses Csound, but you would never know it as its interface is designed to wrap the Csound engine with a child-friendly look and feel. This excellent group of Activities allows kids to make sounds, make music, jam, record and transform their voices in an intuitive way. TamTam Edit allows students to patch together Csound's opcodes (modules) and teaches them all about signals, synthesis, and synthesizers. TamTam Activities demonstrate well how the power of Csound can be harnessed in the XO platform.
GregCsoundActivities.zip - A number of Csound Server-based activities developed by Greg for Build 542 including a pretty cool Pitch-Tracker Bouncing Ball Activity and a Pitch
Reverse Game – both lot's of fun for kids, but not currently supported by the latest builds and security models.
Step - A simple 8-note step sequencer that children will use to play music and record their own loops for use in other sample-based activities. Step uses csndsugui.
Funny Talk - An activity that children can use to record their voices with the built-in microphone, and process them with effects such as reverb, echo, chorus, etc. Funny Talk allows a child to save their manipulated voices as soundfiles so that they can be used in other musical activities. Funny Talk uses csndsugui.
There was once another sort of 'competitor' to csound called cmusic, I believe the last surviving unmaintained port of it can be found at http://yadegari.org/carl.html
Here are some notes I wrote about some visual programming languages and real time performance tools for music and video that I wrote to the LEV mailing list in 2000 (and some additional notes and email I saved over the years).
That link also includes some interesting discussion with Jaron Lanier about visual programming language design.
Image/ine was a software instrument for realtime video manipulation and MIDI processing from STEIM (Studio for Electro-Instrumental Music) in Amsterdam, by Steina Vasulka and Tom Demeyer (1996-2001). It ran on a Mac, and you could write plug-ins for it.
Hookup is a real time visual programming language for controlling MIDI and playing music and rendering graphics, developed by David Levitt (who shared an office with Miller Puckette at MIT), which also incorporated the Macromedia Director MMP player plug-in (so it could read in Director files and play their content under visual program control).
>Mark Coniglio: Here's a bit of history. In 1986 my soon-to-be mentor and Interactor collaborator Mort Subotnick had just come from a residency at MIT where he was using a program called Hookup created by a student there named David Levitt. Hookup was the first program I know of that used the "patch-cord" metaphor, i.e., modules that manipulate data are linked by virtual wires, the connection of which is determined by the user. For those in the world of early analog, patch-cord programmed synthesizers, this was a familiar interface. Mort was using David's program to do tempo following of MIDI instruments -- this allowed him to lock hardware MIDI sequences to the tempo of the live performers. I was a composition student at CalArts at the time, and word had gotten around that I was a good programmer. So Mort contacted me to see if I could hardcode some of the ideas he had implemented in Hookup on a Mac, so that he could use them in his next performance. That program (used in Mort's 1987 multimedia work "Hungers") would eventually become Interactor. Mort designed the functionality of the early versions, but I became more influential in the design as time went on. [...]
>Mark: Yes, that's true and importantly a kind of creative intuition was creeping back in through the development of these new visual interface possibilities for software. Part of the thing I reacted to in Hookup was the way you could easily drop modules into the program and try things; a lot like you could do with the patch-cord synthesizers. I may not have realized it explicitly then, but this ability to program improvisationally allowed for that kind of artful playfulness that is so important. So I set out to make a similar user interface for Interactor. The creation of Isadora was a natural outgrowth of Interactor. In 1996 Troika Ranch had a two-week residency at STEIM, where I first saw Tom Demeyer's real-time video processing program Image/ine. I first started using Image/ine in concert with Interactor, because Image/ine didn't allow the kind of complicated interactive decision making that I was used to having in Interactor. So, Interactor would process the MIDI data from my interactive sensors, and then tell Image/ine what to do. By 1998 I was using Image/ine in a major way in my performances with Troika Ranch. [...]
>Mark: Isadora and Max both inherit the modules linked by the patch-cord metaphor from Hookup. But unlike Max, each Isadora module shows the parameter names and current values for all of its inputs and outputs, and many modules give real-time graphic feedback about their operation. This is important from the perspective of helping new users understand what's going on right away. But perhaps the biggest difference is that Max is a very powerful, open-ended programming language in which you could solve any number of problems. Isadora isn't that. It is a lot like Interactor in that each module is essentially a macro that accomplishes some specific function. This approach helps people who are just beginning to do this kind of work, as it means that useful functionality is already embodied for you and it's very easy to start doing things and getting interesting results quickly (like with Image/ine). Max allows the most flexibility, but may be somewhat more difficult to program because more things have to be built up from scratch. Isadora offers somewhat less flexibility, but is still open-ended enough for the user to imprint his or her aesthetic on the result.
While working at VPL, David also integrated the MMP library into Body Electric (below) to make Bounce (also below). The MMP player plug-in is what eventually became Macromedia Shockwave once it was plugged into the web browser (which wasn't nearly as fun as plugging it into a full fledged real time interactive visual programming language).
Body Electric is a real time visual programming language for VR and music and hardware control, developed at VPL by Chuck Blanchard, which Jaron Lanier and others used to create virtual reality simulations and virtual interactive musical instruments.
Body Electric supported all kinds of interesting input and output devices, including MIDI, sending and receiving UDP packets over Ethernet, loading Swivel3D 3D skeleton files and animating them, sending their state over the network to a pair of SGI workstations for rendering with the Isaac rendering engine to the VPL "EyePhones" VR headset (one SGI workstation per eye, with a Mac to run the simulation), VR input devices like VPL's DataGlove and Body Suit, 3D input devices like the Ascension Flock of Birds, Polhemus, and Spaceball, 3D audio output devices like the Convolvotron, and lots of other cool stuff.
Bounce is a derivative of Body Electric, that David Levitt integrated with the MMP player, and that I helped him develop, and used for some fun projects. Extremely weird and esoteric, but still one of the must productive, delightful visual programming languages I've used!
Here's an interview with Aaron McLeran, who has done a lot of work with CSound, and collaborated with Brian Eno on the procedural music in Will Wright's "Spore" computer game at Maxis, using Pure Data (PD).
>In today’s episode Oliver was joined via Skype by Aaron McLeran, Lead Audio Programmer at Epic Games. Aaron’s first taste of audio programming was writing computer music in CSound while in graduate school at University of Notre Dame (when he was supposed to be doing astrophysics research). Realising his true calling, he left physics to study procedural and interactive computer music, audio synthesis, and audio analysis with Dr. Curtis Roads at the University of Santa Barbara. His first game audio experience was writing procedural music on Spore where he got to collaborate with Brian Eno and Maxis’ audio director Kent Jolly on writing much of the game’s truly procedural music. His next game audio gig was a sound designer on Dead Space 2 where he wrote much of the games interactive audio systems in Lua along with accomplished audio director Don Veca. He made the leap from technical sound designer to audio programmer at Sledgehammer Games where he worked on Call of Duty: Modern Warfare 3 and Call of Duty: Advanced Warfare. His next audio programming gig was at ArenaNet where he got to wrangle with the unpredictability and scale of game audio in the context of an MMO and developed some pretty cool tech around for player-created music and musical interaction. He’s currently working on a new multi-platform audio mixer backend for UE4 and developing new tech and approaches to game audio for VR.
>Aaron speaks to Oliver about all things Game Audio and Procedural Audio and his unusual entry into the industry.
GDC Vault: Procedural Music in SPORE, with Kent Jolly, Aaron McLeran
>Pure Data has been used as the basis of a number of projects, as a prototyping language and a sound engine. The table interface called the Reactable and the abandoned iPhone app RjDj both embed Pd as a sound engine.
>Pd has been used for prototyping audio for video games by a number of audio designers. For example, EAPd is the internal version of Pd that is used at Electronic Arts (EA). It has also been embedded into EA Spore.
>Pd has also been used for networked performance, in the Networked Resources for Collaborative Improvisation (NRCI) Library.
the syntax for the language is horrible and very difficult to understand, the gui is hard to use and unstable, its just generally worse than other sound programming langs like supercollider
I'm being paid off by CSound, but I sure didn't flag you. It must have been one of the many other people that CSound is paying off. CSound sends me thousands of dollars per month to work from home, safely in isolation! You too can make money fast, by promoting CSound on blogs and web sites across the world wide web, and flagging people who call it trash! Simply email me your social security number, bank account information, and mother's maiden name, and you too can make money by promoting CSound online! Operators are standing by. Order before midnight tonight, or it will be tomorrow. Thanks, CSound! ;)
Csound is a programming language. Whatever GUI you are referring too is a third party application. There is no doubt the syntax takes a little getting used it, after all it is a direct descendant of the Music N languages. But in recent years the language has seen many improvements and updates.
While conceptually sound, CSound offers an unintuitive interface and program flow in my opinion. Also the lack of ability to do more "human-readable" actions like use music notes out of the box is a point of frustration (although it is possible with some extra steps.)
Hey, it's clear that you've got a lot of experience with this and related tools. But discussion on HN requires comments to be more substantive than this comment (not to mention "csound is trash", which was correctly flagged upthread). Since you know more than others, please make sure that each of your posts shares some of what you know, so that the rest of us can learn. If a comment only contains putdowns and no solid information, please edit it to take out the putdowns and add solid information; or delete it; or simply don't post it to begin with.
I suppose I should say the language itself is hindered by the horrible GUI application it runs in, the interface is ancient and dated, and the application crashed constantly on Mac. I took a class that that required the use of CSound, so I haven't explored the various options
the gui is pretty useful though because it allow you to look up help for statements in your code. this is necessary to do anything because everything is completely unintuitive and nonsensical, so you constantly need to be racing through the docs to make anything interesting
This is 20 years ago, but I always wrote scripts in perl to generate the orc and sco and then generate the audio. I remember it being petty fun. Maybe it's gotten more complex since then. Lots of things were more fun twenty years ago, or maybe it's just declining executive function.
I honestly find it way way easier to do FFTW manually in C and then convert the output with ffmpeg then use supercollider, like by a significant number of orders of magnitude.
I've given sc 5 years, usually I'll try to use it, give it a few days of effort to do what I want, then give up, rewrite what I want in C, and be done with it in an hour
Some people love it. More power to them. I wish I was one of them
This is exactly my experience with both sc and Csound. (And Max too, for different reasons.)
Csound is based on a synthesis paradigm that dates back to the very first computer music experiments. It started life as a microcomputer implementation of Music 11, which was based on Music IV, which dates back to the 60s - and it hasn't moved on from there.
Meanwhile sc is a masterpiece of software development - a smooth and clever integration of a custom DSL with distributed real-time synthesis.
But musically it's damn near impossible to get it to sound as nice as a mediocre VST, never mind a good one, and the sequencing and event management are eccentric at best.
Essentially these systems are all opinionated frameworks with a huge conceptual overhead. They're supposed to make music-from-DSP easier to learn, but students have to learn DSP and a completely new and unusual programming language at the same time. And that's too much to expect of most people, even for A-grade students with PhD potential.
So they tend to be used for tinkering and for academic music projects. It's not quite true that no worthwhile music has ever been made with these systems, but it's not an exaggeration to say that very little has. And when you include the learning curve, the ratio of time spent to creative benefit is unimpressive.
You make some good points...sonically, out of all the visual node-based and text-based audio DSP environments, only Native Instruments' Reaktor has a reputation for DSP sound quality rivaling commercial software instruments/effects. Worth noting that Reaktor is itself a commercial AU/VST/standalone instrument/effect.
As a resident of both Davis and Berkeley, CA I've heard a lot of stiff academic music made in Max/MSP on UC campuses, though I'd say UC Davis' Bob Ostertag is the notable exception - really compelling stuff - but that's because he's using at as an expressive musical instrument.
But still, these environments hopefully provide a DSL/interace that abstracts away some of the complexity of bare-metal C or C++ code; and non-PhDs like Autechre, Squarepusher, Aphex Twin, BT, Leafcutter John and Christopher Willits have made great-sounding things with them. And these tools are often used by professional audio developers to quickly prototype DSP algorithms.
By now, one of the West Coast biggies, actually, make that international, he’s at the level where he’s thought of as one of the masters, though he is very mild-mannered and modest. In the 70s he formed League of Automatic Music Composers, one of the first computer music network bands, along with Jim Horton, Rich Gold, Tim Perkis. They would use Kim computers and plenty of homemade code and software (and get roasted in the newspapers by the critics especially during New Music America 1981, they were mocked unmercifully, but water off a duck’s back). Who’s laughing now, eh? [November 1988, dur. 11:24]
Probably one of the most famous of all our EA people, who successfully bridged the gap between the avant-garde and the “in the know” mainstream.” Even in the early 80s she packed the Mills College Concert Hall, with her violin, millions of “toys” including vibrators, plenty of digital delay and thrilled us all. A sidebar: when I was interviewing Laurie at The Phoenix Motel in San Francisco, a guy came into the room, she told him to introduce himself to Barbara, and he extended his hand and said: “Hello, I am Wim Wenders”… [17 February 1990, dur. 29:00]
I believe digital tools are scoped like analog ones are - they are appropriate for certain types of projects.
In the same way it would be extremely hard to do say, a convincing rendition of the waldstein sonata on say, a drum kit, the digital tools are great if you want to do what they're designed to do.
This is why some people love one piece of software and hate another in some apparently random distribution, music is a huge tent and these people likely have dramatically different goals. It's like a kosher, a vegan, and a keto arguing over the best restaurant...
The problem is trying to figure out whether it's the wrong tool or whether you just haven't spent enough time learning how to use it.
Max/MSP struck me like a very opinionated and schizophrenic elderly camel, who's been across the desert many times: it's wonderful and indispensable in certain situations, but it will get mad and spit on you if you don't treat it right, and it's butt-ugly, and some Max programmers have a way of cultivating and celebrating that butt-uglyness. (See any of AntiOrp's Nato.0+55+3d code!)
Max has got layers and layers of experience built up over the decades, but no one clear model or consistent way of doing things. It's got so many different opinions, or programming paradigms, that aren't necessarily consistent with each other and don't fit together well. Some people love it, because it happens to have the combination of programming paradigms that they like. But when you're starting out, it's hard to figure out the best way to do anything, because there are so many different competing ways. In that sense, it's extremely un-Pythonic, like visual Perl.
Here's a video that shows some great examples of Max/Nato code. Remember, this was before Cycling '74 created Jitter (which pissed off AntiOrp who considered it a rip-off of Nato). Nato supported many features of QuickTime, including reading and writing live RTP video streams over the network. So Nato "operators" would exchange live QuickTime RTP video streams back and forth over the network (both LAN and Internet) and jam together in live distributed performances, sending the video from one Mac to the other, near and far, mutating and remixing and layering in live video each hop, projecting it on screens, and feeding it back and forth between different "operators" who were writing and editing the code in real time.
>Nato.0+55+3d (released in 1999) was an amazing but notorious extension for Max that enabled live programming of real time video manipulation, networking and display.
https://en.wikipedia.org/wiki/Nato.0%2B55%2B3d
>"At the time of its release (the summer of 1999), NATO.0+55+3d was in demand as it appeared several years before other similar infrastructures such as GEM and Jitter (released by the makers of Max/MSP in October 2002). Earlier software such as Image/ine developed in 1997 at STEIM was drawing in a similar direction, but the fact that NATO.0+55+3d was operating inside the Max/MSP framework, using its "visual programming" protocol, provided at the same time greater ease of use and more flexibility, allowing the user to create his own applications and tools. It gained popularity among video artists and performers, who were using it for a large variety of purposes, prominently for live performance and interactive installation."
>Bravo! If you enjoyed that anti-Max performance art trolling, but thought it wasn't spectacularly hyperbolic and sociopathic enough, I recommend looking up some of the classic flames on the nettime mailing list by Netochka Nezvanova aka "NN" aka "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp"!
https://en.wikipedia.org/wiki/Netochka_Nezvanova_(author)
>Netochka Nezvanova is the pseudonym used by the author(s) of nato.0+55+3d, a real-time, modular, video and multi-media processing environment. Alternate aliases include "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp". The name itself is adopted from the main character of Fyodor Dostoyevsky's first novel Netochka Nezvanova (1849) and translates as "nameless nobody."
>She (or he or they or it) were the author of the NATO.0+55+3d set of extensions for Max, which predated Jitter:
>Netochka Nezvanova is a software programmer, radical artist and online troublemaker. But is she for real?
>The name Netochka Nezvanova is a pseudonym borrowed from the main character of Fyodor Dostoevski’s first novel; it translates loosely as “nameless nobody.” Her fans, her critics, her customers and her victims alike refer to her as a “being” or an “entity.” The rumors and speculation about her range all over the map. Is she one person with multiple identities? A female New Zealander artist, a male Icelander musician or an Eastern European collective conspiracy? The mystery only propagates her legend.
Cramer, Florian. (2005) "Software dystopia: Netochka Nezvanova - Code as cult" in Words Made Flesh: Code, Culture, Imagination, Chapter 4, Automatisms and Their Constraints. Rotterdam: Piet Zwart Institute.
I found some great links (which I've archive.orgified) on Jeremy Bornstein's page on Nato:
Here is some of the delightfully stylized "documentation" of some interesting NATO extensions, written with Netochka Nezvanova's poetic simply.SUPERIOR Eastern European Marxist Feminist Punk Hacker ASCII Art Razzle Dazzle.
242.wto + 242.wto2 - feu!lez de mdl c!t!zn malad!e
242.wto + 242.wto2 - nato.0+55.modular objekts
realtime video streaming 4rom nato.0+55 2 nato.0+55
i.e. 01 wto global video processing network.
performance dependent on internet konekzie.
"have tested via ethernet from g4 > g3.
full framerate, no visible delays.
video codec works best here.
320x240 codecq 3 using video
is my choice at the mom.
runs stable since three hours" - fm life 4rm.
- 242.parazit: a plug-in host for Image/ine plug-ins
242.parazit - a nato.0+55 plug-in host for steim image\ine plug-ins
image\ine plug-ins are lovelier in nato.0+55 modular due 2 :
one may operate them in parallel or sequentially as desired
+ one may instantiate as many kopies as desired
+ due 2 fakt nato.0+55 is much more flexible regarding image resolution
measures have been taken so that the image\ine plug-ins
operate in one similar fashion - hence it is not required
that one restarts the host application in order to modify the output resolution.
+ naturally one may now kontrol image\ine plug-ins via innumerable max routines.
nato.0+55 - is of course the most superb realtime.non.realtime.
m9ndfszp video \ image etcetera etcetera distraktiv kode kontainer.
juzt 1 kl!k - http://membank.org/ juzt ur kl!k
- 242.fireuire: several FireWire objects, which permit NATO to send various data (image & effects data, DV data, MSP audio data) through your FireWire port
- N 4 � �.firewire : beauty has its reasons.
N 4 � �.firewire is a multi klient \ multi application firewire extension.
permitting multiple applications and klients to simultaneously engage in
video + audio firewire aktivity.
klients exist for nato.0+55.modular. image\ine. msp.
- 242.o204: an internet data transfer (download/upload) object
242.0+204 - max c++\c-- objekt primarily konstrukted for utilization
with nato.0+55. if desired it may be utilized independently as well.
242.0+204 performs http \ https \ ftp file transfers -
automatic compression and decompression [stuffit engine required]
of data transferred = feasible. operations may be sequential. logged.
synchronous + asynchronous
nato.0+55 + 242.0+204 locked in one digital embrace
may be utilized for timed video and audio data capture + automatik \ programmatik
upload of mute+media kapzulz to an internet ftp location. - furdzr unatendd
populaz!on=poluz!on ov dze !nternaz!onl b!t ztream = !nev!tabl + !mperat!v
4 an example - may konsum [>]
242.axial - ultra superb avec nato.0+55 modular + non-modular
242.axial - 01 morphology ov 01 direktory zmak routine
ultra elegant _ recursive + infinite search engine
index the stem + branch into the axial system of a directory strukt.
nato.0+55 operators may access + only _ juzt 1 klik [>]
- 242.of02: a realtime, recursive multi-layer photoshop file to qt movie converter
242.0+f02 - max c++\c-- objekt primarily konstrukted for utilization
with nato.0+55. if desired it may be utilized independently as + well.
242.0+f02 performs the conversion of multi image or multi layer files - photoshop. tiff. flashpix
to single track quicktime films. multiple track quicktime films or multiple quicktime films.
the film outputted may be sequential - the image files are placed in one track sequentially
the film outputted may be parallel - the image files are placed in separate film tracks starting at time 0
the film outputted may be parallel and sequential - [m9ndfukc.macht.fre!.n!chtz+?]
the image files are placed in separate film tracks starting at sequential times.
the film outputted may be autonomous films - plural
the image files are placed in separate films entirely.
obl!ke.0+0000 - max c++\c-- objekt . facilitates previewing of aiff\sd2\film files
for auto-loading into the buffer~ and sfplay~ msp objekts + movie + nato.0+55
max objektz + etc. it may also be utilized as a file path aggregator \ accumulator for
convenient access to previously specified \ selected files - and if desired for
converting formats - such as cd audio for subsequent automatik loading into objekts
enumerated.
please insert addtl ko!nsz +? [>]
NATO.0+55.GL - brings OpenGL rendering to NATO.0+55 in 01 superb. ultra sanitary fashion.
NATO.0+55.GL - is totally + totally integrated within NATO.0+55
NATO.0+55.is a realtime + modular authoring environment
comprised of approx 130 objekts [1.22.01] encompassing QT, QTVR,
2D + 3D GRAPHIKS, LIVE-VIDEO, FIREWIRE, VIDEO-STREAMING, FLASH, MP3. QTFX etc.
NATO.0+55.GL facilitates
realtime 3d model specification. manipulation. texture mapping. lighting. fog. etc.
Unlike the ultra rigid + centralized 1 track korporat monstrosities sponsored by INTEL
\+\ populated by aesthetically + biologically destitute xy computer programmers
avec 0+0 imagination and 0+100 percent model citizen predilections -
NATO.0+55.GL is kompletely modular + infinitely flexible.
NATO.0+55.GL permits an infinite number of render sequences.
NATO.0+55.GL permits an infinite number of render sequences.
NO treatments. No columns. No windows.
NO inhibitors. NO prolonged inkubations.
NO korporat translations.
PURIFIKATION>
- NATO.0+55.QTFX : realtime quicktime effects processing within NATO.0+55 [>]
in 01 superb. ultra sanitary + flexible fashion.
one may process video + 3d + 2d data via std quicktime effects + 3rd party effects
in realtime + non-realtime - as desired. operation = ultra sanitary + flexible evidament.
one may process video + 3d + 2d data via std quicktime transitions + 3rd party transitions
in realtime + non-realtime - as desired. operation = ultra sanitary + flexible evidament.
2 versions = may be selekted - standard + ultralux. ultralux permits the compilation of standalone applications
for non-commercial or commercial [during the korporat fascist (r)evolution life forms are presently experiencing
in which 01 googolplex of iszkrema flavorz are ultra available everything = ist pure komersz - inkluziv of +
not limited to one's simply genial m9nd kontainer [>] whilst the standard version does not.
one may selekt as one's status permits _____... body without borders [want zom +?]
si vouz voulez ____...
just 1 klik \ ur klik _ http://order.immunology.com/>YES PLEASE+?
242.nr+ - nato.0+55 objekts facilitate realtime \ non-realtime rendering \ processing.
generally nato.0+55 attempts to operate in realtime. depending on the underlying hardware
this may restrict the type and \ or number of processes that may be performed.
the realtime \ non-realtime objekts may be utilized to rekord data in non-realtime
thus facilitating high quality rendering and \ or processor intensive tasks.
likewise 242.nr+ permits operations unfeasible in any other environment.
i.e. one may render a film in reverse \ randomly \ stochastically \ programmatically.
e.g. one may specify that only every other frame is to be rendered or that every 10 frames
a loop should be applied. or that only those frames that fit a certain criteria should
be rendered. in other words NATO.0+55 renders korporat fascist kode null + ultra null
in 01 ultra sanitary \ elegant + ekxpedient fashion.
komentari
"the non-realtime objects prove that there is truly
nothing you can't do with nato.0+55 -- now i can
work in high resolution with full-frame rate results.
it truly renders all other `nonlinear` editing applications
ultra null"
"ultra lovely :-) "
- 242.rna: NATO to MSP sound manager driver and associated software.
NATO.0+55.RNA : beauty has its reasons.
NATO.0+55.RNA is a multi klient \ multi application audio library \ patchbay
permitting multiple applications + klients to simultaneously engage in ___...
unilateral global.OS vociferous akkords. da + ultra da.
klik 2 m9ndfukc [>] klik if u do not own nato.0+55 [>]
it is the ultra.inauguration of multi.format multi.klient FREE global.OS konverzazie.
+ some 01 in ost europa kontrols the protokol [>]
NATO kontra NN +? nn u!zprz - uarm.kompaz!onat.zm!le okz!dent kr!!!!ket.
klients exist for nato.0+55.modular. msp.
NATO.0+55.RNA : 01 addtl simply.SUPERIOR + ultra mortal projekt by Netochka Nezvanova.
implemented by ___... mmmmmm _
`must play a game of mother` - i smell baby powder!!!
_____.... nn cannot play mother!!! nn can play mistress +? da + ultra da.
apropos. most of your children [ne. make that all]
arnt very attractive. they must not be yours a +?
bon. let us play - delicious kouard. firstly however - letz konfuze dzm [>]
Could you say more about how you work? I know C (very well) and the principles of synthesis (very well), but I'm trying to get my head around the idea that you find it easier to . . . implement your own DSP algorithms from the ground up than using tools like sc?
It took me many years to learn how to get the "sound in my head" programmed into a synthesizer. You do this with the fast fourier transform? Huh?
I'm not trying to burn anyone. The people who make the project really care about it and have put a lot of effort in it. I personally am just too stupid to figure it out.
I think like Haskell and R it's designed for a different profession so to people like me who are programmers first I am scratching my head the whole time. I can do some thing in it, yeah eventually, usually...
The documentation appears complete and I'm sure the compilers are well written, an enormous amount of effort went into it, it's just a problem with me here.
Do you have any recommendations for learning sound synthesis and such (for the purpose of music production) for those who are, as you say, programmers first? Most the materials I’ve found teach using Csound, PD, SC etc (understandably), and that’s always a bit off-putting to me and appears as another obstacle / headache, so the projects get shelfed more quickly. I’ve begun reading Miller Puckett’s book Theory and Technique of Electronic Music and quite like that, though, despite strongly disliking the PD interface.
The fundamentals of sound synthesis are things like oscillators, delays, filters etc as you see in Miller Puckett's book, and teaching materials tend to lean towards environments like Csound, pd, SC etc for their practical exercises because they all contain roughly equivalent implementations of those fundamental tools, albeit wrapped in some uniquely opinionated structural or UI paradigm, in each of those environments.
If you think as a programmer you might be happier around low-level things, take a look at Soundpipe, which contains those same fundamental elements again - often with the same or similar names to their equivalents in the above programs - but in plain C code.
For something a little more 'live' and high-level built on that library by the same author, check out Sporth, or another guy's browser-based embedding of it called AudioMasher - which has some very nice examples.
Chuck [1] is what clicked for me, as it is C/Java-like with the DSP basics built-in.
Im biased here however as I eventually became one of its developers.
Its easy to get started although unfortunately also easy to outgrow :)
SonicPi/Overtone or Gibber are also nice also as they are based off of existing languages.
I recommend Musical Signal Processing by Curtis Roads (latest edition), it mostly cover every type of sound synthesis in details, it also cover MIDI, spatialization, mixing, filtering and base concepts without much technical / mathematical overhead. Most sound synthesis algorithms can be implemented from the given block diagrams when you get used to read them.
Thank you for the recommendation, Curtis Roads seems to be quite the synthey-book legend. I read portions of Computer Music, but your title seems much more relevant to precisely the subset of info I'm after.
You can make midi interfaces in Python and plugins in LADSPA and other things with Jack ... lots of programs are fairly extensible these days.
so for instance, instead of a physical instrument connected to a usb port, your software is feeding the midi input into some other software, say something simple like seq42 (https://github.com/Stazed/seq42)
Synthesizers have some interesting things too. https://zynaddsubfx.sourceforge.io/ uses an XML format for its synthesis definition. It also has "learnable midi" as in parts of the interface can be instrumented from a midi controller - so you turn a knob in physical space and it turns in the software accordingly.
So let's go back to the previous part, the part about software defined midi. You can now emit the mutation of the sound and the sound itself into software like that. Here's a 2005 linux journal article with a screen shot (https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...) essentially the stack I just said. https://www.linuxjournal.com/article/8304 ... "2005" you say? yeah, old pianos also still work.
The linux space is littered with generic audio tools that don't really work on their own and must be pasted together with other tools in order to get anywhere, much like in the shell. I did a bit of editing on the linux audio wiki about 3 years ago, it's probably the best place to look: https://wiki.linuxaudio.org/wiki/introduction
It's still just a bunch of hacks on top of hacks. Things break all over the place and latency is a bitch ... I dunno, there's a lot out there.
You're getting downvoted and flagged became you're violating site guidelines, and it kinda looks like you've made two throwaway accounts to do so.
You like supercollider. That's fine but it doesn't make csound "trash." You want a gui. That's fine, but csound users like myself and others here prefer a solid scripting environment.
Thanks. As a rule on HN, everyone should act like the author of what they're thinking of trashing is reading through the comments and will take your comments about their hard work in open source to heart, this happens more than you think.
If you wouldn't say it to the author, don't say it here, because it's often the same thing
That's particularly true because HN threads usually have high search ranking. Anyone personally connected to a theme can easily get directed to an HN thread on that topic. That includes authors and project creators. It also includes family members of people being discussed.
There was a horrible case yesterday where someone died and the thread filled up with generic dross. People weren't being malicious. It's just what happens when internet commenters aren't familiar with the specifics of a topic (more about that at https://news.ycombinator.com/item?id=22027453). But we ended up getting an anguished email from someone close to the person who had just died.
This is a systemic problem and I wish we knew what to do about it.
Hi, maybe this is offtopic, but I felt this way when anime studio KyoAni was arsoned and many of its employees died in a horrific way, and the news got to the front page of HN: https://news.ycombinator.com/item?id=20468395
Even though the people there weren't necessarily violating the site guidelines per se, the commentary that some people were making (e.g. discussion about IP stemming from the murderer's unsubstantiated accusation of plagiarism, or discussion about Japan's culture) felt insensitive and hurt me as someone who was greatly impacted by KyoAni's work. I didn't understand how to express my feelings about this, but the way you describe it ("generic dross") explains it perfectly.
Max & Pd are fantastic for incorporating sensors & other physical interfaces, real-time interactivity, routing signals, creating visualizations, & all that. Supercollider is fantastic for generative music & using control flow compositionally.
Csound, on the other hand, is really, really great for creating beautiful & nuanced electronic compositions. The sound quality is unrivaled (emphasis on accuracy over interactivity), the interface is great (plain text, which, as a programmer, I prefer), and GEN routines plus the myriad opcodes allow you to do some heavy, intricate aural spelunking.
As a bonus (& as mentioned by others), it’s highly performant & fairly easy to integrate with other languages & environments (including Max & Pd!).
The syntax is a bit strange, but once you get over that, Csound is an amazing piece of software.
wondering if you have any favorites that you can recommend.
Really beautiful album, especially the 5.1 surround version.
http://simoncpage.co.uk/blog/2008/10/bt-this-binary-universe...
And dear lord do some people understand synths.
It might give you a feel for how you can create compositions that sound very remote from what most people would think of as musical. The whole piece is synthesized sound with "instruments" consisting of various types of signal generators composed together.
- It was very complicated to wrap a C library in Java, at least for a new graduate like me.
- There was no learning material for the kind of things I needed to do (manipulating wav files). learing CSound at the time was a mess - no blog posts in 2010.
- If I read the CSound source file I wrote in 2010 I'm sure I would not understand a single line.
Some years later, when Coursera was just starting to offer free courses to the world, I encountered another musical programming language called ChucK (https://chuck.cs.princeton.edu/). The course was very well done and ChucK too, was so simple that I almost decided to rewrite the whole project with it. I wrote some very nice pieces of music while studying ChucK.
Good luck to all the musicians out there!
http://write.flossmanuals.net/csound/a-the-csound-api/
The cool thing about SWIG (Scripting Wrapper and Interface Generator) is that it supports multiple scripting languages (and other kinds of languages, since it's debatable if Java is a "scripting language"). It understands most of C++, so it can automatically read in header files and generate wrappers from them, but you can also tailor and customize the interfaces and how it marshals different data types back and forth, to create more efficient, convenient wrappers, too.
http://www.swig.org/
SWIG is the brainchild of David Beazley, Python hacker extraordinaire. His talks are amazing!
https://www.dabeaz.com/talks.html
https://en.wikipedia.org/wiki/David_M._Beazley
>David Beazley is an American software engineer. He has made significant contributions to the Python developer community, which includes writing the definitive Python reference text Python Essential Reference, the SWIG software tool for creating language agnostic C and C++ extensions, and the PLY parsing tool. He has served on the program committees for PyCon and the O'Reilly Open Source Convention, and was elected a fellow of the Python Software Foundation in 2002.
A project about playing back recorded audio with interactive control should be feasible in Java, dispensing with CSound and JNI complications entirely, while a project to do something with CSound could focus on the strong points of CSound and avoid technical hurdles (e.g. Java programs that generate highly complex CSound code for highly complex music).
I was involved with the Oxford Laptop Orchestra in 2012, and did a few "programming for musicians" lessons in ChucK. Writeups here:
https://blog.afandian.com/tags/oxlork/
This made in C sound? I have no words.
https://chuck.cs.princeton.edu/
I appreciate that the title of this post calls it a "sound and music computing system" rather than a "musical programming language". In truth, Csound is more of a text-based modular synthesis environment than a programming language.
As others have said, the orchestra syntax is a bit strange at first, but you do get used to it. Writing Csound code feels more like patching a modular synthesizer rather than writing a computer program. It's basically a DSL for connecting small sound/signal modules (called opcodes) together. Most of the time one thinks about things in terms of signal flow and not computer logic. A common mistake I see new Csounders make is to immediately reach for the conditional statements and loops. They often don't behave the way you expect, so people get frustrated.
The Csound dev team has a very strong emphasis on backwards compatibility, to the point where the older opcodes do not get bugfixes in case someone is exploiting the bug in the compositions. The programmer in me groans a little bit, but the composer takes great comfort in the fact that pieces I write now will be playable for many years or even decades (some of the Csound test pieces, like Trapped In Convert by Richard Boulanger or Xanadu by Joeseph Kung, are over 30 years old and still run).
I've been told that many works written in MusicN languages (a precursor to Csound) have been ported to run in Csound, which means that the legacy of Csound includes computer music written in the 60s! I wish I knew where to find those, as I quite enjoy computer music history.
I agree with this point. I am using Csound for creating VST plugins (with Cabbage framework[1]) for which is Csound extremely productive. I can have working prototype (which I can actually play on my keyboard) ready in something like 15 minutes.
Once you get over somewhat strange syntax[2] and understand difference between k-time and i-time[3] you can do any DSP processing without actually diving into hard math.
Cabbage has nice beginner documentation on Csound[4].
[1]: https://cabbageaudio.com/
[2]: output operand, paramA, paramB
[3]: k-time - on every step of audio processing, i-time - on initialization of instrument/note
[4]: https://cabbageaudio.com/docs/file_structure_and_syntax/
I love Csound, but it has been very challenging to learn. The first two or three months were an uphill battle where I thought about quitting a few times. Admittedly, I was brand new to both computer programming and digital audio generation. I’m sure if I had more experience with those then picking up Csound wouldn’t have been as painful. The biggest early challenge for me was understanding how the three variable rates (initialization rate, control rate, and audio rate) work. I felt like I had to hit my head against a wall for three weeks before that clicked. But once you become familiar with the basic principles and syntax of Csound you start picking up other topics and opcodes quicker.
I’ve used both CsoundQt and Cabbage as Csound development environments. They each have their pros and cons and best use cases. I’ve been using Cabbage more because it has an ingenious way of controlling the instrument interface within the Csound code itself.
There are a ton of opcodes available to do many sound design techniques out of the box, or you can code your own opcodes to do anything you’d like. The user community is very responsive and helpful on the Csound listserv (http://csound.1045644.n5.nabble.com/). And the developers have made it so you can integrate Csound with all sorts of other languages and software.
Does anyone use Csound for Live? It's no longer working since the Ableton 10.1 update and the Developers do not respond to emails. Incredible set of audio tools.
https://csoundforlive.com/
Anyone managed to fix in Max/Cabbage for Live 10.1/Max 8.1?
I remember trying to install Tidal Cycles a few years back and having some difficulty - IIRC it's a library that requires other components/config. Same for Overtone [1] (Clojure frontend to SuperCollider), it took a bit of time to configure Leinengen at first.
Cabbage [2] interface to CSound would probably be closest to Sonic Pi, rather than straight CSound iteself.
Also worth investigating is Pyo [3] - a Python interface to DSP code written in C.
So many interesting (and free) choices - it really just comes down to your language preference. I make a lot of music in DAWs like Ableton Live & Apple Logic, but I have some fairly original, very specific ideas around exploring pitch, rhythm & harmony that a text-based language is better suited for.
[1] https://github.com/overtone/overtone
[2] https://cabbageaudio.com/
[3] http://ajaxsoundstudio.com/software/pyo/
http://csounds.com/
http://csounds.com/cascone/
"One of the motives for being an artist is to recreate a condition where you're actually out of your depth, where you're uncertain, no longer controlling yourself, yet you're generating something, like surfing as opposed to digging a tunnel. Tunnel-digging activity is necessary, but what artists like, if they still like what they're doing, is the surfing" — Brian Eno (Aurora Musicalis. ArtForum Magazine. 24:10. 1986)
These hint at some neat possibilities but I still don't get it:
a sound and music computing system
a tool for composing electro-acoustic pieces
real-time
What makes it different from popular music tools is that you are in control of the instruments' guts, and can create custom instruments, so you can apply virtually any form of synthesis, any type of audio transformation or generation, you can imagine. This makes it ideal for experimenting with synthesis and algorithmic composition.
"Electro-acoustic" is an academic term that encompasses various forms of experimental music and research involving artificial sound sources, including electronic music, electric instruments, tape loops and manipulation, computer-generated music, and so forth. Roughly: "any avant-garde music that requires loudspeakers to perform." You can of course use Csound for more popular music applications as well, but you would typically find traditional DAW tools to be more convenient in those cases.
[0] http://www.csounds.com/manual/html/PitchTop.html
[1] http://jacobjoaquin.github.io/csd/pysco.html
[2] http://write.flossmanuals.net/csound/methods-of-writing-csou...
[3] https://csound.com/frontends.html
EDIT: remove some repetition
[0] https://supercollider.github.io/
CSound is a grab-bag of mediocre DSP algos hacked together from various sources by academics who have no interest in professional production values.
While you can build your own synths with Csound, they don't usually sound very good.
Games are actually more likely to use PDLib, although there's also a lot of custom C++ in some games.
There's a significant difference in sophistication between the crude algos in Csound and the algos in successful commercial VSTs like Serum, Uhe's synths, the Roland Cloud collection, SoftTube, UAD, and FabFilter mixing tools, and so on.
I don't know about "crude," but yeah. And honestly? There is no comparison between the components in Max/Pd/sc/ChuCK and any of this stuff either (I joke with my art-music friends that I like everything about Max except the sound ;). You'll never hear something like Cytomic's The Drop (a filter that can crush your CPU) or serious tape saturation, or sophisticated EQ curves with lots of warmth and character.
It's true that you could create any kind of filter, oscillator, DSP-whatever you want with these systems, but in practice, the people working with these tools are not U-he-level DSP programmers, and it shows.
I wish that weren't true, because I'd much rather code stuff csound-style than work in a DAW with a bunch of expensive plugins.
But is it true that you can run VSTs in csound? Could you use commercial VSTs, but write fancy controllers in csound?
"One of the main principles in Csound development is to guarantee backwards compatibility. You can still render a Csound source file from 1986 on the latest Csound release, and you should be able to render a file written today with the latest Csound in 2036."
I wish more "modern" languages and frameworks put in the effort on this point as well.
A proprietary but much more approachable and functional offshoot is Max/MSP.
The visual dataflow style is especially good for interactive stuff, where you're taking inputs and running them through chains of synths and filters, but it gets really hairy if you want to do non-interactive composition. People use it for that too, but you end up with huge banks of delay lines to simulate control-flow constructs, which in other languages could've just been a for loop.
I'm not sure what you're referring to. Pd has a whole category of control objects for routing arbitrary message data. This includes branching and looping in zero logical time.
I think Csound didn't have a real time mode back then. Many things have improved since then.
Regardless, many people do take to it and do amazing things with it and all these music systems extend the learnings from earlier systems.
REAPER is probably the most-scriptable DAW of all, with an API using EEL, Lua, and/or Python. [4]
[1] https://www.kvraudio.com/forum/viewforum.php?f=268
[2] https://www.bitwig.com/en/community/learning/grid-lets-build
[3] https://julienbayle.studio/PythonLiveAPI_documentation/Live1...
[4] https://www.reaper.fm/sdk/reascript/reascripthelp.html
Then he later developed the open source Pure Data (PD) in the 90's, which also included real time signal processing features (flowing streams of high frequency audio over wires whose samples are at a much higher rate than the frame rate of the visual program's control signals).
Max/MSP and PS are both visual data flow programming languages, where data flows along wires between icons, but some data (like audio stream samples) flow much faster than others (like messages, logic, and control signals).
Cycling '74 Max later adapted Puckette's work on Pure Data and called it "Max/MSP", which stands for both "Max Signal Processing" and his initial "Miller Smith Puckette".
https://en.wikipedia.org/wiki/Miller_Puckette
https://en.wikipedia.org/wiki/IRCAM
https://en.wikipedia.org/wiki/Pure_Data
https://en.wikipedia.org/wiki/Max_(software)
>Max is named after composer Max Mathews, and can be considered a descendant of his MUSIC language, though its graphical nature disguises that fact. Like most MUSIC-N languages, Max distinguishes between two levels of time: that of an event scheduler, and that of the DSP (this corresponds to the distinction between k-rate and a-rate processes in Csound, and control rate vs. audio rate in SuperCollider).
Pd's "control" classes are probably confusing to programmers coming from other computer music environments. There's no control rate in Pd.
The "control" classes (the ones without a tilde at the end of their name) send messages in zero logical time and may be triggered sporadically. Building diagrams out of them is like building an immediate-mode Rube Goldberg machine.
There are some conversion classes that allow control <-> signal object communication. Some of the control-to-signal classes do conversion at what you could call "control rate"-- e.g., they might compute a single value and copy it to the rest of the samples for output. Others do sub-sample accuracy bounded by the precision of floats (single or double as Pd can be compiled to use either).
If you're weird you can use [bang~] to emulate a control rate diagram-- it will literally output the "bang" message at each block which you can then feed to a downstream Rube Goldberg machine in order to do arbitrary message passing each block. But that's less ergonomic than just using signal objects which a) all send the same type of vector data and b) get automatically ordered by the graph builder and are therefore easier to read. (The irony being that signal diagrams generally deal with DSP, so the readable part of the diagram is the most conceptually complex and the simple stuff like branching or counting to 10 tends to end up looking like a plate of spaghetti.)
There's also overhead in the control message dispatch which would probably undo any imagined efficiency gains. Signal diagrams on the other hand get sorted into an array of function callbacks (as needed during runtime or editing time), so there's no chasing of pointers or type-checking to eat up cycles.
Opening someone else's sketch and playing around with the different components has been a great way for me to learn some of the more advanced features.
If you end up using it and making something cool, please share!
https://en.wikipedia.org/wiki/Csound#One_Laptop_per_Child_(O...
>Csound5 was chosen to be the audio/music development system for the OLPC project on the XO-1 Laptop platform.
http://wiki.laptop.org/go/Csound
Csound is the music and audio signal processing language originally developed by MIT's Barry Vercoe and now expanded and maintained by a world-wide community, as Free Software. Csound will provide audio services for the XO computer. Csound is both a programming language and a sound synthesis engine. Csound, as included in the OLPC project, can be used by Activities or directly by children and teachers. It can be accessed in a variety of ways. In the XO platform, two basic ways are provided:
Through the Python programming environment: eg. programmed in Activities.
Through its 'classic' command-line frontend, directly invoking it from the Terminal activity.
Further information about Csound can be found on its official website: http://csounds.com/. The canonical Csound sources and multi-platform binaries are hosted by Sourceforge.
Activities
Csound Editor - view, edit and perform Csound files
http://wiki.laptop.org/go/Csound:Csound_Editor
Audio Loop Remixer - perform audio loops and apply a variety of effects
http://wiki.laptop.org/go/Csound:Audio_Loop_Remixer
MIDI File Player - performs MIDI files using the donated General MIDI soundfont
http://wiki.laptop.org/go/Csound:MIDI_File_Player
Instrument Player - a keyboard interface to play a variety of instruments
http://wiki.laptop.org/go/Csound:Instrument_Player
TamTam - Tam Tam uses Csound, but you would never know it as its interface is designed to wrap the Csound engine with a child-friendly look and feel. This excellent group of Activities allows kids to make sounds, make music, jam, record and transform their voices in an intuitive way. TamTam Edit allows students to patch together Csound's opcodes (modules) and teaches them all about signals, synthesis, and synthesizers. TamTam Activities demonstrate well how the power of Csound can be harnessed in the XO platform.
http://wiki.laptop.org/go/TamTam
GregCsoundActivities.zip - A number of Csound Server-based activities developed by Greg for Build 542 including a pretty cool Pitch-Tracker Bouncing Ball Activity and a Pitch Reverse Game – both lot's of fun for kids, but not currently supported by the latest builds and security models.
http://csounds.com/GregCsoundActivities.zip
Pippy - Pippy uses Csound to help teach children the Python programming language and to build XO Activities.
http://wiki.laptop.org/go/Pippy
Step - A simple 8-note step sequencer that children will use to play music and record their own loops for use in other sample-based activities. Step uses csndsugui.
http://www.thumbuki.com/xo/step.activity.zip
Funny Talk - An activity that children can use to record their voices with the built-in microphone, and process them with effects such as reverb, echo, chorus, etc. Funny Talk allows a child to save their manipulated voices as soundfiles so that they can be used in other musical activities. Funny Talk uses csndsugui.
http://wiki.laptop.org/go/Csound:Funny_Talk
http://wiki.laptop.org/go/Csound_tutorials
http://wiki.laptop.org/go/Csound_TOOTS
https://www.donhopkins.com/home/archive/visual-programming/b...
That link also includes some interesting discussion with Jaron Lanier about visual programming language design.
Image/ine was a software instrument for realtime video manipulation and MIDI processing from STEIM (Studio for Electro-Instrumental Music) in Amsterdam, by Steina Vasulka and Tom Demeyer (1996-2001). It ran on a Mac, and you could write plug-ins for it.
https://steim.org/
https://en.wikipedia.org/wiki/STEIM
https://v2.nl/archive/works/image-ine
Hookup is a real time visual programming language for controlling MIDI and playing music and rendering graphics, developed by David Levitt (who shared an office with Miller Puckette at MIT), which also incorporated the Macromedia Director MMP player plug-in (so it could read in Director files and play their content under visual program control).
http://www.sdela.dds.nl/sfd/isadora.html
>Mark Coniglio: Here's a bit of history. In 1986 my soon-to-be mentor and Interactor collaborator Mort Subotnick had just come from a residency at MIT where he was using a program called Hookup created by a student there named David Levitt. Hookup was the first program I know of that used the "patch-cord" metaphor, i.e., modules that manipulate data are linked by virtual wires, the connection of which is determined by the user. For those in the world of early analog, patch-cord programmed synthesizers, this was a familiar interface. Mort was using David's program to do tempo following of MIDI instruments -- this allowed him to lock hardware MIDI sequences to the tempo of the live performers. I was a composition student at CalArts at the time, and word had gotten around that I was a good programmer. So Mort contacted me to see if I could hardcode some of the ideas he had implemented in Hookup on a Mac, so that he could use them in his next performance. That program (used in Mort's 1987 multimedia work "Hungers") would eventually become Interactor. Mort designed the functionality of the early versions, but I became more influential in the design as time went on. [...]
>Mark: Yes, that's true and importantly a kind of creative intuition was creeping back in through the development of these new visual interface possibilities for software. Part of the thing I reacted to in Hookup was the way you could easily drop modules into the program and try things; a lot like you could do with the patch-cord synthesizers. I may not have realized it explicitly then, but this ability to program improvisationally allowed for that kind of artful playfulness that is so important. So I set out to make a similar user interface for Interactor. The creation of Isadora was a natural outgrowth of Interactor. In 1996 Troika Ranch had a two-week residency at STEIM, where I first saw Tom Demeyer's real-time video processing program Image/ine. I first started using Image/ine in concert with Interactor, because Image/ine didn't allow the kind of complicated interactive decision making that I was used to having in Interactor. So, Interactor would process the MIDI data from my interactive sensors, and then tell Image/ine what to do. By 1998 I was using Image/ine in a major way in my performances with Troika Ranch. [...]
>Mark: Isadora and Max both inherit the modules linked by the patch-cord metaphor from Hookup. But unlike Max, each Isadora module shows the parameter names and current values for all of its inputs and outputs, and many modules give real-time graphic feedback about their operation. This is important from the perspective of helping new users understand what's going on right away. But perhaps the biggest difference is that Max is a very powerful, open-ended programming language in which you could solve any number of problems. Isadora isn't that. It is a lot like Interactor in that each module is essentially a macro that accomplishes some specific function. This approach helps people who are just beginning to do this kind of work, as it means that useful functionality is already embodied for you and it's very easy to start doing things and getting interesting results quickly (like with Image/ine). Max allows the most flexibility, but may be somewhat more difficult to program because more things have to be built up from scratch. Isadora offers somewhat less flexibility, but is still open-ended enough for the user to imprint his or her aesthetic on the result.
While working at VPL, David also integrated the MMP library into Body Electric (below) to make Bounce (also below). The MMP player plug-in is what eventually became Macromedia Shockwave once it was plugged into the web browser (which wasn't nearly as fun as plugging it into a full fledged real time interactive visual programming language).
Body Electric is a real time visual programming language for VR and music and hardware control, developed at VPL by Chuck Blanchard, which Jaron Lanier and others used to create virtual reality simulations and virtual interactive musical instruments.
http://www.jaronlanier.com/vpl.html
https://wiki.c2.com/?JaronLanier
https://www.vrs.org.uk/virtual-reality-profiles/vpl-research...
https://web.archive.org/web/20050228021115/http://www.well.c...
https://web.archive.org/web/20040414174418/http://www.well.c...
https://web.archive.org/web/20050211182929/http://www.well.c...
Body Electric supported all kinds of interesting input and output devices, including MIDI, sending and receiving UDP packets over Ethernet, loading Swivel3D 3D skeleton files and animating them, sending their state over the network to a pair of SGI workstations for rendering with the Isaac rendering engine to the VPL "EyePhones" VR headset (one SGI workstation per eye, with a Mac to run the simulation), VR input devices like VPL's DataGlove and Body Suit, 3D input devices like the Ascension Flock of Birds, Polhemus, and Spaceball, 3D audio output devices like the Convolvotron, and lots of other cool stuff.
https://est-kl.com/manufacturer/ascension/flock-of-birds.htm...
https://polhemus.com/
http://www-cdr.stanford.edu/DesignSpace/sponsors/Convolvotro...
https://www.researchgate.net/publication/253921765_The_Convo...
Bounce is a derivative of Body Electric, that David Levitt integrated with the MMP player, and that I helped him develop, and used for some fun projects. Extremely weird and esoteric, but still one of the must productive, delightful visual programming languages I've used!
https://medium.com/@donhopkins/bounce-stuff-8310551a96e3
https://wiki.c2.com/?BounceLanguage
Immersive Audio Podcast Episode 7 Aaron McLeran
https://podcasts.apple.com/ie/podcast/immersive-audio-podcas...
https://soundcloud.com/user-713907742/immersive-audio-podcas...
>In today’s episode Oliver was joined via Skype by Aaron McLeran, Lead Audio Programmer at Epic Games. Aaron’s first taste of audio programming was writing computer music in CSound while in graduate school at University of Notre Dame (when he was supposed to be doing astrophysics research). Realising his true calling, he left physics to study procedural and interactive computer music, audio synthesis, and audio analysis with Dr. Curtis Roads at the University of Santa Barbara. His first game audio experience was writing procedural music on Spore where he got to collaborate with Brian Eno and Maxis’ audio director Kent Jolly on writing much of the game’s truly procedural music. His next game audio gig was a sound designer on Dead Space 2 where he wrote much of the games interactive audio systems in Lua along with accomplished audio director Don Veca. He made the leap from technical sound designer to audio programmer at Sledgehammer Games where he worked on Call of Duty: Modern Warfare 3 and Call of Duty: Advanced Warfare. His next audio programming gig was at ArenaNet where he got to wrangle with the unpredictability and scale of game audio in the context of an MMO and developed some pretty cool tech around for player-created music and musical interaction. He’s currently working on a new multi-platform audio mixer backend for UE4 and developing new tech and approaches to game audio for VR.
>Aaron speaks to Oliver about all things Game Audio and Procedural Audio and his unusual entry into the industry.
GDC Vault: Procedural Music in SPORE, with Kent Jolly, Aaron McLeran
https://www.gdcvault.com/play/323/Procedural-Music-in
MAKE YOUR OWN KIND OF MUSIC IN 'SPORE' WITH HELP FROM BRIAN ENO (LISTEN TO THIS)
http://www.mtv.com/news/2456432/make-your-own-kind-of-music-...
THE BEAT GOES ON: DYNAMIC MUSIC IN SPORE: Audio engineers Kent Jolly and Aaron McLeran unveil Spore's procedural music generation.
https://www.moredarkthanshark.org/eno_int_gspy-feb08.html
Will Wright and Brian Eno - Generative Systems
https://www.youtube.com/watch?v=UqzVSvqXJYg
Pure Data
https://en.wikipedia.org/wiki/Pure_Data#Projects_using_Pure_...
>Projects using Pure Data
>Pure Data has been used as the basis of a number of projects, as a prototyping language and a sound engine. The table interface called the Reactable and the abandoned iPhone app RjDj both embed Pd as a sound engine.
>Pd has been used for prototyping audio for video games by a number of audio designers. For example, EAPd is the internal version of Pd that is used at Electronic Arts (EA). It has also been embedded into EA Spore.
>Pd has also been used for networked performance, in the Networked Resources for Collaborative Improvisation (NRCI) Library.
edit: whoever flagged me is being paid off by csound
https://news.ycombinator.com/newsguidelines.html
Csound is ridiculously straight forward in comparison. Absurdly more comprehensible to me
I dunno, have things gotten less fun?
I've given sc 5 years, usually I'll try to use it, give it a few days of effort to do what I want, then give up, rewrite what I want in C, and be done with it in an hour
Some people love it. More power to them. I wish I was one of them
Csound is based on a synthesis paradigm that dates back to the very first computer music experiments. It started life as a microcomputer implementation of Music 11, which was based on Music IV, which dates back to the 60s - and it hasn't moved on from there.
Meanwhile sc is a masterpiece of software development - a smooth and clever integration of a custom DSL with distributed real-time synthesis.
But musically it's damn near impossible to get it to sound as nice as a mediocre VST, never mind a good one, and the sequencing and event management are eccentric at best.
Essentially these systems are all opinionated frameworks with a huge conceptual overhead. They're supposed to make music-from-DSP easier to learn, but students have to learn DSP and a completely new and unusual programming language at the same time. And that's too much to expect of most people, even for A-grade students with PhD potential.
So they tend to be used for tinkering and for academic music projects. It's not quite true that no worthwhile music has ever been made with these systems, but it's not an exaggeration to say that very little has. And when you include the learning curve, the ratio of time spent to creative benefit is unimpressive.
As a resident of both Davis and Berkeley, CA I've heard a lot of stiff academic music made in Max/MSP on UC campuses, though I'd say UC Davis' Bob Ostertag is the notable exception - really compelling stuff - but that's because he's using at as an expressive musical instrument.
But still, these environments hopefully provide a DSL/interace that abstracts away some of the complexity of bare-metal C or C++ code; and non-PhDs like Autechre, Squarepusher, Aphex Twin, BT, Leafcutter John and Christopher Willits have made great-sounding things with them. And these tools are often used by professional audio developers to quickly prototype DSP algorithms.
https://en.wikipedia.org/wiki/John_Bischoff_(musician)
https://www.johnbischoff.com/
Lots of amazing interviews with amazing people here:
https://econtact.ca/12_2/interviews_golden.html
John Bischoff
https://econtact.ca/12_2/audio/JohnBischoff.mp3
By now, one of the West Coast biggies, actually, make that international, he’s at the level where he’s thought of as one of the masters, though he is very mild-mannered and modest. In the 70s he formed League of Automatic Music Composers, one of the first computer music network bands, along with Jim Horton, Rich Gold, Tim Perkis. They would use Kim computers and plenty of homemade code and software (and get roasted in the newspapers by the critics especially during New Music America 1981, they were mocked unmercifully, but water off a duck’s back). Who’s laughing now, eh? [November 1988, dur. 11:24]
Laurie Anderson
https://econtact.ca/12_2/audio/LaurieAnderson.mp3
Probably one of the most famous of all our EA people, who successfully bridged the gap between the avant-garde and the “in the know” mainstream.” Even in the early 80s she packed the Mills College Concert Hall, with her violin, millions of “toys” including vibrators, plenty of digital delay and thrilled us all. A sidebar: when I was interviewing Laurie at The Phoenix Motel in San Francisco, a guy came into the room, she told him to introduce himself to Barbara, and he extended his hand and said: “Hello, I am Wim Wenders”… [17 February 1990, dur. 29:00]
In the same way it would be extremely hard to do say, a convincing rendition of the waldstein sonata on say, a drum kit, the digital tools are great if you want to do what they're designed to do.
This is why some people love one piece of software and hate another in some apparently random distribution, music is a huge tent and these people likely have dramatically different goals. It's like a kosher, a vegan, and a keto arguing over the best restaurant...
The problem is trying to figure out whether it's the wrong tool or whether you just haven't spent enough time learning how to use it.
https://en.wikipedia.org/wiki/Nato.0%2B55%2B3d
The author of Nato.0+55+3d, Netochka Nezvanova, aka "nameless nobody", "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp":
https://en.wikipedia.org/wiki/Netochka_Nezvanova_%28author%2...
A typical AntiOrp-style NATO patch:
https://enacademic.com/pictures/enwiki/78/Nato.0%2B55%2B3d.p...
Some neater examples, and an in-depth description of Nato, by Jeremy Bornstein:
http://www.bootsquad.com/old_site/nato/nato00.html
Max has got layers and layers of experience built up over the decades, but no one clear model or consistent way of doing things. It's got so many different opinions, or programming paradigms, that aren't necessarily consistent with each other and don't fit together well. Some people love it, because it happens to have the combination of programming paradigms that they like. But when you're starting out, it's hard to figure out the best way to do anything, because there are so many different competing ways. In that sense, it's extremely un-Pythonic, like visual Perl.
Here's a video that shows some great examples of Max/Nato code. Remember, this was before Cycling '74 created Jitter (which pissed off AntiOrp who considered it a rip-off of Nato). Nato supported many features of QuickTime, including reading and writing live RTP video streams over the network. So Nato "operators" would exchange live QuickTime RTP video streams back and forth over the network (both LAN and Internet) and jam together in live distributed performances, sending the video from one Mac to the other, near and far, mutating and remixing and layering in live video each hop, projecting it on screens, and feeding it back and forth between different "operators" who were writing and editing the code in real time.
Max_MSP_nato.0+55+3d 's_app_run_on_El_Capitan_test 2
https://www.youtube.com/watch?v=X0kQcnetR9M
Here's more about Nato:
https://news.ycombinator.com/item?id=16753758
>Nato.0+55+3d (released in 1999) was an amazing but notorious extension for Max that enabled live programming of real time video manipulation, networking and display. https://en.wikipedia.org/wiki/Nato.0%2B55%2B3d
>"At the time of its release (the summer of 1999), NATO.0+55+3d was in demand as it appeared several years before other similar infrastructures such as GEM and Jitter (released by the makers of Max/MSP in October 2002). Earlier software such as Image/ine developed in 1997 at STEIM was drawing in a similar direction, but the fact that NATO.0+55+3d was operating inside the Max/MSP framework, using its "visual programming" protocol, provided at the same time greater ease of use and more flexibility, allowing the user to create his own applications and tools. It gained popularity among video artists and performers, who were using it for a large variety of purposes, prominently for live performance and interactive installation."
https://news.ycombinator.com/item?id=22352276
>Bravo! If you enjoyed that anti-Max performance art trolling, but thought it wasn't spectacularly hyperbolic and sociopathic enough, I recommend looking up some of the classic flames on the nettime mailing list by Netochka Nezvanova aka "NN" aka "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp"! https://en.wikipedia.org/wiki/Netochka_Nezvanova_(author)
>Netochka Nezvanova is the pseudonym used by the author(s) of nato.0+55+3d, a real-time, modular, video and multi-media processing environment. Alternate aliases include "=cw4t7abs", "punktprotokol", "0f0003", "maschinenkunst" (preferably spelled "m2zk!n3nkunzt"), "integer", and "antiorp". The name itself is adopted from the main character of Fyodor Dostoyevsky's first novel Netochka Nezvanova (1849) and translates as "nameless nobody."
>She (or he or they or it) were the author of the NATO.0+55+3d set of extensions for Max, which predated Jitter:
https://en.wikipedia.org/wiki/Nato.0%2B55%2B3d
The most feared woman on the Internet
http://www.salon.com/2002/03/01/netochka/
>Netochka Nezvanova is a software programmer, radical artist and online troublemaker. But is she for real?
>The name Netochka Nezvanova is a pseudonym borrowed from the main character of Fyodor Dostoevski’s first novel; it translates loosely as “nameless nobody.” Her fans, her critics, her customers and her victims alike refer to her as a “being” or an “entity.” The rumors and speculation about her range all over the map. Is she one person with multiple identities? A female New Zealander artist, a male Icelander musician or an Eastern European collective conspiracy? The mystery only propagates her legend.
Cramer, Florian. (2005) "Software dystopia: Netochka Nezvanova - Code as cult" in Words Made Flesh: Code, Culture, Imagination, Chapter 4, Automatisms and Their Constraints. Rotterdam: Piet Zwart Institute.
https://web.archive.org/web/20070215185215/http://pzwart.wdk...
Here is some of the delightfully stylized "documentation" of some interesting NATO extensions, written with Netochka Nezvanova's poetic simply.SUPERIOR Eastern European Marxist Feminist Punk Hacker ASCII Art Razzle Dazzle.
http://www.bootsquad.com/old_site/nato/nato00.html
If the built-in NATO objects aren't enough for you, you may purchase several `extended` objects for NATO. At the time of this writing, they include:
- 242.wto: video streaming objects
https://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.parazit: a plug-in host for Image/ine plug-inshttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.fireuire: several FireWire objects, which permit NATO to send various data (image & effects data, DV data, MSP audio data) through your FireWire porthttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.o204: an internet data transfer (download/upload) objecthttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.axial: a directory/search engine utilityhttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.of02: a realtime, recursive multi-layer photoshop file to qt movie converterhttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.obl!ke: a media preview objecthttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.gl: an OpenGL rendererhttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.qtfx: a QuickTime effects hosthttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.nr+: some non-realtime objectshttps://web.archive.org/web/20010707090427/http://eusocial.c...
- 242.rna: NATO to MSP sound manager driver and associated software.https://web.archive.org/web/20010707090427/http://eusocial.c...
It took me many years to learn how to get the "sound in my head" programmed into a synthesizer. You do this with the fast fourier transform? Huh?
I think like Haskell and R it's designed for a different profession so to people like me who are programmers first I am scratching my head the whole time. I can do some thing in it, yeah eventually, usually...
The documentation appears complete and I'm sure the compilers are well written, an enormous amount of effort went into it, it's just a problem with me here.
If you think as a programmer you might be happier around low-level things, take a look at Soundpipe, which contains those same fundamental elements again - often with the same or similar names to their equivalents in the above programs - but in plain C code.
https://paulbatchelor.github.io/proj/soundpipe.html
For something a little more 'live' and high-level built on that library by the same author, check out Sporth, or another guy's browser-based embedding of it called AudioMasher - which has some very nice examples.
https://paulbatchelor.github.io/proj/sporth.html https://audiomasher.org/
SonicPi/Overtone or Gibber are also nice also as they are based off of existing languages.
[1] https://chuck.stanford.edu/
You can make midi interfaces in Python and plugins in LADSPA and other things with Jack ... lots of programs are fairly extensible these days.
so for instance, instead of a physical instrument connected to a usb port, your software is feeding the midi input into some other software, say something simple like seq42 (https://github.com/Stazed/seq42)
Synthesizers have some interesting things too. https://zynaddsubfx.sourceforge.io/ uses an XML format for its synthesis definition. It also has "learnable midi" as in parts of the interface can be instrumented from a midi controller - so you turn a knob in physical space and it turns in the software accordingly.
So let's go back to the previous part, the part about software defined midi. You can now emit the mutation of the sound and the sound itself into software like that. Here's a 2005 linux journal article with a screen shot (https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...) essentially the stack I just said. https://www.linuxjournal.com/article/8304 ... "2005" you say? yeah, old pianos also still work.
The linux space is littered with generic audio tools that don't really work on their own and must be pasted together with other tools in order to get anywhere, much like in the shell. I did a bit of editing on the linux audio wiki about 3 years ago, it's probably the best place to look: https://wiki.linuxaudio.org/wiki/introduction
It's still just a bunch of hacks on top of hacks. Things break all over the place and latency is a bitch ... I dunno, there's a lot out there.
You like supercollider. That's fine but it doesn't make csound "trash." You want a gui. That's fine, but csound users like myself and others here prefer a solid scripting environment.
If you wouldn't say it to the author, don't say it here, because it's often the same thing
There was a horrible case yesterday where someone died and the thread filled up with generic dross. People weren't being malicious. It's just what happens when internet commenters aren't familiar with the specifics of a topic (more about that at https://news.ycombinator.com/item?id=22027453). But we ended up getting an anguished email from someone close to the person who had just died.
This is a systemic problem and I wish we knew what to do about it.
Even though the people there weren't necessarily violating the site guidelines per se, the commentary that some people were making (e.g. discussion about IP stemming from the murderer's unsubstantiated accusation of plagiarism, or discussion about Japan's culture) felt insensitive and hurt me as someone who was greatly impacted by KyoAni's work. I didn't understand how to express my feelings about this, but the way you describe it ("generic dross") explains it perfectly.