[music-dsp] a little about myself

Ross Bencina rossb-lists at audiomulch.com
Mon Feb 27 16:00:25 EST 2012

On 27/02/2012 4:11 AM, Richard Dobson wrote:
> On 26/02/2012 05:48, Ross Bencina wrote:
> ..
>>> (1) An efficient way to implement a runtime compiler for block-based
>>> audio DSP chains (these are what are in software synthesizers)...
>>> which usually are based on
>> As if block-based DSP chains are the only way to make sound with a
>> computer.
> Indeed they are not; but they are often the most efficient way to do it
> while retaining flexibility of configuration. For much the same reason
> that block-based access to a disk file is so much more efficient than
> single-word access that the latter never happens.

Thing is, most of the time you can do word-level i/o, even if this is 
not how it's implemented. Same thing with processor cache's, they 
(mostly) transparently support word-level access.

This is not the same as being (effectively) forced to do page or block 
level access.

> Most audio devices for
> general-purpose computers have no choice but to deliver audio to the
> host in bursts of, say, 32 samples, so the audio is already being
> supplied as a block rather than single samples.

I don't really see how the functioning of the hardware sample delivery 
mechanism has any bearing on the required functional capabilities of a 
computer music programming system that (fundamentally) generates sound 
sample by sample.

> Given the choice of one
> function call on a vector, or 32 function calls on a sample, there can
> still be many reasons to choose the former.

Agreed. And one would like to do so whenever possible, and not do so 
whenever required. Setting ksamps=1 may be sufficient in some 
circumstances, whereas I would say the option needs to be available at 
any moment (for each subexpression or statement say). This is more or 
less what Faust or MP4-SAOL give you for example.

>> The assumption here is that the target audience is the "non technical
>> musician". I think this is completely spurious. Talking about
>> limitations or capabilities of computer programming languages is kind of
>> pointless if you allow for the novice user who doesn't even know what a
>> turing complete language can do.
> Exactly true. It is only relevant to programmers.

And as I have already said. Computer musicians, must be programmers *by 
definition*. Otherwise they are musicians, using computers. That's where 
I stand. If you want to take a different point of view that's fine, but 
know that this is the position from which all of my arguments in this 
thread stem.

> We can drive a car
> pefectly well, and even do or direct basic maintenance on them, without
> knowing the minutiae of metallurgy or chemistry, and we can light and
> enjoy a firework without knowing anything about Newton's laws (or
> chemistry, again). Maybe just a bit about health and safety. And we can
> enjoy a film and use a GPS system without having to know anything about
> the interactions of photons and electrons or the relativistic
> compensation of satellite signals. All these things are interesting, and
> for those whose business is building them, essential. But carbon-based
> life forms have managed to jump, swim, fly, throw and catch for
> millennia without having any idea how gravity really works, or what
> momentum really is.

Agreed. Indeed the skills required for driving may even be orthogonal to 
those required for metalurgy.

> People (UK-based) concerned about the public's level of education with
> respect to computing may be interested to join the Computing At School
> community, dealing with the newly announced UK initiative to all but
> replace the existing ICT curriculum with a computer science one
> involving real programming. One tool widely used at primary level is
> called "Scratch", developed at MIT:
> http://scratch.mit.edu/
> It supports some music programming, but arguably could do very much more
> in that area.
>> In my view, anyone who cares about being a composer of *computer music*
>> (in the context of this dicussion) needs at least the following (or
>> equivalent) undergraduate knowledge:
> Although I go along with the collective and use the term, I do not
> believe there is actually such a thing as "computer music", outside the
> usual limitations of the language myth. At the very least, I would
> question if everyone using that term means it in the same way. There is
> music (or "sound art") that has been composed or performed using
> computers, and in practice there are sounds which we either know or
> assume depended on computers (or tape, or strange electronics) to make
> them. There is also music composed using algorithmic techniques, but
> these do not all need computers, unless in the old meaning of "one who
> computes". The vast majority of what is popularly called "computer
> music" is well within the classical paradigm of instruments and notes,
> rhythms and harmonies, drones and moments, active performers and passive
> listeners, and can be listened to and enjoyed with no more than the
> corrsponding vernacular musical listening skills. A basic definition of
> "electro-acoustic" is no more than "music/sound presented using
> loudspeakers". The somewhat astonishing but also understandable
> enthusiasm for all things analogue and retro suggests that for most
> people computers are best seen but not heard!

Yes there is a lot of this. I make my living making software that 
addresses this "retro" non-computational use of computers to make music. 
You could see it as part of the trend towards virtualisation of 
pre-existing paradigms.

To a large degree I am sympathetic to non-computational music, and have, 
lately been avoiding computers for my own composition and sound making.

> Computers, in the end, are used because comparatively speaking they are
> either cheaper and/or faster than the available alternatives of
> comparable scale. This is not to trivialise them at all (most of my life
> and work involves them, after all), but it is not to over-romanticise
> them either. They remain strictly a means to an end (unless your thing
> is designing them). However, it is clear that composers of "computer
> music" very intensely and understandably want their skills to be
> recognised and appreciated; easy enough with a physical instrument, a
> printed score and ready comparisons, but not so much when all you have
> to show for it is hunched shoulders over a laptop, or a CD and brief
> programme note. So, the more informed the public is about computing, the
> more they will appreciate those who are adepts.

I'm not sure this is relevant. Ultimately it is the musical result that 
is important, not recognition of other, necessary skills, or achievement 
of previously unachieved technical feats. Ultimately the requirements I 
am arguing for are relevant (I belive) to achieving desired musical ends.

> The only other way is if
> the programming seems truly "impossible" or mould-breaking - witness the
> admiration given to the Melodyne developers, for example. Sadly the
> public is so used to breakthroughs on a yearly basis, that soon enough
> they will be taken for granted along with GPS, mobile phones, wash
> cycles and cash dispensers.
> Of course, to write programs requires relevant skills; but that is true
> for all computing subjects. Much depends on one's ambition. An
> arpeggiator is an algorithmically defined thing, as is a drum machine;
> but they hardly need a CS degree to use. I suspect the key difference
> that takes one into "real" computing is the rare desire to deal with
> hard precise numbers rather than with intuitive/random twiddling and
> fiddling. That desire remains the exception rather than the rule, as I
> soon found out the one time I got to teach Csound to an undergraduate
> CMT group for a semester: "We don't have to learn any maths, do we?".

Reminds me of an argument I heard about between a classroom music 
teacher and a composer friend. The music teacher was adamant that 
mathematics has nothing to do with music.


More information about the music-dsp mailing list