It's common to think of networking as being essentially a solved problem
for Linux. But, like the rest of the computing environment, networking is
evolving quickly over time, and Linux will have to evolve with it. Marcel
Holtmann used his LinuxCon Europe slot to talk about some of the work that
is being done to ensure that Linux networking remains second to none.
In particular, Marcel is concerned with improving networking on mobile
devices. He is staying away from enterprise networking, which, he said, is
pretty well worked out. It's mostly based on cabled connections with "no
crazy stuff" to worry about. But mobile networking is different. The
environment is far more dynamic, there is much more user interaction
involved, and there is a long list of tools needed to manage it — and many
of those tools are old and not up to the task.
That said, some of the problems are nicely solved at this point. The
"networking basics" are in place; these include Ethernet and WiFi support,
along with Bluetooth, cellular protocols, and higher-level protocols like
DHCP, DNS, and NTP. IPv6 support is mostly there, and tethering support
is now in good shape. We also have the beginnings of support for the WISPr protocol which enables
automatic login to wireless hotspots. Things are quite good, Marcel said,
for the simpler use cases.
The problem is that, increasingly, the common use cases are not so simple,
so there are a number of challenges to be overcome before Linux can take
the next step. The first of those is being able to answer a simple
question: is the system actually online? Simply being associated with an
access point is often not enough if that access point requires
authentication. It is not an uncommon experience to have a smartphone hook
up to an access point with a recognized SSID and, since the
authentication step has not yet happened, lose connectivity entirely. The
problem is that, at this point, there is no easy way to know if a system is
actually on the net or not.
An additional complication is the concept of a locally-connected network; a
mobile device may be connected to local devices (a television, say) without
having access to the wider Internet. We don't currently have a way to
detect that situation or to communicate it to applications.
Connectivity is currently thought of at a global level — the system is
either online or it is not. But different applications have different
connectivity needs, so we need to move toward a concept of per-application
connectivity. The system should be able to go online for a specific task
(synchronizing an important application, say) without necessarily opening
the floodgates for any other application that may want to talk to the
world. We currently have no way to do that because Linux networking is based
around systems, not around applications.
An additional irritation is that, once connectivity is established, all
applications are notified of the availability of the net at the same time.
That creates a sort of thundering herd problem where a whole range of
processes try to open connections simultaneously. The result can be a
clogged link and frustrated users. We really need a one-at-a-time
waking mechanism for applications, with the more important ones being
There is a real need for finer-grained usage statistics for the net;
currently all statistics are global, which tends not to be helpful in the
mobile environment. There are no per-user or per-application statistics,
and no way to distinguish home-network traffic from roaming traffic.
Android has a solution of sorts for this problem, Marcel said, but it is "a
horrible nasty hack" that will never make it upstream. Somehow we need to
come up with a cleaner implementation.
Time is simple in the data center; one just has to fire up NTP and forget
about it. But it is a more challenging concept on a mobile system. Those
systems can move between time zones; it can be hard to know what time it
actually is. For added fun, many of the available sources of time
information — cellular networks, for example — are often simply wrong. So
the system needs to find a way to look at data from multiple sources before
concluding that it is safe to change the current time zone.
Time confusion can also create trouble for applications, especially those
with complex synchronization requirements. To avoid problems, the system
really needs to figure out the correct time before notifying applications
that the network is available.
The concept of network routing must become more sophisticated in the mobile
environment. Some applications, for example, should only be run if the
virtual private network (VPN) is available, while others can run over any
network. Other applications should not be allowed to use the VPN
regardless of its availability; the same is true of Bluetooth and other
types of connections.
If a WiFi connection becomes available, some applications may
want to use it immediately, but an application in the middle of a
conversation over the cellular connection should be allowed to wrap things
up before being switched to the new route. So there needs to be something
like per-application routing tables, something that a tool like ConnMan can
change easily, but, Marcel said, the current network namespace
implementation is too strict.
What bugs Marcel the most, though, is the Linux firewall mechanism. He
wants to be able to set up personal firewalls that differ based on the
current location; a configuration that works at home or in the office may
be entirely inappropriate in a coffee shop. He didn't have much good to
say about the Linux firewall implementation; it's highly capable, but
impossible to configure in a reasonable way. There are, he said, lots of
race conditions; reconfiguring the firewall involves clearing the old
configuration and leaving things open for a period. He is hoping for a
conversion to nftables, but progress on
that front is slow.
Marcel would also like to see the easy creation of per-application
firewalls; just because a port is opened for one application does not mean
that others should be able to use it.
Local WiFi networks, for applications like sending video streams to a
television, are coming. That requires support for protocols like WiFi Direct. The good
news is that the kernel has fairly nice support at this point;
unfortunately, the user interface work has not been done. So only expert
users can make use of this capability now. Making it work properly for all
users will require a lot of integration work into a lot of subsystems, much
like full Bluetooth support needed.
Speaking of Bluetooth, it now has support for pairing via the near-field
communications (NFC) protocol. Essentially, devices can be paired by
touching them together. NFC-based authentication for WiFi access points is
on its way.
There is also work being done to support sensor networks over protocols
like 802.15.4 and
To summarize the talk, there is a lot of work to be done to provide the
best mobile networking experience with Linux. Happily, that work is being
done and the pieces are falling into place. Lest anybody think that there
will be nothing for anybody to complain about, though, it is worth noting
that Marcel saved for the very end of the talk: in the future, the use of
systemd and control groups will be mandatory to get good mobile networking
[Your editor would like to thank the Linux Foundation for funding his
travel to the event.]
Comments (20 posted)
It has now been a little more than two years since the systemd project
began, and in that time a lot has happened. So Lennart Poettering, one of
the main developers of systemd, took the opportunity to look back at the progress to date, in a talk at LinuxCon
Europe 2012 . Kay Sievers, the other
principal systemd developer, was also in the audience, and offered some
pieces of background information during the talk.
The first announcement of systemd was in April 2010. The first
distribution based on systemd, Fedora 15, came out in May 2011. Since
then, it has appeared as the default init system in a number of other
distributions, including openSUSE, Mageia, Mandriva, Arch Linux, and
others. Systemd is also included in Debian and Gentoo, but it is not the default init system. The most notable absence from the list is, of course,
Ubuntu. Lennart expressed the hope that Ubuntu might still switch over, but
sounds somewhat less confident of that these days than he has in the past.
Lennart reported that the systemd project is in good health, with 15
committers (including committers from a range of distributors) and 374
contributors to date, although the latter number is inflated by the
incorporation of udev into systemd; if the udev contributors that have
contributed to that project during its seven-year lifespan are excluded,
then systemd has had about 150 contributors. There are about 30 contributors
in any given month, and around 490 subscribers to the project mailing list.
One of the goals of systemd was to be able to boot a system without
requiring shell scripts, and that goal was achieved about a year ago. The
problem with shell scripts, of course, is that they make it difficult to
implement the necessary parallelization and asynchronous logic that are
needed for fast boot times. As a result of eliminating shell scripts from
the boot phase, the number of processes created during system start-up
has fallen from 1500 to about 150. On a system with an SSD, booting a
full user space can be accomplished in under one second on a standard
PC-architecture laptop. Users of Fedora are unlikely to achieve boot times
that are quite that fast, because of dependencies like LVM, but boot times
of 10 seconds should be achievable "out of the box" with Fedora. Thus,
whereas once upon a time the kernel was
fast and user space was slow to boot, these days the position has
reversed. Lennart remarked that the ball is now back in the kernel's
court in terms of improving boot speeds.
Lennart noted that systemd started out as an init system, and as such
replaces the classical System V init (sysvinit) program. But along the
way, the developers figured out that booting a system is not solely the job
of PID 1 (the PID created for the first process on the system, which
executes the init program). There are other processes as well, such as
init scripts. So the developers redefined systemd a little more, to be not
just an init system, but also a platform. Thus, systemd includes a couple
of mini-services that are useful for booting. These services include, for
example, reading ahead files that were used during the last boot so that
booting proceeds faster this time around. Systemd also added a number of
other components, such as udev and a system logger, and replacements for
pieces like ConsoleKit. The
goal of including these services and components within systemd is to create
a more integrated boot system.
These changes are sometimes perceived as feature creep in what is
supposed to be simply an init system, which prompts the question: is it
bloated? Lennart's response is an emphatic "no". In the systemd platform,
PID 1 is simply a unit control system. Other tasks are performed by other
pieces that ship as part of the systemd package. He likened this to being
a repackaging of what once were separate tools that interacted during the
boot phase. That repackaging allows a more integrated approach to the
boot process that also eliminates some code and feature duplication that
occurred across the formerly separate components. By eliminating
duplication, and providing a more integrated approach to the boot
components, the resulting system is easier for system administrators to
manage. The increasing scope of systemd has created more dependencies on
other packages, but Lennart noted that almost all of these dependencies are
optional, and only required if users want the optional features available
At this point, an audience member asked about the status of systemd with
Busybox for embedded systems. Lennart noted that he works mainly on
desktop systems, but the project certainly does care about embedded
Systemd integrates with some other operating system components. For
example, Dracut can pass
performance information to systemd, as well as other information, such as
whether the root file system was consistency checked. Systemd integrates
closely with udev—so closely that udev was eventually merged into systemd, a decision that was, as
Lennart noted, widely discussed, and somewhat controversial. Systemd
integrates with D-Bus
activation, so that if a D-Bus name is requested, a service will be
started. Systemd integrates with the Plymouth boot
screen splash tool, so that the two systems coordinate their handling of
the screen and passwords. It integrates with the Gummiboot boot
loader for EFI, so that it is possible to get boot statistics such as
measures of the amount of time spent in BIOS, bootloader, kernel
initialization, in init ramdisk, and in user-space activation.
Like the Linux kernel, systemd targets the full spectrum of
platforms, with features for mobile, embedded, desktop, and server systems,
and Lennart remarked that it was interesting that these diverse platforms
gained common benefits from systemd. For example, the control-group
management features for systemd are of interest for resource management in
both server and embedded systems.
An audience member noted that the systemd project has not focused on
porting systemd to other operating systems, such as FreeBSD, and asked
whether there was no FreeBSD developer who said they'd like to port systemd
to FreeBSD? That has not happened so far, Lennart said. The
problem is that systemd is tightly bound to various Linux-specific
features, such as control groups, for which there are no equivalents on
other operating systems. Kay noted that attempts to port udev to other
systems went nowhere, and that would be a necessary first step to port
Systemd has made a number of components in the traditional init system
obsolete. The most obvious of these are, of course, sysvinit and init
scripts, which are replaced by small C programs that can be parallelized
during boot. In addition, systemd made a number of other components
obsolete, such as ConsoleKit, pm-utils, and acpid (the ACPI daemon). Systemd's
socket-activation feature renders inetd obsolete.
Lennart emphasized that while systemd renders all of these components
obsolete, most of the components (with obvious exceptions such as
sysvinit) can still be used in parallel with systemd, if desired.
At this point, an audience member opined that the classical UNIX init
process was designed to be as small and robust as possible, but that this
seemed to contrast with where systemd was going. Is systemd at risk of
becoming a large single point of failure? Lennart pointed out that while
systemd replaces many earlier tools, it performs those tasks in separate
processes. However, the notable difference is that the various components
operate in a much more integrated fashion.
Lennart then turned to a discussion of the
Journal. The Journal is a recently announced systemd component, which
is posited as the successor of the traditional syslog logging system. The
syslog system is nearly 30 years old, renders log messages in plain
text, and does not lend itself to seemingly simple tasks such as showing
the last ten log messages produced by a particular service. There are
many problems with syslog. For example, it does not index the log and it
does not verify the source of log messages.
The systemd developers concluded that logging is an essential part of
service management, and none of the current solutions was adequate for
systemd's needs, so they came up with the Journal. The Journal has
structured metadata about every log event, including eighteen fields with
information such as user ID, group ID, and SELinux context. The log is
indexed, and secured so that the logged data is trustworthy. The Journal
is also rate limited, so that no individual service can clog the log. The
Journal has forward secure sealing, so that,
periodically (by default, every fifteen minutes) a cryptographic tag is
added to the logged data, and the cryptographic key is discarded. The effect
is that an attacker who breaks into the system can't alter history in the
log (other than possibly the log entries created in the current interval).
Work is ongoing to add network logging functionality to the Journal.
Unfortunately, Lennart ran out of time, so that he was unable to go
over his thoughts about the future of systemd. However, after two years,
it's clear that systemd is an established part of the Linux landscape, and
there are increasing signs
that it is moving toward becoming an essential part of the operating
Comments (80 posted)
Csound is a digital audio synthesis and processing environment with
facilities for music and sound composition. It is a product of the world of
Unix workstations in the 1980s, with a native user interface consisting of
plain text files created in a text editor or word processor. Csound is one
of the many systems that evolved from Max Mathews's pioneering MusicN
series, which was the first set of programming languages dedicated to creating sound and music on computers. Csound is arguably the most advanced of all the systems derived from the MusicN languages.
More specifically, Csound evolved from Music5. It was written by Barry
Vercoe, but, since its inception, the system has grown from contributions
by many other developers. Csound has always been open-source
software. Originally covered by a license from MIT, Csound is now protected
by the LGPL, which makes it free and open-source software by contemporary
standards. The source package also carries free license terms for certain components not covered by GNU licenses.
The complete Csound system is made of many parts, but the two most
important are the Csound programming language and its compiler. A musical
piece for Csound is usually written as a collection of instrument
definitions and score directives, all of which are compiled to an audio
waveform by the csound binary, either offline or in realtime. The
language can describe a synthesizer, build a guitar effects processor,
perform conditional transformations on a MIDI input stream, and so forth,
while the scoring language describes events and their parameter sets to be
interpreted by the specified instruments. When the instrument definitions
and score instructions are complete, the audio engine can be invoked as a
separate process to render the sound.
When processed by the Csound compiler, the following code creates a WAV file
of a sine wave played for three seconds — an audio compiler's "Hello world!":
; process with no display, minimal messaging, no graphics
; output to WAV file named simple-sine.wav
-d -m0 -g -o simple-sine.wav
sr=48000 ; audio sample rate
ksmps=64 ; samples per k-rate (control rate) period
nchnls=2 ; number of audio output channels
instr 1 ; define a Csound instrument by number
kamp = p4 ; amplitude value in the score event's
; 4th p-field
kfreq = p5 ; frequency value in the score event's
; 5th p-field
ifn = p6 ; function table number in score event's
; 6th p-field
aosc oscil kamp,kfreq,ifn ; an oscillator with amplitude, frequency,
; and f-table values from preceding parameters
kenv linseg 0,p3*.50,1,p3*.50,0 ; a gain envelope to modulate
; the event's output volume
aout = aosc*kenv ; apply the envelope to the oscillator output
outs aout,aout ; send the modulated signal to the
; system audio stereo outs
endin ; end the instrument definition
; a stored function table
; table number, start time, number of sample points,
; GEN function, harmonic fundamental
f1 0 8192 10 1
; an event list with six p-fields
; instrument number, start time, event duration,
; direct amplitude value, frequency in cycles per second (cps),
; function table numnber
i1 0.0 3 5000 440 1
e ; end of score
This example is in Csound's unified file format, which joins the instrument
definition and score events pieces that historically were in separate files. To render it to a soundfile we need to feed the file to the Csound compiler:
If all goes well you'll have a new 3-second recording of a sine wave that swells from silence to a fairly loud volume and back again to silence. If things don't go well you'll get some hopefully informative error messages from Csound to help debug your code.
I'm sure some readers are wondering why anyone would go to such trouble to produce a sine wave, but consider the following implications from our little example :
- I can invoke as many oscillators as I want by simple cut-and-paste text manipulation.
- I can increase the number of sample points in the function table that provides the sine wave.
- The envelope can have as many stages as I wish.
- I can easily specify a more complex multichannel audio output.
- The score event values can be replaced by expressions and macros.
All of that just scratches the surface of Csound's capabilities, many of
which are found in no other sound software or hardware. It is amazingly
powerful software, but accessing its power can be difficult, especially for
new users accustomed to GUI-based music software. The plain-text interface
seems rather forbidding at first, as does the prospect of working at the
command-line. Fortunately, the language has been designed for directness and
simplicity, though its complexity varies with the particular
elements used in your instruments, of course.
Instruments and processors are built from Csound's huge collection of
opcodes, which are the synthesis and processing "black boxes" that provide the various parts — oscillators, envelopes, filters, etc. — required by your instrument designs. Each opcode has its own set of parameters and usage details, so while some may have only a few parameters to address, others may have considerably more. Values for those parameters can be set or calculated within your instrument definitions, or they may be provided by the scoring language.
In the general computing world, the dominance of the GUI might have doomed
Csound and similar systems to the dustbin of music software
history. However, Csound has proven to be flexible enough to evolve and and
remain current, thanks especially to a talented development team ably
managed by John ffitch for more than twenty years. Through those years, many fine contributing programmers have come and gone from the Csound development community, but John's deep involvement as Csound programmer and composer has ensured stability, high-performance, and compatibility. On top of this core reliability, we find many developers dedicated to easing the way into Csound by way of graphic IDEs (integrated development environments), documentation improvements, enhanced connectivity, and other developer and user-level amenities.
Thanks to the efforts of its dedicated developers, Csound has an API
(application programming interface). Thanks to that API, interesting new
applications can be devised with easy access to Csound's considerable
capabilities. This article presents a fly-by scan of the activity in some
of Csound's new directions, including its deployment on mobile devices, its
ever-improving development environments, and its integration with external
music and sound software by way of plugins or standalone programs built with the Csound API.
Work proceeds towards the deployment of Csound on Android and iOS
devices. I haven't entered the mobile world yet — I'm still deciding
on the hardware — but I can point to Steven Yi's VoiceTouch, Art
Hunkins's ChimePad, Roger Kelly's
and Rick Boulanger's CsoundTouch
to indicate the state of the art.
The Csound source tree now includes a
branch for Android development, while the developers' mailing list reveals
considerable interest and activity in this area. The hardware capabilities
of the current devices pose problems with latency, memory usage, and
screen real estate, but those will be resolved eventually. As the devices become more powerful, Csound will be ready to take advantage of their increased capabilities.
The way into instrument design and audio composition with Csound has been
made easier with environments such as Andres Cabrera's CsoundQt (shown at right),
Yi's blue, Stefano Bonetti's WinXound (at left), and Jean Piche's Cecilia. These environments
differ in many ways, but all are dedicated to providing an organized entry
WinXound and CsoundQt look similar to general
purpose IDEs such as Eclipse or Microsoft's VisualStudio, with panels for
code inspection, debugging output, manual pages, GUI elements, and so
Blue (at left) is more focused on the use of Csound's interfaces to Python
and Java, with provisions for instrument design and some powerful tools for
Cecilia takes a more graph-oriented approach to composition by
employing an X/Y coordinate system to create generative and modulation
curves (shown at right) in a unique way for Csound.
The Cabbage patcher
Developer Rory Walsh has been working on an interesting project called Cabbage. Its web site describes the project as "software for creating cross-platform Csound-based audio plugins", a laudable goal that intends to bring Csound's capabilities to any Linux audio host that supports native VST plugins.
Cabbage processes a file created in a special version of Csound's unified
file format and creates a GUI front-end for the instrument or effect (at left). A regular CSD file can be edited with Cabbage's file source editor and tweaked until ready for export as a plugin or standalone application. Currently, the Linux version of Cabbage will create standalone executables and Linux VST plugins, with support for either JACK or plain ALSA audio I/O.
I've had mixed but promising results from my tests of Cabbage. Most
well, and I've been able to export plugins recognized as valid Linux VSTs
by Qtractor and Ardour3. Rory also reports success using
Cabbage-created plugins with the Linux version of the Renoise digital audio
workstation (Renoise is built with the same JUCE framework used by Cabbage).
Documentation consists of a single HTML page in the Docs directory of the source package. The information on that page is useful, but it is not current. For more up-to-date information, you can communicate with Rory and other developers and users on the Cabbage forum and the Csound mailing lists.
The project is young but its Linux version is stable enough for public
testing. Performance needs further tuning, the plugins themselves have a
large memory footprint, and the documentation needs to be updated. Work remains to be done, but Rory is dedicated to Cabbage's success and welcomes participation from other developers and normal users.
Csound composition/performance environments
In Ye Olden Times, music and sound composition in Csound was a daunting task. The system includes a scoring language and a few utilities for massaging existing scores, but composing complete pieces directly in Csound meant laboring over every event and its unique parameters. Composers such as Richard Boulanger and James Dashow created substantial, beautiful works by hand-crafting every sound and effect, and this method is still available to anyone who wishes to work in such a manner. However, Csounders now enjoy a variety of helper applications and utilities, including some remarkable software dedicated to facilitating composition in Csound.
The modern Csound language includes opcodes — signal processing black boxes — that provide useful random number generators and stochastic cannons, but it lacks sophisticated procedures for further processing the generated data. Fortunately, the gurus of Csound development have created programming interfaces for other languages that do provide such procedures, such as C++, Java, and Python.
I've written elsewhere about athenaCL, CsoundAC, and CM/GRACE, all of which include Csound as an output target. These systems require some study — programs in CM/GRACE are written in a Lisp derivative, CsoundAC and athenaCL employ Python — and they are of interest primarily to composers working with algorithmic composition methods. CM/GRACE author Rick Taube observes that they address issues at what he calls the metalevel of music composition, a "representation of music ... concerned with representing the activity, or process, of musical composition as opposed to its artifact, the score." These packages are fascinating and powerful tools, but clearly they are not music manufacturing programs a la GarageBand.
Jean-Pierre Lemoine's AVSynthesis (at right) is
designed as an environment for interaction with OpenGL 3D graphics transformations in realtime, accompanied by audio from Csound also rendered in realtime. However, it is equally useful as a standalone non-realtime system for music and sound composition with Csound. AVSynthesis provides a set of premade instruments and signal processors, along with an analog-style sequencer, a 64-position step sequencer, a GUI for shaping Cmask tendency masks, and a piano-roll interface. Alas, there are no facilities for adding new instruments or effects, but Jean-Pierre's instruments and processing modules are excellent. I've worked intensively with AVSynthesis for a few years, and I'm far from exhausting the possibilities of its included sound-design modules.
Stephane Rollandin's Surmulot is
also dedicated to composition with Csound. The Surmulot home page describes
the software as "a complex environment for music composition",
which is an accurate description. Surmulot is a collection of three systems
— the Csound-x code for using Emacs as a front-end for Csound, the
muO Smalltalk objects created for use in the Squeak environment, and the
GeoMaestro system based on the powerful Keykit program for experimental MIDI
composition. Its author advises that Surmulot is not for everyone, but it
is a rich environment for composers who want to work in an experimental
environment and are not intimidated by emacs.
Incidentally, if you want to compose your Csound works in good old Western standard music notation you'll be pleased to learn that the Rosegarden sequencer can export scores created in that program to scores in the Csound format. Rosegarden's notation capabilities are extensive, and as far as I know it is the only sequencer/notation package that includes Csound as an export target.
Documenting the scene
When I began using Csound in 1989 the system was relatively small. Most of its documentation was in the official manual, a useful and informative tome despite a rather terse presentation and the lack of examples for many opcodes. A few pieces were available for inspection, but the learning process was largely by trial and error.
The current system is considerably larger, with many new opcodes,
utilities, and third-party extensions. Likewise, Csound's documentation has
expanded. The official manual is
the focus of much labor from the community, with updated entries for the
whole system and useful examples for all opcodes. The FLOSS on-line manual is more modest in scope but is especially valuable for beginners. Dozens of Vimeo and YouTube videos offer instruction and demonstrations of Csound in action, and if I'm in the off-line state I can read and study one of the five hardcopy books dedicated to Csound. It is fair to claim that the learning process has become considerably easier — perhaps I should say "much less difficult" — thanks to this profusion of resources.
But wait, there's more. In 1999, Hans Mikelson published the first issue of the Csound Magazine, an on-line collection of articles from and for the Csound community. All levels of participation were encouraged, and the magazine was a first-rate resource for new and experienced users. Alas, in 2002 Hans gave up management of its publication. However, in 2005 Steven Yi and James Hearon began publishing the Csound Journal. Like the Csound Magazine, the Journal accepts and publishes work regarding all aspects of Csound at all levels. Don't take my word for it though, just take a look at the Csound Journal/Csound Magazine article index for a quick survey of the various topics of interest to Csounders.
Google finds thousands of sites associated with a search for "Csound", including the predictable thousands of bogus or irrelevant sites. I suggest that you cut through the confusion and head straight to Dr. Richard Boulanger's cSounds.com. It's the best resource for exploring the world of Csound with news, announcements, links, podcasts, user pages, and more. If you want to know what's going on with Csound you need to check out cSounds.com.
I've mentioned the Csound mailing lists. Separate lists are available for developer and user-level discussions, though anyone is invited to participate on either list. For many years the lists have been the principal channel for Csound-relevant communications, and they remain so today. The level of discussion can be formidable, especially on the developers list, but exchange is typically civil and helpful. If you don't understand something, just ask, and you're likely to get a prompt response from one of the many Csound wizards populating the lists.
The more musical notes
Csound is the system of choice for many diverse composers. Check out the Csound group on SoundCloud,
as it's quite a varied playlist. Csound is normally associated with
academic and experimental computer music, but the collection at SoundCloud
includes both popular and more esoteric styles. The Csound users mailing list frequently receives announcements for new works, and the occasional Csound-based piece shows up in KVR's Music Cafe. If you're composing with Csound, feel free to leave a link to your work in the comments on this article.
Csound is deep and complex software with powerful capabilities for
audio/MIDI composition and processing. The Csound community is committed to
improving every aspect of the system, including its documentation at user
and developer levels. Projects such as Cabbage and CsoundForLive extend Csound into
the larger world of the modern digital audio workstation, exposing its
powers without demanding special knowledge from a normal user. Greater
awareness of Csound help generate more interest in the system, expanding its development and user base, thus ensuring its continued relevance.
Comments (12 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: PAM face-recognition authentication; New vulnerabilities in drupal, kernel, munin, mysql, ...
- Kernel: Volatile ranges; Secure boot kernel restrictions; NILFS2
- Distributions: Slipping or skipping Fedora 18; DragonFly, Fedora ARM, OpenBSD, openSUSE ARM, ...
- Development: Modeling systems with Alloy; Asterisk; Enlightenment; LibreOffice numbers; ...
- Announcements: Linaro Enterprise Group announced, Apple v Motorola, RMS on software patents, ...