From douglas at music.columbia.edu  Mon Sep  1 00:00:00 2008
From: douglas at music.columbia.edu (douglas repetto)
Date: Mon Sep  1 00:00:18 2008
Subject: [music-dsp] [admin] music-dsp FAQ
Message-ID: <20080901040000.E2C6A381FB041@music.columbia.edu>

Hi,

Just a reminder that if you are new to the list you should read the
music-dsp FAQ. It contains answers to both technical _and_
adminstrative questions that often come up on the list. If your question
appears in the FAQ it is safe to assume that it has been discussed on the
list many times in the past, and you should probably have a look through
the list archives before posting your question to the list.

http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html


Also of interest to new and not-so-new list members:

The music-dsp list archives
http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html

The music-dsp source code archive
http://www.musicdsp.org

music-dsp books and reviews
http://music.columbia.edu/cmc/music-dsp/dspbooks.html


All this and more at:
http://music.columbia.edu/cmc/music-dsp


Hasta la pasta,
douglas

(this is an automated message sent out on the 1st and 15th of each month)
From radarsat1 at gmail.com  Tue Sep  2 10:58:52 2008
From: radarsat1 at gmail.com (Stephen Sinclair)
Date: Tue Sep  2 10:59:20 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <1220174476.11291.2.camel@aluminium>
References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com>
	<1220174476.11291.2.camel@aluminium>
Message-ID: <9b3e2dc20809020758v66549ed1g63ccc20c611a63b@mail.gmail.com>

On Sun, Aug 31, 2008 at 5:21 AM, Jamie Bullock <jamie@postlude.co.uk> wrote:
>
> Hi Stephen,
>
> On Sat, 2008-08-23 at 13:28 -0400, Stephen Sinclair wrote:
>
>> Lately I've been wondering a lot about what programming languages are
>> useful for real-time audio other than C/C++.  I think the main reason
>> we stick to these languages is the deterministic memory management and
>> native code performance.  However, many dynamic languages actually
>> have quite well-optimized JIT compilers, so occasionally I have come
>> across an application, for example, that uses Java for real-time audio
>> synthesis.  (Though not necessarily as efficiently as a C program
>> might have done it, according to my CPU meter and the occasional
>> underrun!)  I often wonder which other dynamic languages might have
>> the potential for real-time audio.
> <snip>
>
> I don't really know very much about Erlang, so this may be way off the
> mark, but this came up today and may be of relevance:
>
> http://lambda-the-ultimate.org/node/2954

I noticed that too and thought of this thread!  ;-)

There do exist real-time extensions to some dynamic languages, they
would certainly be interesting to evaluate.  Fortunately the embedded
market creates a demand in this area.

Steve
From pau.arumi at barcelonamedia.org  Wed Sep  3 07:42:10 2008
From: pau.arumi at barcelonamedia.org (Pau =?ISO-8859-1?Q?Arum=ED?=)
Date: Wed Sep  3 07:42:21 2008
Subject: [music-dsp] Job offers at Barcelona Media: 3D audio developers
Message-ID: <1220442130.20683.10.camel@desktop>

Dear All, 
The following position may be of interest to you.

Please forward to anyone interested. Apologies for double posting.


==== About the Barcelona Media Audio Group ====

Fundacio Barcelona Media Universitat Pompeu Fabra is a research centre
created to foster the competitiveness of the Catalan and Spanish media
and communication industry through innovative research activities and
projects. BM promotes technology generation and development; research
and creativity; transfer of research results to industry; promotion of
the research results to society at large; training in all areas of
communication; and social awareness of the communication industry in a
culture of innovation. 

The Audio Group research embraces the whole chain of audiovisual
productions, focusing specially on 3D surround sound technologies, from
capturing, to postproduction, to exhibition. Two main general goals are
to automatize the workflow (by automatic audio adaptation to given 3D
scenes), and to make it easily adaptable to any final exhibition system
(surround 5.1, 7.1, 22.2, binaural or 3D stereo, etc.).

One strong line of research of the group is the reproduction of acoustic
fields in 3D virtual environments, using computer simulations to predict
what any source would sound like in a given virtual world.  The group
applies and improves the algorithms of Finite-Differences in Time-Domain
for low frequencies, Ray-Tracing for high frequencies. Such technologies
are then integrated in real-time, interactive multimedia systems. 

Audio group home page: http://www.barcelonamedia.org/linies/10/en

==== Profile ====

We are looking for one or more experienced software developers.  The
candidate should be self-motivated, results-oriented, and hard-working.
The candidate should preferably have a degree on Computer Science,
although other profiles might be taken into account.

==== Required skills ====

      * Software-engineering techniques and methods for developing large
        software systems (design patterns, agile methodologies, version
        control systems, etc. ).
      * Real-time programming techniques including lock-free and
        multi-threading.
      * Programming languages: C, C++, Python.
      * Operating systems: GNU/Linux and Mac OS X.
      * A keen sense for the aesthetics of code, documentation, and user
        interfaces. Thoroughness in all aspects of software development.
      * The ability and willingness to interact in a team, using agile
        methodologies.


Not required, but valuable skills:
      * Real-time multimedia environments (PureData, Max/MSP,
        Supercollider, CLAM, etc.).
      * Plugin architectures: LADSPA, LV2, VST, Audio Units, etc.
      * Knowledge of common protocols such as OSC, MIDI, etc.
      * Knowledge in digital signal processing and/or acoustics
      * 3D modeling: Blender or Maya or 3D studio
      * Qt
      * Scons 


==== What we offer ====

We offer an opportunity to work in creative projects in the field of 3D
audio for media productions, with applications ranging from 3D digital
cinema, to sports broadcasting, and videogames. 

Side opportunities: perform strategic research in a new promising
domain, working in a small-medium multidisciplinary team, collaborate
with people from the industry and from other academic research groups,
to establish contacts with the international audio research community
through the attendance to international conferences...


==== How to apply ====

To apply, send email to jobs@barcelonamedia.org / cc:
toni.mateos@barcelonamedia.org, pau.arumi@barcelonamedia.org with the
subject "3D Audio Jobs"

      * A brief presentation letter stating your interest in the offer.
      * A CV
      * Optionally, code samples (non open-source samples will be
        treated as confidential)


==== More background about Barcelona Media ====

BM grew from the Communication Station set up by Universitat Pompeu
Fabra in 2001. It is a member of the Catalan and Spanish network of
Technology Centres, and is the only one devoted to the Media sector.
BM?s trustees are representatives of the Media industry, the Catalan
Government, Barcelona City and four universities. BM has an extremely
strong record in European collaborative R&D and Innovation projects,
both as partner and coordinator. BM is currently involved in 14 EU
funded research projects in information and communication technologies
with over 5 million ? EC funding. BM was coordinator of an FP6 IP and 2
STREPs, including IP-RACINE which researched and developed digital
cinema technologies ?from scene to screen?. It is now co-ordinating the
FP7 ICT IP 2020 3D Media, developing 3D digital cinema and home
entertainment. Other directly relevant projects are IP SALERO
(?intelligent content? objects with context-aware behaviours), SEMEDIA
(Search Environments for MEDIA) and FP5 SPEED-FX (very high resolution
real-time graphic interaction for digital cinema). 


From batuhan at batuhanbozkurt.com  Wed Sep  3 11:46:31 2008
From: batuhan at batuhanbozkurt.com (Batuhan Bozkurt)
Date: Wed Sep  3 11:46:51 2008
Subject: [music-dsp] Audio hashing/acoustic fingerprint techniques
Message-ID: <48BEB157.4070102@batuhanbozkurt.com>

Hello all,

I'm searching for ways of machine fingerprinting of music. I'm thinking 
of a system, where the generated fingerprint of the musical data(I'm 
talking about full music tracks here, not individual samples) from a 
source will then be added to a database of other fingerprints. Then one 
should be able to find out which piece, a given portion of sound belongs 
to(by fingerprinting it with the same algorithm and comparing it to the 
ones already in the database). It should be immune to some lossy 
compression techniques(within limits of course!) and cropping(the longer 
portion of it we have a hand, the better of course).

So say we have the whole fingerprint of piece X in our database(along 
with many others). I want to be able to identify a lossily compressed 
and cropped sample of music as piece X by comparing its musical 
fingerprint with the ones already in the database.

Do such systems exist? If there are any, can someone point me to them? 
Any thoughts on the issue will also be appreciated.

Thanks.

BB.
From tobe at stonecodex.com  Wed Sep  3 11:57:13 2008
From: tobe at stonecodex.com (t o b e)
Date: Wed Sep  3 11:57:21 2008
Subject: [music-dsp] Audio hashing/acoustic fingerprint techniques
In-Reply-To: <48BEB157.4070102@batuhanbozkurt.com>
References: <48BEB157.4070102@batuhanbozkurt.com>
Message-ID: <48BEB3D9.8010300@stonecodex.com>

 > Do such systems exist?

Yes they do.. lots of them..

http://en.wikipedia.org/wiki/Acoustic_fingerprint

I don't believe there are any truly open implementation out there but 
MusicDNS (the one preferred by MusicBrainz) is largely open and would 
seem to be a good start.

--
t o b e

Batuhan Bozkurt wrote:
> Hello all,
>
> I'm searching for ways of machine fingerprinting of music. I'm 
> thinking of a system, where the generated fingerprint of the musical 
> data(I'm talking about full music tracks here, not individual samples) 
> from a source will then be added to a database of other fingerprints. 
> Then one should be able to find out which piece, a given portion of 
> sound belongs to(by fingerprinting it with the same algorithm and 
> comparing it to the ones already in the database). It should be immune 
> to some lossy compression techniques(within limits of course!) and 
> cropping(the longer portion of it we have a hand, the better of course).
>
> So say we have the whole fingerprint of piece X in our database(along 
> with many others). I want to be able to identify a lossily compressed 
> and cropped sample of music as piece X by comparing its musical 
> fingerprint with the ones already in the database.
>
> Do such systems exist? If there are any, can someone point me to them? 
> Any thoughts on the issue will also be appreciated.
>
> Thanks.
>
> BB.
> -- 
> dupswapdrop -- the music-dsp mailing list and website: subscription 
> info, FAQ, source code archive, list archive, book reviews, dsp links 
> http://music.columbia.edu/cmc/music-dsp 
> http://music.columbia.edu/mailman/listinfo/music-dsp
>

From robert.lorentz at gmail.com  Sun Sep  7 09:19:37 2008
From: robert.lorentz at gmail.com (Robert Lorentz)
Date: Sun Sep  7 09:19:52 2008
Subject: [music-dsp] New to list with startup type questions..
Message-ID: <225813c30809070619o45456b96rb520b36b433460de@mail.gmail.com>

Hi everyone,

I was referred to this list by someone over on the synth diy list
because of my interest in digital reverb (offtopic over there, it's an
analog list mainly).  My interests for music creation are restricted
to 'non-computer', and up until now I haven't had any interest in
anything but analog stuff.  However, reverb is something that should
really be done in the realm of DSP for many obvious reasons...

What I'm mostly looking for is some advice for getting started on a
project like this, because I'm not familiar with how DSP is done in a
relevant modern way.  It seems like FPGA may be the way to go, and
I've wanted a reason to dive in to them to get some experience with
them.  What FPGA or series of FPGA's would be good for this type of
project?

My criteria would be that I prefer to work in Mac OS X (but *can* do
Windows or Linux), hugely prefer an environment that I can simulate in
software for development, and would like to find a platform that is
powerful and represents the real world but isn't prohibitively
expensive.  I am sure that there are 'usual suspects' to recommend
here and appreciate hearing about those :)

I was originally hoping to find some existing work to expand on, so if
you can recommend any that would also be great.  Or, if there are any
authoritative resources, papers, or even books on the topic of digital
reverb that would be great.  I understand the 'black art' nature of
reverb and that it's non-trivial to get something working out that
sounds good.  That's not a big deal as I'm looking for a worthwhile
project in this domain

Thanks, and look forward to following traffic on this list!

Robert
From cournape at gmail.com  Sun Sep  7 11:26:13 2008
From: cournape at gmail.com (David Cournapeau)
Date: Sun Sep  7 11:26:30 2008
Subject: [music-dsp] New to list with startup type questions..
In-Reply-To: <225813c30809070619o45456b96rb520b36b433460de@mail.gmail.com>
References: <225813c30809070619o45456b96rb520b36b433460de@mail.gmail.com>
Message-ID: <5b8d13220809070826p6ba882cdt9a3277623a22ab11@mail.gmail.com>

On Sun, Sep 7, 2008 at 10:19 PM, Robert Lorentz
<robert.lorentz@gmail.com> wrote:
>
> What I'm mostly looking for is some advice for getting started on a
> project like this, because I'm not familiar with how DSP is done in a
> relevant modern way.  It seems like FPGA may be the way to go, and
> I've wanted a reason to dive in to them to get some experience with
> them.  What FPGA or series of FPGA's would be good for this type of
> project?
>

Hi Robert,

    I can't help you for the hardware side, but for the 'theoritical'
aspect of digital revert, a good reference is the serie of articles from
Dattoro (who designed most of the Ensoniq Dp4, some lexicon and some emu
stuff too):

http://www.stanford.edu/~dattorro/music.html

The three effect design articles in the Journal of AES are particularly
interesting (one of them focus on reverberation based on filters).
Another, more modern approach is convolution based: this one is more
"brute force", and the difficulty is to make the convolution run fast
and with low latency (with various schemes to split the impulse response
of the room into parts to balance between efficiency and latency). But I
don't know much about those, and do not know of any useful reference
(other will probably jump in at this point).

cheers,

David
From mark.plumbley at elec.qmul.ac.uk  Mon Sep  8 05:33:39 2008
From: mark.plumbley at elec.qmul.ac.uk (Mark Plumbley)
Date: Mon Sep  8 05:34:10 2008
Subject: [music-dsp] ICArn 2008,
	25-26 Sept 2008: Registration Reminder (12 Sept 2008)
Message-ID: <9A6BBBBE2AAD6746A6D961B57357426236F6E45E@staff-mail2.vpn.elec.qmul.ac.uk>


    *** Registration Deadline 12 September 2008 ***

                      ICArn 2008
    ICA Research Network International Workshop 2008

         Liverpool UK,  25-26 September 2008

                     www.icarn.org
      www.elec.qmul.ac.uk/icarn/events/icarnw08/


The 2008 ICA Research Network Workshop will be held at
the University of Liverpool, UK covering the latest developments
and techniques in the area of source separation and ICA.

The ICA Research Network is sponsored by the UK Engineering
and Physical Sciences Research Council (EPSRC), and is aimed
at improving communications in the area of Blind Source
Separation (BSS) and Independent Component Analysis (ICA).

Topics

The workshop will feature invited talks and technical
presentations (oral and poster), which will be included in the
registration. Papers will be presented in the area of
independent component analysis and source separation, including
and architectures, theory and novel methods, as well as
applications in audio, image processing, biomedical engineering
and communications.

Registration

Registration costs will include attendance in all the sessions,
a copy of the bound proceedings, mid-morning and mid-afternoon
refreshments as well as buffet lunches on both days, and the
Workshop dinner on the evening of 25 September 2008.

Important Dates/Deadlines

Registration deadline:      12 September 2008
Workshop:                25-26 September 2008

Website: www.elec.qmul.ac.uk/icarn/events/icarnw08/

Programme: www.elec.qmul.ac.uk/icarn/events/icarnw08/programme.html

ICA Research Network: www.icarn.org

--
Dr Mark D Plumbley
Electronic Engineering and Computer Science
Queen Mary University of London
Mile End Road, London E1 4NS, UK
Tel: +44 (0)20 7882 7518
Fax: +44 (0)20 7882 7997
Email: mark.plumbley@elec.qmul.ac.uk
http://www.elec.qmul.ac.uk/people/markp/
From mark.plumbley at elec.qmul.ac.uk  Tue Sep  9 05:44:47 2008
From: mark.plumbley at elec.qmul.ac.uk (Mark Plumbley)
Date: Tue Sep  9 05:45:12 2008
Subject: [music-dsp] PhD Studentship in Compressed Sensing of Audio Scenes
 (Ddln: 19 Sept 2008)
Message-ID: <9A6BBBBE2AAD6746A6D961B57357426236F6E4C8@staff-mail2.vpn.elec.qmul.ac.uk>

[Apologies for cross-posting. Please forward to any potentially
interested candidates. Thanks, Mark.]
----------------------------------------------------------------

   PhD Studentship in Compressed Sensing of Audio Scenes

        (Application deadline: 19 September 2008)


Applications are invited for a 3-year PhD studentship to
investigate the analysis of musical and environmental audio,
using the technique of compressed sensing, to commence in
October 2008, or as soon as possible thereafter.

Compressed sensing is a new technique concerned with reducing
the number of measurements necessary to reconstruct an object.
It is based on the principle that the object has some underlying
sparse representation, i.e. that it can be described using a
small number of non-zero coefficients. Audio scenes may be
sparse in the time domain, if each source sounds only rarely; in
the frequency domain, if the sound sources use a small number of
frequencies; or in the spatial domain, if there are only a small
number of discrete sound sources. The aim of the PhD project is
to investigate compressed sensing techniques to extract audio
from such sound scenes, and compare with existing methods for
audio source separation and audio enhancement.

This PhD will be supervised by Dr Mark D Plumbley
(www.elec.qmul.ac.uk/people/markp), and will take place in the
School of Electronic Engineering and Computer Science at Queen
Mary University of London, within the world-leading Centre for
Digital Music (although the research is not limited to musical
audio). The work will form part of a new programme of research
in "Machine Listening using Sparse Representations", supported
by a Leadership Fellowship from the UK Engineering and Physical
Sciences Research Council (EPSRC). This is to be a concerted
programme of research in machine listening (the automatic
analysis and understanding of sounds from the world around us),
using methods from sparse representations, and to establish
machine listening as a key enabling technology to improve our
ability to interact with the world.

Applicants must have a first degree in electronic engineering,
mathematical science, physics, statistics, computer science, or
allied disciplines (minimum: good 2:1 or equivalent), and
excellent mathematical and programming skills. Previous
experience of digital signal processing of audio is desirable,
although not mandatory.

The 3-year studentship will comprise full fees for "home"
(UK/EU) students and an annual stipend commencing at ?14,600
including London Allowance (stipends are exempt of UK tax),
subject to satisfactory progress.

For informal enquiries, please contact Dr Mark D Plumbley,
Queen Mary, University of London, mark.plumbley@elec.qmul.ac.uk.

For application forms and information on how to apply, see
http://www.elec.qmul.ac.uk/study/phd/res-stud.htm.

Deadline: 19 September 2008

--
Dr Mark D Plumbley
Electronic Engineering and Computer Science
Queen Mary University of London
Mile End Road, London E1 4NS, UK
Tel: +44 (0)20 7882 7518
Fax: +44 (0)20 7882 7997
Email: mark.plumbley@elec.qmul.ac.uk
http://www.elec.qmul.ac.uk/people/markp/
From spambait1000006 at cox.net  Thu Sep 11 22:55:41 2008
From: spambait1000006 at cox.net (spambait1000006@cox.net)
Date: Thu Sep 11 22:59:30 2008
Subject: [music-dsp] Matlab Tools and other useful stuff
In-Reply-To: <B467D49BB7D42248B54CB70D85DFAFAC6C5B6A07C9@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <47C2DD7E.2030402@web.de>
	<B467D49BB7D42248B54CB70D85DFAFAC6C5B6A074D@NA-EXMSG-C103.redmond.corp.microsoft.com>
	<b6105e870802250818v410b49f8xd8ff4a88ea6ccbdb@mail.gmail.com>
	<8948-Mon25Feb2008170652+0000-jpff@codemist.co.uk>
	<B467D49BB7D42248B54CB70D85DFAFAC6C5B6A07C9@NA-EXMSG-C103.redmond.corp.microsoft.com>
Message-ID: <20080911121427.A28078@egads.ronnet.moc>

I just looked up REDUCE ( http://reduce-algebra.com )and there seems to be 
a ~$99/80 pound sterling (from two different venders linked off the REDUCE 
site --One of which is from www.codemist.co.uk biased? Maybe...) 
"personal" version for Mac, windows and linux only. Appearantly the full 
version includes (lisp?) source code and is also available for sun/silicon 
graphics/rs6000/cray & friends.

There is a demo version with no garbage collector. It sould work for day 
to day "I could do this but don't want to" calulactions well enough to 
tell if it want the paid version.

REDUCE was the first CAS I used and it was easy enough to learn for what I 
needed at the time (which probably wasn't much).

CR

On Mon, 25 Feb 2008, Ian Lewis wrote:
> $695US is not expensive? I know the dollar has tanked, but come on...
>
>> -----Original Message-----
>> From: music-dsp-bounces@music.columbia.edu On Behalf Of jpff@codemist.co.uk
>> Sent: Monday, February 25, 2008 12:07 PM
>> To: A discussion list for music-related DSP
>> Cc: music-dsp@music.columbia.edu
>> Subject: Re: [music-dsp] Matlab Tools and other useful stuff
>>
>> I am biased, but I always use REDUCE for algebraic stuff.  Not free,
>> but not expensive.
>> ==John ffitch
From k.s.matheussen at notam02.no  Sun Sep 14 11:03:38 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Sun Sep 14 11:03:57 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <20080824154821.2C921366411D8@music.columbia.edu>
References: <20080824154821.2C921366411D8@music.columbia.edu>
Message-ID: <Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>


Sorry for late reply.


Michael Gogins:
> 
> First, let me see if I understand how snd-rt works. The musician writes 
> Scheme code. He or she can declare special blocks of real-time 
> statements. These blocks are compiled using the Stalin compiler into 
> highly optimized C code that uses your real-time safe garbage collector. 
> Thus, semantically the musician is writing both the high-level 
> composition and the low-level DSP operations, including unit generators, 
> in Scheme. But inside the system, that optimized C code is still 
> compiled by the GNU C compiler into object code.
> 
> Please correct me if I've misunderstood...
> 

That sounds right.


> So, in ALL of these systems, the running unit generators are C or C++ code.
> 
> If that's correct, my point is, why not just stick with C++ and have 
> that compiled inside the system? Of course functional programming offers 
> certain advantages, but staying in C++, which is immensely powerful and 
> has the widest selection of libraries, has its own large advantages.
> 

Scheme is a much higher level language than C++, and you get away
with writing a lot less code to do the same things.
For example, this is the implementation of a complete polyphonic soft
synth:

(<rt-stalin>
 (while #t
   (wait-midi :command note-on
     (spawn
       (define osc (make-oscil :freq (midi-to-freq (midi-note))))
       (define player (spawn (block (out (* (midi-vol)
					    (oscil osc))))))
       (wait-midi :command note-off :note (midi-note))
       (stop player)))))


The C code which the above scheme code is compiled down to
is quite optimal, thanks to the Stalin compiler, and very
hard to write manually.

Also, to run and stop the above code, you just have to place
the cursor above the code and press a key
combination in a lisp editor. About two seconds later the
softsynth is running (Stalin use relatively long time to
compile into C). There's another key combination to stop
the instrument.

If using C++, you have to compile, run and stop a separate
program, plus connecting midi and audio for each time to
the new program.
From k.s.matheussen at notam02.no  Sun Sep 14 11:13:53 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Sun Sep 14 11:14:09 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>
References: <20080824154821.2C921366411D8@music.columbia.edu>
	<Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>
Message-ID: <Pine.LNX.4.58.0809141709380.5612@notam02.uio.no>

On Sun, 14 Sep 2008, Kjetil S. Matheussen wrote:

> > So, in ALL of these systems, the running unit generators are C or C++ code.
> > 
> > If that's correct, my point is, why not just stick with C++ and have 
> > that compiled inside the system? Of course functional programming offers 
> > certain advantages, but staying in C++, which is immensely powerful and 
> > has the widest selection of libraries, has its own large advantages.
> > 
> 
> Scheme is a much higher level language than C++, and you get away
> with writing a lot less code to do the same things.

And I forgot to add that you can use C and C++ libraries in 
high level languages such as scheme/ML/lua/faust/etc. as well,
so that wide selection of libraries you were talking about
is not limited to C and C++. For snd-rt, it's
also possible to write C functions in the S-expression
format, which you can intertwine with scheme code and
call directly from scheme, so you've still got the full
low-level power.

From radarsat1 at gmail.com  Sun Sep 14 12:07:47 2008
From: radarsat1 at gmail.com (Stephen Sinclair)
Date: Sun Sep 14 12:07:57 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>
References: <20080824154821.2C921366411D8@music.columbia.edu>
	<Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>
Message-ID: <9b3e2dc20809140907m637a0f24wf68b06e5d5661c8@mail.gmail.com>

On Sun, Sep 14, 2008 at 11:03 AM, Kjetil S. Matheussen
<k.s.matheussen@notam02.no> wrote:
>
> Sorry for late reply.
>
>
> Michael Gogins:
>>
>> First, let me see if I understand how snd-rt works. The musician writes
>> Scheme code. He or she can declare special blocks of real-time
>> statements. These blocks are compiled using the Stalin compiler into
>> highly optimized C code that uses your real-time safe garbage collector.
>> Thus, semantically the musician is writing both the high-level
>> composition and the low-level DSP operations, including unit generators,
>> in Scheme. But inside the system, that optimized C code is still
>> compiled by the GNU C compiler into object code.
>>
>> Please correct me if I've misunderstood...
>>
>
> That sounds right.
>
>
>> So, in ALL of these systems, the running unit generators are C or C++ code.
>>
>> If that's correct, my point is, why not just stick with C++ and have
>> that compiled inside the system? Of course functional programming offers
>> certain advantages, but staying in C++, which is immensely powerful and
>> has the widest selection of libraries, has its own large advantages.
>>
>
> Scheme is a much higher level language than C++, and you get away
> with writing a lot less code to do the same things.
> For example, this is the implementation of a complete polyphonic soft
> synth:
>
> (<rt-stalin>
>  (while #t
>   (wait-midi :command note-on
>     (spawn
>       (define osc (make-oscil :freq (midi-to-freq (midi-note))))
>       (define player (spawn (block (out (* (midi-vol)
>                                            (oscil osc))))))
>       (wait-midi :command note-off :note (midi-note))
>       (stop player)))))
>
>
> The C code which the above scheme code is compiled down to
> is quite optimal, thanks to the Stalin compiler, and very
> hard to write manually.

This is really amazing to me, thanks!  I haven't heard of the Stalin
compiler before.  I'm definitely going to spend some time with this.
I've been wanting to do more lisp-ish programming lately anyways.  ;-)


Steve
From gogins at pipeline.com  Sun Sep 14 13:05:11 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Sun Sep 14 13:05:30 2008
Subject: [music-dsp] Re: programming languages for real-time audio
Message-ID: <158168.1221411917606.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net>

Thanks for your response. I will be trying snd-rt, and I will let you know my responses.

It is, of course, possible to encapsulate and automate the compiling/linking steps, and the input/output drivers, in a C++ based system. So, the main thing I am interested in is just how much convenience and expressivity using Scheme buys.

Thanks again,
Mike

-----Original Message-----
>From: "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
>Sent: Sep 14, 2008 11:03 AM
>To: music-dsp@music.columbia.edu
>Subject: [music-dsp] Re: programming languages for real-time audio
>
>
>Sorry for late reply.
>
>
>Michael Gogins:
>> 
>> First, let me see if I understand how snd-rt works. The musician writes 
>> Scheme code. He or she can declare special blocks of real-time 
>> statements. These blocks are compiled using the Stalin compiler into 
>> highly optimized C code that uses your real-time safe garbage collector. 
>> Thus, semantically the musician is writing both the high-level 
>> composition and the low-level DSP operations, including unit generators, 
>> in Scheme. But inside the system, that optimized C code is still 
>> compiled by the GNU C compiler into object code.
>> 
>> Please correct me if I've misunderstood...
>> 
>
>That sounds right.
>
>
>> So, in ALL of these systems, the running unit generators are C or C++ code.
>> 
>> If that's correct, my point is, why not just stick with C++ and have 
>> that compiled inside the system? Of course functional programming offers 
>> certain advantages, but staying in C++, which is immensely powerful and 
>> has the widest selection of libraries, has its own large advantages.
>> 
>
>Scheme is a much higher level language than C++, and you get away
>with writing a lot less code to do the same things.
>For example, this is the implementation of a complete polyphonic soft
>synth:
>
>(<rt-stalin>
> (while #t
>   (wait-midi :command note-on
>     (spawn
>       (define osc (make-oscil :freq (midi-to-freq (midi-note))))
>       (define player (spawn (block (out (* (midi-vol)
>					    (oscil osc))))))
>       (wait-midi :command note-off :note (midi-note))
>       (stop player)))))
>
>
>The C code which the above scheme code is compiled down to
>is quite optimal, thanks to the Stalin compiler, and very
>hard to write manually.
>
>Also, to run and stop the above code, you just have to place
>the cursor above the code and press a key
>combination in a lisp editor. About two seconds later the
>softsynth is running (Stalin use relatively long time to
>compile into C). There's another key combination to stop
>the instrument.
>
>If using C++, you have to compile, run and stop a separate
>program, plus connecting midi and audio for each time to
>the new program.
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From gogins at pipeline.com  Sun Sep 14 13:06:13 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Sun Sep 14 13:06:24 2008
Subject: [music-dsp] Re: programming languages for real-time audio
Message-ID: <23239160.1221411974186.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net>

I didn't know you could intermix code like that. It does add something.

Regards,
Mike

-----Original Message-----
>From: "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
>Sent: Sep 14, 2008 11:13 AM
>To: "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
>Cc: music-dsp@music.columbia.edu
>Subject: [music-dsp] Re: programming languages for real-time audio
>
>On Sun, 14 Sep 2008, Kjetil S. Matheussen wrote:
>
>> > So, in ALL of these systems, the running unit generators are C or C++ code.
>> > 
>> > If that's correct, my point is, why not just stick with C++ and have 
>> > that compiled inside the system? Of course functional programming offers 
>> > certain advantages, but staying in C++, which is immensely powerful and 
>> > has the widest selection of libraries, has its own large advantages.
>> > 
>> 
>> Scheme is a much higher level language than C++, and you get away
>> with writing a lot less code to do the same things.
>
>And I forgot to add that you can use C and C++ libraries in 
>high level languages such as scheme/ML/lua/faust/etc. as well,
>so that wide selection of libraries you were talking about
>is not limited to C and C++. For snd-rt, it's
>also possible to write C functions in the S-expression
>format, which you can intertwine with scheme code and
>call directly from scheme, so you've still got the full
>low-level power.
>
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From k.s.matheussen at notam02.no  Sun Sep 14 13:21:55 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Sun Sep 14 13:22:10 2008
Subject: [music-dsp] Re: Re: programming languages for real-time audio
In-Reply-To: <20080914170545.867543C5DAAC2@music.columbia.edu>
References: <20080914170545.867543C5DAAC2@music.columbia.edu>
Message-ID: <Pine.LNX.4.58.0809141914410.5612@notam02.uio.no>


Michael Gogins:
> 
> Thanks for your response. I will be trying snd-rt, and I will let you know my responses.
> 

You should know that the stalin part is quite new, so it is not 
available in the snd-ls package yet. (I have to fix that).

So you must use a recent version of snd instead. Start
by evaluating (load-from-path "rt-engine.scm")

Also, compiling the stalin compiler can take some time. (leave it
over night). In case your machine gives up while compiling stalin,
ask me for a binary. Hold on, here is a binary:
http://www.notam02.no/~kjetism/stalin.gz
Copy it into the include directory.


> I didn't know you could intermix code like that. It does add something.

It's very convenient since you don't have to restart snd while
developing. The rt part of snd-rt is written like that, including
the sound engine.

From gogins at pipeline.com  Sun Sep 14 14:55:09 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Sun Sep 14 14:55:24 2008
Subject: [music-dsp] Re: Re: programming languages for real-time audio
Message-ID: <3895445.1221418509593.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>

Thanks,
Mike

You had a whole Windows package -- that doesn't do the whole job?

Regards,
Mike

-----Original Message-----
>From: "Kjetil S. Matheussen" <k.s.matheussen@notam02.no>
>Sent: Sep 14, 2008 1:21 PM
>To: music-dsp@music.columbia.edu
>Subject: [music-dsp] Re: Re: programming languages for real-time audio
>
>
>Michael Gogins:
>> 
>> Thanks for your response. I will be trying snd-rt, and I will let you know my responses.
>> 
>
>You should know that the stalin part is quite new, so it is not 
>available in the snd-ls package yet. (I have to fix that).
>
>So you must use a recent version of snd instead. Start
>by evaluating (load-from-path "rt-engine.scm")
>
>Also, compiling the stalin compiler can take some time. (leave it
>over night). In case your machine gives up while compiling stalin,
>ask me for a binary. Hold on, here is a binary:
>http://www.notam02.no/~kjetism/stalin.gz
>Copy it into the include directory.
>
>
>> I didn't know you could intermix code like that. It does add something.
>
>It's very convenient since you don't have to restart snd while
>developing. The rt part of snd-rt is written like that, including
>the sound engine.
>
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From k.s.matheussen at notam02.no  Sun Sep 14 15:12:06 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Sun Sep 14 15:12:22 2008
Subject: [music-dsp] Re: Re: Re: programming languages for real-time audio
In-Reply-To: <20080914185535.DCBAF3C64CC69@music.columbia.edu>
References: <20080914185535.DCBAF3C64CC69@music.columbia.edu>
Message-ID: <Pine.LNX.4.58.0809142104310.5612@notam02.uio.no>


Michael Gogins:
> You had a whole Windows package -- that doesn't do the whole job?
> 

Unfortunately not. Newer versions of snd-rt uses a lot of posix stuff
(mutexes, semaphores, threads, <ucontext.h>-based coroutines), which
are not available in MinGW (as far as I know), so you must use Linux.
MacosX is possible as well, but no one has compiled the packages
for macosx as far as I know (again), so it probably doesn't work
right away.

You can do a lot of cool stuff with the windows package though,
but only the "RT" compiler is supported in it, which doesn't use
the garbage collector. So it's a bit limited compared to
what you can do in linux.
From douglas at music.columbia.edu  Mon Sep 15 00:00:00 2008
From: douglas at music.columbia.edu (douglas repetto)
Date: Mon Sep 15 00:00:04 2008
Subject: [music-dsp] [admin] music-dsp FAQ
Message-ID: <20080915040000.D76C53C875935@music.columbia.edu>

Hi,

Just a reminder that if you are new to the list you should read the
music-dsp FAQ. It contains answers to both technical _and_
adminstrative questions that often come up on the list. If your question
appears in the FAQ it is safe to assume that it has been discussed on the
list many times in the past, and you should probably have a look through
the list archives before posting your question to the list.

http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html


Also of interest to new and not-so-new list members:

The music-dsp list archives
http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html

The music-dsp source code archive
http://www.musicdsp.org

music-dsp books and reviews
http://music.columbia.edu/cmc/music-dsp/dspbooks.html


All this and more at:
http://music.columbia.edu/cmc/music-dsp


Hasta la pasta,
douglas

(this is an automated message sent out on the 1st and 15th of each month)
From richarddobson at blueyonder.co.uk  Mon Sep 15 16:46:01 2008
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Mon Sep 15 16:48:36 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>
References: <20080824154821.2C921366411D8@music.columbia.edu>
	<Pine.LNX.4.58.0809141650020.5612@notam02.uio.no>
Message-ID: <48CEC989.1020209@blueyonder.co.uk>

Kjetil S. Matheussen wrote:
>,,
> For example, this is the implementation of a complete polyphonic soft
> synth:
> 
> (<rt-stalin>
>  (while #t
>    (wait-midi :command note-on
>      (spawn
>        (define osc (make-oscil :freq (midi-to-freq (midi-note))))
>        (define player (spawn (block (out (* (midi-vol)
> 					    (oscil osc))))))
>        (wait-midi :command note-off :note (midi-note))
>        (stop player)))))
> 
> 

Out of interest, which bit of this code handles voice assignment 
(stealing, etc) for machines with a fixed upper limit of polyphony?

Richard Dobson

From k.s.matheussen at notam02.no  Wed Sep 17 06:55:40 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Wed Sep 17 06:56:00 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <20080914150408.477E33C56370D@music.columbia.edu>
References: <20080914150408.477E33C56370D@music.columbia.edu>
Message-ID: <Pine.LNX.4.58.0809171230500.28797@notam02.uio.no>


Richard Dobson:
> Kjetil S. Matheussen wrote:
> >,,
> > For example, this is the implementation of a complete polyphonic soft
> > synth:
> > 
> > (<rt-stalin>
> >  (while #t
> >    (wait-midi :command note-on
> >      (spawn
> >        (define osc (make-oscil :freq (midi-to-freq (midi-note))))
> >        (define player (spawn (block (out (* (midi-vol)
> >                                             (oscil osc))))))
> >        (wait-midi :command note-off :note (midi-note))
> >        (stop player)))))
> > 
> > 
> 
> Out of interest, which bit of this code handles voice assignment 
> (stealing, etc) for machines with a fixed upper limit of polyphony?
> 

The code does not use any special kind of hardware, and
the number of simultanious voices are only limited by CPU.

The "out" macro does the mixing, and the "block" macro makes
sure efficient inner loops are being created.

To make this work, the scheduler tells the coroutines which are
currently running inside a "block" block to produce so and
so many samples, where "so and so" most of the time would
be equal to the number of frames placed in the soundcard
buffer before refill. Coroutines are created by the "spawn"
macro.
From richarddobson at blueyonder.co.uk  Wed Sep 17 07:43:03 2008
From: richarddobson at blueyonder.co.uk (Richard Dobson)
Date: Wed Sep 17 07:45:39 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <Pine.LNX.4.58.0809171230500.28797@notam02.uio.no>
References: <20080914150408.477E33C56370D@music.columbia.edu>
	<Pine.LNX.4.58.0809171230500.28797@notam02.uio.no>
Message-ID: <48D0ED47.9070305@blueyonder.co.uk>

Kjetil S. Matheussen wrote:
> Richard Dobson:
>> Kjetil S. Matheussen wrote:
>>> ,,
>>> For example, this is the implementation of a complete polyphonic soft
>>> synth:
..
>> Out of interest, which bit of this code handles voice assignment 
>> (stealing, etc) for machines with a fixed upper limit of polyphony?
>>
> 
> The code does not use any special kind of hardware, and
> the number of simultanious voices are only limited by CPU.
> 

I am not concerned with CPU load per se, but with amplitude scaling, 
which needs to take the number of voices into account (eg log(N)). 
Setting a limit on N make that computable. That is as much the reason 
for setting such a limit, as available compute cycles. Put another way, 
I do not think that a machine with no fixed upper limit of polyphony can 
be implemented as a real-time process, without the user constantly 
having to change Volume!

Richard Dobson


From k.s.matheussen at notam02.no  Wed Sep 17 07:57:56 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Wed Sep 17 07:58:14 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <20080917105609.F1F413D4CDD0B@music.columbia.edu>
References: <20080917105609.F1F413D4CDD0B@music.columbia.edu>
Message-ID: <Pine.LNX.4.58.0809171353370.28797@notam02.uio.no>


Richard Dobson:
> > Richard Dobson:
> >> Kjetil S. Matheussen wrote:
> >>> ,,
> >>> For example, this is the implementation of a complete polyphonic soft
> >>> synth:
> ..
> >> Out of interest, which bit of this code handles voice assignment 
> >> (stealing, etc) for machines with a fixed upper limit of polyphony?
> >>
> > 
> > The code does not use any special kind of hardware, and
> > the number of simultanious voices are only limited by CPU.
> > 
> 
> I am not concerned with CPU load per se, but with amplitude scaling, 
> which needs to take the number of voices into account (eg log(N)). 
> Setting a limit on N make that computable. That is as much the reason 
> for setting such a limit, as available compute cycles. Put another way, 
> I do not think that a machine with no fixed upper limit of polyphony can 
> be implemented as a real-time process, without the user constantly 
> having to change Volume!

Well, the example just shows how to make a _minimal_ soft synth.
There's nothing hindering you from setting a limit on the number
of voices, scale the volume, using an envelope, adding reverb, etc.

From k.s.matheussen at notam02.no  Wed Sep 17 08:01:10 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Wed Sep 17 08:01:26 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <Pine.LNX.4.58.0809171353370.28797@notam02.uio.no>
References: <20080917105609.F1F413D4CDD0B@music.columbia.edu>
	<Pine.LNX.4.58.0809171353370.28797@notam02.uio.no>
Message-ID: <Pine.LNX.4.58.0809171359400.29943@notam02.uio.no>

On Wed, 17 Sep 2008, Kjetil S. Matheussen wrote:

> 
> Richard Dobson:
> > > Richard Dobson:
> > >> Kjetil S. Matheussen wrote:
> > >>> ,,
> > >>> For example, this is the implementation of a complete polyphonic soft
> > >>> synth:
> > ..
> > >> Out of interest, which bit of this code handles voice assignment 
> > >> (stealing, etc) for machines with a fixed upper limit of polyphony?
> > >>
> > > 
> > > The code does not use any special kind of hardware, and
> > > the number of simultanious voices are only limited by CPU.
> > > 
> > 
> > I am not concerned with CPU load per se, but with amplitude scaling, 
> > which needs to take the number of voices into account (eg log(N)). 
> > Setting a limit on N make that computable. That is as much the reason 
> > for setting such a limit, as available compute cycles. Put another way, 
> > I do not think that a machine with no fixed upper limit of polyphony can 
> > be implemented as a real-time process, without the user constantly 
> > having to change Volume!
> 
> Well, the example just shows how to make a _minimal_ soft synth.

Okay, I used the word "complete". Maybe I should have written "working"
instead.

From darren.landrum at sbcglobal.net  Fri Sep 19 14:15:01 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Fri Sep 19 14:16:03 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com>
References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com>	<860667A7-7566-4042-B2B8-842B46274A9A@gmail.com>	<001501c9056e$97774f90$0201a8c0@family>
	<9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com>
Message-ID: <48D3EC25.1090507@sbcglobal.net>

Stephen Sinclair wrote:
> On Sat, Aug 23, 2008 at 6:21 PM, victor <Victor.Lazzarini@nuim.ie> wrote:
>> I think Mike's reply was probably the bottom line: if you want speed
>> and efficiency, it has to be C or C++ (or a similar compiled language).
>> Java appears to be the alternative, but not as efficient.
> 
> Of course, I'll grudgingly accept the status quo that C or C++ is the
> only real answer here.

Has anyone taken a close look at Ocaml for real-time DSP?

http://caml.inria.fr/about/index.en.html

I'm into functional languages, having had a lot of fun with Faust 
lately, and I've been interested in a functional language for more 
general synth/effect plug-in writing.

Thanks for the very interesting discussion.

By the way, here's the link to Faust, just in case:

http://faust.grame.fr/index.php

I don't recall if it got mentioned yet. It's a functional language for 
DSP that compiled to efficient C/C++ code.

Regards,
Darren Landrum
From darren.landrum at sbcglobal.net  Fri Sep 19 14:30:53 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Fri Sep 19 14:31:53 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <48D3EC25.1090507@sbcglobal.net>
References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com>	<860667A7-7566-4042-B2B8-842B46274A9A@gmail.com>	<001501c9056e$97774f90$0201a8c0@family>	<9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com>
	<48D3EC25.1090507@sbcglobal.net>
Message-ID: <48D3EFDD.5000004@sbcglobal.net>

Darren Landrum wrote:
> Stephen Sinclair wrote:
>> On Sat, Aug 23, 2008 at 6:21 PM, victor <Victor.Lazzarini@nuim.ie> wrote:
>>> I think Mike's reply was probably the bottom line: if you want speed
>>> and efficiency, it has to be C or C++ (or a similar compiled language).
>>> Java appears to be the alternative, but not as efficient.
>>
>> Of course, I'll grudgingly accept the status quo that C or C++ is the
>> only real answer here.
> 
> Has anyone taken a close look at Ocaml for real-time DSP?
> 
> http://caml.inria.fr/about/index.en.html

I guess I should clarify: I'm aware that FFTW is written using Ocaml, 
but I'm under the impression that the part written in Ocaml is a code 
generator that makes C code (not unlike Faust, actually). Someone please 
correct me if this is wrong.

What I'm really curious about is if anyone ever managed to make a 
plug-in or other music-DSP-type program in Ocaml. Thank you!

Regards,
Darren Landrum
From gogins at pipeline.com  Fri Sep 19 16:22:25 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Fri Sep 19 16:22:50 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>

Yes, I have examined OCaml and I have played with Faust.

Faust may conceivably be useful to some persons. For most people, I think it would be just about as easy to write code using a class library such as the STK. However, I hope that Faust continues to be developed because (a) the code may be easier to read for signal processing tasks, and (c) once written the code may automatically be built into various kinds of plugins.

I have considered making a generator so Faust code will compile into plugin Csound opcodes.

OCaml as benchmarked with other functional languages compared with C++: slower. See this from http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all:

100%	C GNU gcc 	1.41
100%	C++ GNU g++ 	1.43
110%	ATS 	        1.49
110%	Clean 	        1.61
120%	Java 6 -server 	1.76
130%	Lisaac 	        1.82
130%	Fortran Intel 	1.86
140%	Haskell GHC 	1.93
150%	Lisp SBCL 	2.1
150%	Pascal Free Pas 2.17
180%	OCaml 	        2.54
180%	Ada 2005 GNAT 	2.59
200%	Nice 	        2.86
200%	Scala 	        2.87
220%	C# Mono 	3.04
220%	CAL 	        3.14
320%	Lua LuaJIT 	4.46

However, it is worth noting that the performance of some other languages has gradually been catching up to C and C++. 

For this recent set of low level benchmarks, not necessarily representative of signal processing or music loops, Java now runs in 120% the time of C, OCaml 180%, and even handy little LuaJIT is 320%. In reality, one could write some sort of real-time software synthesizer in any of these languages. But if you need oodles of oomph and oodles of libraries to use, the champ is still C/C++... plus, my personal experience is that when you do write a synthesizer, these benchmarks over-estimate the performance you will actually get.

Based on these results, I would think it worth looking at ATS to see if it is significantly easier to write ATS code. Extremely hasty glimpse suggests functional programming and linking with C/C++.

Of course, like so many of these research languages, ATS code is compiled to C code before it is compiled to machine language... so even if you like the language you still have to have a C development system... if you have to have a C development system anyway, why not write somewhat faster code in C++ with an existing rich signal processing library?

Regards,
Mike

Regards,
Mike

-----Original Message-----
>From: Darren Landrum <darren.landrum@sbcglobal.net>
>Sent: Sep 19, 2008 2:15 PM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>Stephen Sinclair wrote:
>> On Sat, Aug 23, 2008 at 6:21 PM, victor <Victor.Lazzarini@nuim.ie> wrote:
>>> I think Mike's reply was probably the bottom line: if you want speed
>>> and efficiency, it has to be C or C++ (or a similar compiled language).
>>> Java appears to be the alternative, but not as efficient.
>> 
>> Of course, I'll grudgingly accept the status quo that C or C++ is the
>> only real answer here.
>
>Has anyone taken a close look at Ocaml for real-time DSP?
>
>http://caml.inria.fr/about/index.en.html
>
>I'm into functional languages, having had a lot of fun with Faust 
>lately, and I've been interested in a functional language for more 
>general synth/effect plug-in writing.
>
>Thanks for the very interesting discussion.
>
>By the way, here's the link to Faust, just in case:
>
>http://faust.grame.fr/index.php
>
>I don't recall if it got mentioned yet. It's a functional language for 
>DSP that compiled to efficient C/C++ code.
>
>Regards,
>Darren Landrum
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From Victor.Lazzarini at nuim.ie  Fri Sep 19 16:51:31 2008
From: Victor.Lazzarini at nuim.ie (victor)
Date: Fri Sep 19 16:51:48 2008
Subject: FAUST and Csound (was Re: [music-dsp] programming languages for
	real-time audio)
References: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
Message-ID: <000b01c91a99$7fa79f60$0201a8c0@family>

I had some chats with Yann (we keep bumping into each other at various
conferences) about doing exactly this. I think it is a great idea (and 
possibly
the only output FAUST does not have at this stage).

One thing this might enable is to benchmark music languages (Csound vs.
PD vs. SC3), which is something worth doing once and for all (I can see
a paper in this...)

Victor

----- Original Message ----- 
From: "Michael Gogins" <gogins@pipeline.com>
To: "A discussion list for music-related DSP" <music-dsp@music.columbia.edu>
Sent: Friday, September 19, 2008 9:22 PM
Subject: Re: [music-dsp] programming languages for real-time audio


> I have considered making a generator so Faust code will compile into 
> plugin Csound opcodes.

From darren.landrum at sbcglobal.net  Fri Sep 19 16:51:19 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Fri Sep 19 16:52:20 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
References: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
Message-ID: <48D410C7.8060603@sbcglobal.net>

Michael Gogins wrote:
> Of course, like so many of these research languages, ATS code is 
compiled to C code before it is compiled to machine language... so
even if you like the language you still have to have a C development
system... if you have to have a C development system anyway, why not
write somewhat faster code in C++ with an existing rich signal processing
library?

How about the fact that I really, really hate C/C++ and would rather 
gouge my own eyes out than spend four years teaching myself a language I 
hate when functional languages really suit the way I think and I can 
ramp up on them quickly?

Okay, that's all a bit of exaggeration, but you get my point. Besides, I 
have no real experience with Ocaml. Just because I got pretty good at 
one functional language (Faust) doesn't mean I'd be any good at another.

Also, Ocaml has no readily available LV2 or JACK interfaces, or anything 
like that. As for DSP code libraries, well, I have yet to find one of 
those I want to use in any language. Ocaml can use C libraries, which 
may ease construction of things like LV2 plugins, as well as allow the 
use of libraries like libsamplerate, libsndfile, and libfftw3.

I guess "try it out and see" is the only real option here.

Thanks for the reply!

Regards,
Darren Landrum
From radarsat1 at gmail.com  Fri Sep 19 16:54:00 2008
From: radarsat1 at gmail.com (Stephen Sinclair)
Date: Fri Sep 19 16:54:23 2008
Subject: FAUST and Csound (was Re: [music-dsp] programming languages for
	real-time audio)
In-Reply-To: <000b01c91a99$7fa79f60$0201a8c0@family>
References: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
	<000b01c91a99$7fa79f60$0201a8c0@family>
Message-ID: <9b3e2dc20809191354h61186bacue4dde7d4000c48ae@mail.gmail.com>

On Fri, Sep 19, 2008 at 4:51 PM, victor <Victor.Lazzarini@nuim.ie> wrote:
> I had some chats with Yann (we keep bumping into each other at various
> conferences) about doing exactly this. I think it is a great idea (and
> possibly
> the only output FAUST does not have at this stage).
>
> One thing this might enable is to benchmark music languages (Csound vs.
> PD vs. SC3), which is something worth doing once and for all (I can see
> a paper in this...)

Some time I'd love to do this for ChucK as well.  While it's got a lot
of cool Ugens (e.g., STK), it's actually currently quite difficult to
write new ones.  Having FAUST output them would make it way easier.


Steve
From gogins at pipeline.com  Fri Sep 19 17:14:03 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Fri Sep 19 17:14:18 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <1479089.1221858844026.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>

If you let your personal taste dictate your choice of tool, you most likely will end up using the wrong tool. Use the tool that will do the job best.

I'm not saying that personal differences don't have any role at all. Suppose that, for some odd reason, my brain was wired so that I just couldn't deal with languages in which I have to be sure to delete every object that I allocate. I would be foolish not to use a garbage collected language, in that case. 

In your case, I am simply wondering if this bias of yours is something you might be able to overcome for the sake of more effective work in the future. Once again, I remind you that the track record of C/C++ in signal processing and music programming -- military (most demanding), research, open source, and commercial -- simply blows every other language away.

Regards,
Mike


-----Original Message-----
>From: Darren Landrum <darren.landrum@sbcglobal.net>
>Sent: Sep 19, 2008 4:51 PM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>Michael Gogins wrote:
>> Of course, like so many of these research languages, ATS code is 
>compiled to C code before it is compiled to machine language... so
>even if you like the language you still have to have a C development
>system... if you have to have a C development system anyway, why not
>write somewhat faster code in C++ with an existing rich signal processing
>library?
>
>How about the fact that I really, really hate C/C++ and would rather 
>gouge my own eyes out than spend four years teaching myself a language I 
>hate when functional languages really suit the way I think and I can 
>ramp up on them quickly?
>
>Okay, that's all a bit of exaggeration, but you get my point. Besides, I 
>have no real experience with Ocaml. Just because I got pretty good at 
>one functional language (Faust) doesn't mean I'd be any good at another.
>
>Also, Ocaml has no readily available LV2 or JACK interfaces, or anything 
>like that. As for DSP code libraries, well, I have yet to find one of 
>those I want to use in any language. Ocaml can use C libraries, which 
>may ease construction of things like LV2 plugins, as well as allow the 
>use of libraries like libsamplerate, libsndfile, and libfftw3.
>
>I guess "try it out and see" is the only real option here.
>
>Thanks for the reply!
>
>Regards,
>Darren Landrum
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From darren.landrum at sbcglobal.net  Fri Sep 19 17:42:03 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Fri Sep 19 17:43:04 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <1479089.1221858844026.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>
References: <1479089.1221858844026.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>
Message-ID: <48D41CAB.2020209@sbcglobal.net>

Michael Gogins wrote:
> If you let your personal taste dictate your choice of tool, you most likely will end up using the wrong tool. Use the tool that will do the job best.
> 
> I'm not saying that personal differences don't have any role at all. Suppose that, for some odd reason, my brain was wired so that I just couldn't deal with languages in which I have to be sure to delete every object that I allocate. I would be foolish not to use a garbage collected language, in that case. 
> 
> In your case, I am simply wondering if this bias of yours is something you might be able to overcome for the sake of more effective work in the future. Once again, I remind you that the track record of C/C++ in signal processing and music programming -- military (most demanding), research, open source, and commercial -- simply blows every other language away.

Well, I'm also wanting to build these tools mainly for my own use, and 
intend to release them as open source. As such, I'm actually better off 
using a sub-optimal tool and actually getting them done, than using an 
optimal tool that I get too frustrated with and then never get them 
done. Of course, my secondary goal is to create some (hopefully) nice 
software synthesizers and effects for Linux music production.

I've not got my heart set on Ocaml. I just want to explore some options 
before I dive in and get too far. Heck, I'd just use Csound if it had 
one very important capability (oversampling). I could probably build 
GUIs for Csound instruments (I've investigated the Csound API).

I've been doing a lot of research into DSP and the math of DSP, but 
creating implementations, and more importantly, finished "products", has 
been very elusive to me, and I'm trying to rectify that, however it may 
happen.

Regards,
Darren Landrum
From tim at klingt.org  Fri Sep 19 17:48:41 2008
From: tim at klingt.org (Tim Blechmann)
Date: Fri Sep 19 17:48:59 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <1479089.1221858844026.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>
References: <1479089.1221858844026.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>
Message-ID: <1221860921.21835.45.camel@peter-laptop>

hi all ...

> In your case, I am simply wondering if this bias of yours is something
> you might be able to overcome for the sake of more effective work in
> the future. Once again, I remind you that the track record of C/C++ in
> signal processing and music programming -- military (most demanding),
> research, open source, and commercial -- simply blows every other
> language away.

in this discussion, one should distinguish between a signal processing
language and a real-time scripting language ...

the signal processing code should prbly be written in a language like c
or c++ for performance reasons ...

personally, i would be interested in a real-time safe scripting
language, targeting a virtual machine with a jit compiler, though ...
llvm looks quite interesting, but i am not sure about it's real-time
safety ... might be an interesting research project ...

btw, from what i heard, recent versions of lua provide a real-time safe
garbage collector ... does anyone know, how if performs in low-latency
real-time systems?

best, tim

From darren.landrum at sbcglobal.net  Fri Sep 19 18:09:41 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Fri Sep 19 18:10:44 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <48D41CAB.2020209@sbcglobal.net>
References: <1479089.1221858844026.JavaMail.root@mswamui-blood.atl.sa.earthlink.net>
	<48D41CAB.2020209@sbcglobal.net>
Message-ID: <48D42325.9070400@sbcglobal.net>

Darren Landrum wrote:
> Michael Gogins wrote:
>> If you let your personal taste dictate your choice of tool, you most 
>> likely will end up using the wrong tool. Use the tool that will do the 
>> job best.
>>
>> I'm not saying that personal differences don't have any role at all. 
>> Suppose that, for some odd reason, my brain was wired so that I just 
>> couldn't deal with languages in which I have to be sure to delete 
>> every object that I allocate. I would be foolish not to use a garbage 
>> collected language, in that case.
>> In your case, I am simply wondering if this bias of yours is something 
>> you might be able to overcome for the sake of more effective work in 
>> the future. Once again, I remind you that the track record of C/C++ in 
>> signal processing and music programming -- military (most demanding), 
>> research, open source, and commercial -- simply blows every other 
>> language away.
> 
> Well, I'm also wanting to build these tools mainly for my own use, and 
> intend to release them as open source. As such, I'm actually better off 
> using a sub-optimal tool and actually getting them done, than using an 
> optimal tool that I get too frustrated with and then never get them 
> done. Of course, my secondary goal is to create some (hopefully) nice 
> software synthesizers and effects for Linux music production.
> 
> I've not got my heart set on Ocaml. I just want to explore some options 
> before I dive in and get too far. Heck, I'd just use Csound if it had 
> one very important capability (oversampling). I could probably build 
> GUIs for Csound instruments (I've investigated the Csound API).
> 
> I've been doing a lot of research into DSP and the math of DSP, but 
> creating implementations, and more importantly, finished "products", has 
> been very elusive to me, and I'm trying to rectify that, however it may 
> happen.

Forgive the reply to myself, but I do have to say, in all honesty, I'll 
probably end up coding in C++ using CLAM (http://clam.iua.upf.edu/) than 
trying to learn a new language, suitable or not. I just wish there were 
an easier way to make softsynths and the like on Linux for us math-heads 
who aren't such good coders.

-- Darren
From k.s.matheussen at notam02.no  Fri Sep 19 18:23:02 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Fri Sep 19 18:24:05 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <20080919202250.61B7C3E2A3342@music.columbia.edu>
References: <20080919202250.61B7C3E2A3342@music.columbia.edu>
Message-ID: <Pine.LNX.4.64.0809192359330.5776@ttleush>



Darren Landrum:
> I don't recall if it got mentioned yet. It's a functional language for
> DSP that compiled to efficient C/C++ code.

Faust has actually been mentioned a few times in this discussion.



Darren Landrum:
> How about the fact that I really, really hate C/C++ and would rather
> gouge my own eyes out than spend four years teaching myself a language I
> hate when functional languages really suit the way I think and I can
> ramp up on them quickly?

Stalin Scheme is a functional language. You can
think of Scheme as the dynamically typed brother
of ML, which Ocaml is a descendent of.



Michael Gogins:
>
> Of course, like so many of these research languages, ATS code is 
> compiled to C code before it is compiled to machine language... so even 
> if you like the language you still have to have a C development system... 
> if you have to have a C development system anyway, why not write 
> somewhat faster code in C++ with an existing rich signal processing library?
>

It's hard to manually do the kind of optimization performed by 
whole-program optimizers such as faust, mlton or stalin.
Have you looked at the output of those compilers? That's pretty
extreme stuff.

Anyway, hearing your arguments, it reminds me of old assembler vs. C
disussions. The simple truth is that developing in a higher level
language simply is faster, and it frees up your brain to concentrate
on the algorithms instead of gory low-level details. You can 
try out things more quickly, and if you think you can make
your stuff run faster if developed directly in C or assember
later on, you are free to do so.



Tim Blechmann:
> personally, i would be interested in a real-time safe scripting
> language, targeting a virtual machine with a jit compiler, though ...
> llvm looks quite interesting, but i am not sure about it's real-time
> safety ... might be an interesting research project ...

There is a project for compiling faust to llvm. I don't
know if it's usable yet.



Tim Blechmann:
> btw, from what i heard, recent versions of lua provide a real-time safe
> garbage collector ... does anyone know, how if performs in low-latency
> real-time systems?

Have you looked at Vessel? It seems very nice and a quick
way to test lua's realtimeness.

From gogins at pipeline.com  Fri Sep 19 19:53:30 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Fri Sep 19 19:53:55 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <6159104.1221868410938.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>

You may be interested in Vessel, which is part of LuaAV. It provides Lua wrappers and coroutine scheduling for DSP classes written in C++ (the synz package). I have examined the code, but I have not tried to run it. Adobe Systems also presented a VST plugin Lua scripting project at one of the Lua conferences a few years ago.

I have worked on something similar myself, but I think I will drop it in favor of pure C++ that is built in a hidden, encapsulated way. As far as the user is concerned, it will be like a scripting language -- hit the button and go.

The idea of Lua remains attractive because it has an extremely small footprint for a powerful language. You can build it right into your libraries and applications. In fact, it comes with Csound on Windows, in the form of LuaJIT.

Regards,
Mike

-----Original Message-----
>From: Tim Blechmann <tim@klingt.org>
>Sent: Sep 19, 2008 5:48 PM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>hi all ...
>
>> In your case, I am simply wondering if this bias of yours is something
>> you might be able to overcome for the sake of more effective work in
>> the future. Once again, I remind you that the track record of C/C++ in
>> signal processing and music programming -- military (most demanding),
>> research, open source, and commercial -- simply blows every other
>> language away.
>
>in this discussion, one should distinguish between a signal processing
>language and a real-time scripting language ...
>
>the signal processing code should prbly be written in a language like c
>or c++ for performance reasons ...
>
>personally, i would be interested in a real-time safe scripting
>language, targeting a virtual machine with a jit compiler, though ...
>llvm looks quite interesting, but i am not sure about it's real-time
>safety ... might be an interesting research project ...
>
>btw, from what i heard, recent versions of lua provide a real-time safe
>garbage collector ... does anyone know, how if performs in low-latency
>real-time systems?
>
>best, tim
>
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From gogins at pipeline.com  Fri Sep 19 19:54:39 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Fri Sep 19 19:54:52 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <32102194.1221868479288.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>

CLAM might be overkill. What's wrong with STK? Then there's SndObj, which is not only C++ but also has Python wrappers.

Regards,
Mike

-----Original Message-----
>From: Darren Landrum <darren.landrum@sbcglobal.net>
>Sent: Sep 19, 2008 6:09 PM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>Darren Landrum wrote:
>> Michael Gogins wrote:
>>> If you let your personal taste dictate your choice of tool, you most 
>>> likely will end up using the wrong tool. Use the tool that will do the 
>>> job best.
>>>
>>> I'm not saying that personal differences don't have any role at all. 
>>> Suppose that, for some odd reason, my brain was wired so that I just 
>>> couldn't deal with languages in which I have to be sure to delete 
>>> every object that I allocate. I would be foolish not to use a garbage 
>>> collected language, in that case.
>>> In your case, I am simply wondering if this bias of yours is something 
>>> you might be able to overcome for the sake of more effective work in 
>>> the future. Once again, I remind you that the track record of C/C++ in 
>>> signal processing and music programming -- military (most demanding), 
>>> research, open source, and commercial -- simply blows every other 
>>> language away.
>> 
>> Well, I'm also wanting to build these tools mainly for my own use, and 
>> intend to release them as open source. As such, I'm actually better off 
>> using a sub-optimal tool and actually getting them done, than using an 
>> optimal tool that I get too frustrated with and then never get them 
>> done. Of course, my secondary goal is to create some (hopefully) nice 
>> software synthesizers and effects for Linux music production.
>> 
>> I've not got my heart set on Ocaml. I just want to explore some options 
>> before I dive in and get too far. Heck, I'd just use Csound if it had 
>> one very important capability (oversampling). I could probably build 
>> GUIs for Csound instruments (I've investigated the Csound API).
>> 
>> I've been doing a lot of research into DSP and the math of DSP, but 
>> creating implementations, and more importantly, finished "products", has 
>> been very elusive to me, and I'm trying to rectify that, however it may 
>> happen.
>
>Forgive the reply to myself, but I do have to say, in all honesty, I'll 
>probably end up coding in C++ using CLAM (http://clam.iua.upf.edu/) than 
>trying to learn a new language, suitable or not. I just wish there were 
>an easier way to make softsynths and the like on Linux for us math-heads 
>who aren't such good coders.
>
>-- Darren
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From darren.landrum at sbcglobal.net  Fri Sep 19 22:35:50 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Fri Sep 19 22:36:53 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <32102194.1221868479288.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>
References: <32102194.1221868479288.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>
Message-ID: <48D46186.8020409@sbcglobal.net>

Michael Gogins wrote:
> CLAM might be overkill. What's wrong with STK? Then there's SndObj, which is not only C++ but also has Python wrappers.

STK I had completely forgotten about. SndObj I've already played with 
and dismissed. STK looks like it has a lot of stuff I need, and it 
wouldn't be hard to add everything else. It's worth a shot, anyway.

-- Darren

From lists at grahamwakefield.net  Sat Sep 20 00:02:25 2008
From: lists at grahamwakefield.net (Graham Wakefield)
Date: Sat Sep 20 00:02:49 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <Pine.LNX.4.64.0809192359330.5776@ttleush>
References: <20080919202250.61B7C3E2A3342@music.columbia.edu>
	<Pine.LNX.4.64.0809192359330.5776@ttleush>
Message-ID: <B6FE463F-0996-4392-B2FA-40E1DD6DCCE3@grahamwakefield.net>

> Tim Blechmann:
>> btw, from what i heard, recent versions of lua provide a real-time  
>> safe
>> garbage collector ... does anyone know, how if performs in low- 
>> latency
>> real-time systems?
>
> Have you looked at Vessel? It seems very nice and a quick
> way to test lua's realtimeness.

Yes, I can speak from experience that it performs very well indeed;  
very low jitter. This was one of the most attractive features of Lua  
for me, when I first chose to use it.

It's also quite configurable: http://www.lua.org/manual/5.1/ 
manual.html#2.10
Tweaking the pause and step multipliers improved the overhead  
significantly when used within an audio process. In Lua~ I have the  
collector effectively turned off while running coroutine updates, and  
then run a conservative step of gc at the end of each DSP callback,  
this reduced the overhead of gc logic slightly, at the expense of  
slightly greater memory use.

Also, the allocator used by Lua can be very easily replaced: http:// 
www.lua.org/manual/5.1/manual.html#lua_Alloc
For my work I used dlmalloc as a drop-in replacement, which performed  
very well. It's on my todo list to compare this with TLSF and of  
course the rollendurchmesserzeitsammler.

BTW The Vessel application was my MS thesis, but the standalone app  
described there isn't in a publicly downloadable state. It is about  
95% the same as the lua~ external for Max/MSP, which is downloadable,  
and documented here: http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua% 
7E.htm
Since then, I've been working on a new version which is not only more  
efficient (buffer use minimization is the biggest improvement over  
lua~, but there are many more), but also operates in the main thread  
while dispatching all signal processing events (with sample accuracy)  
to the audio thread through wait-free queues. The upshot is that the  
articulation of audio events, coroutines, dsp graph changes and so on  
can all exist in the same accurately timed script as OpenGL calls,  
GUI event handling, and so on. This is part of a joint project with  
Wes Smith, called LuaAV, which ought to be in a stable state in the  
next week or so. I'll post an update on that if people are  
interested. In the meantime, here's a placeholder: http://lua- 
av.mat.ucsb.edu/about.html

From tim at klingt.org  Sat Sep 20 05:54:23 2008
From: tim at klingt.org (Tim Blechmann)
Date: Sat Sep 20 05:54:39 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <B6FE463F-0996-4392-B2FA-40E1DD6DCCE3@grahamwakefield.net>
References: <20080919202250.61B7C3E2A3342@music.columbia.edu>
	<Pine.LNX.4.64.0809192359330.5776@ttleush>
	<B6FE463F-0996-4392-B2FA-40E1DD6DCCE3@grahamwakefield.net>
Message-ID: <1221904463.6435.30.camel@peter-laptop>

On Fri, 2008-09-19 at 21:02 -0700, Graham Wakefield wrote:
> > Tim Blechmann:
> >> btw, from what i heard, recent versions of lua provide a real-time  
> >> safe
> >> garbage collector ... does anyone know, how if performs in low- 
> >> latency
> >> real-time systems?
> >
> > Have you looked at Vessel? It seems very nice and a quick
> > way to test lua's realtimeness.
> 
> Yes, I can speak from experience that it performs very well indeed;  
> very low jitter. This was one of the most attractive features of Lua  
> for me, when I first chose to use it.

i hadn't heard of vessel before ... i was just skimming through your
master thesis, thought ... seems interesting ...
but i'm curious, did you do any analysis of the worst-case response
times of the lua interpreter, when running in a real-time thread? like,
is entering/leaving the interpreter lock-free?

> Also, the allocator used by Lua can be very easily replaced: http:// 
> www.lua.org/manual/5.1/manual.html#lua_Alloc
> For my work I used dlmalloc as a drop-in replacement, which performed  
> very well. It's on my todo list to compare this with TLSF and of  
> course the rollendurchmesserzeitsammler.

unfortunately tlsf is just a single-threaded allocator ... therefore it
is not usable, where the allocator needs to be accessed from multiple
real-time threads ... well, for most computer music systems, that may be
the case, but we're living in 2008, where most of the personal computers
provide multiple processors ...
i am not sure about rollendurchmesserzeitsammler, but the last time i
checked, it was relying on tlsf ... kjetil, do you know how rdmzs would
perform with multiple real-time threads?

cheers, tim

From k.s.matheussen at notam02.no  Sat Sep 20 07:22:01 2008
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Sat Sep 20 07:22:20 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <20080919214901.8F5A93E3036BC@music.columbia.edu>
References: <20080919214901.8F5A93E3036BC@music.columbia.edu>
Message-ID: <Pine.LNX.4.58.0809201247280.29035@notam02.uio.no>


Tim Blechmann:
> > Also, the allocator used by Lua can be very easily replaced: http:// 
> > www.lua.org/manual/5.1/manual.html#lua_Alloc
> > For my work I used dlmalloc as a drop-in replacement, which performed  
> > very well. It's on my todo list to compare this with TLSF and of  
> > course the rollendurchmesserzeitsammler.
> 
> unfortunately tlsf is just a single-threaded allocator ... therefore it
> is not usable, where the allocator needs to be accessed from multiple
> real-time threads ... well, for most computer music systems, that may be
> the case, but we're living in 2008, where most of the personal computers
> provide multiple processors ...

Don't you have to do extermely frequent allocations for this to matter?
I mean, that the TLSF allocator uses mutexes instead of lock-free 
teqniques for supporting multiple threads.

Since allocating memory happens relatively seldom, plus that TLSF
only uses about 180 instructions for allocating and freeing,
I don't really think this should make a difference
since the mutex will hardly be used anyway.


> i am not sure about rollendurchmesserzeitsammler, but the last time i
> checked, it was relying on tlsf ... kjetil, do you know how rdmzs would
> perform with multiple real-time threads?

rollendurch is tuned to work with snd-rt, which is single threaded (for
now), so it doesn't support multithreaded access. But it's not very hard
to support.

rollendurch has two memory allocators, which must be configured
at compile time to select which allocator to use: TLSF and
a (very naive) custom-made pool-based allocator.

For TLSF, as mentioned, you must use a mutex around alloc() and free(),
but for the pool-based allocator, it's relatively trivial
to add true multi-threading support just by using
atomic_add and lock-free fifo queues. (see algorithm below)

The pool-based allocator is, as I said, very naive, so it
can't really be used in general. It probably works okay for
about 99% (or more) of normal music algorithm use, but it
wastes an enourmous amount of memory plus that for some
types of code it could "mysteriously" :-) run out of memory
very quickly, or unquickly:

alloc(size):
  if pools[size]!=NULL:
     ret=pools[size]
     pools[size]=pools[size].next
  else:
     ret=freemem;
     freemem+=size
  return ret;

free(mem,size):
  if (freemem-size)==mem:
     freemem-=size
  else:
     mem.next=pools[size]
     pools[size]=mem.next

But it's very fast though. :-)
It should be more than 10 times faster than TLSF. (not
that it seems to matter in my tests though, unfortunately)

From gogins at pipeline.com  Sat Sep 20 10:27:49 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Sat Sep 20 10:28:11 2008
Subject: [music-dsp] Re: programming languages for real-time audio
Message-ID: <2282385.1221920870214.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>

>Michael Gogins:
>>
>> Of course, like so many of these research languages, ATS code is 
>> compiled to C code before it is compiled to machine language... so even 
>> if you like the language you still have to have a C development system... 
>> if you have to have a C development system anyway, why not write 
>> somewhat faster code in C++ with an existing rich signal processing library?
>>
>
>It's hard to manually do the kind of optimization performed by 
>whole-program optimizers such as faust, mlton or stalin.
>Have you looked at the output of those compilers? That's pretty
>extreme stuff.

> Kjetil:

>Anyway, hearing your arguments, it reminds me of old assembler vs. C
>disussions. The simple truth is that developing in a higher level
>language simply is faster, and it frees up your brain to concentrate
>on the algorithms instead of gory low-level details. You can 
>try out things more quickly, and if you think you can make
>your stuff run faster if developed directly in C or assember
>later on, you are free to do so.

I agree -- in principle, and in practice. That is, in some contexts I agree
in practice. I find Python productive compared to C++, for example. (Though
the margin is not as huge as I thought it might be. I use both Python and C++
both in my day job and in composing music, so I think factors of learning 
curve and knowledge of the languages have pretty much evened out by now.)

I think the question whether programming ease and clarity 
makes an effective difference will vary by
person, so it boils down to which objective is more important. C/C++ rules in
this field because for most of the people producing software for other people
to use, final performance is the overriding objective.

For a composer, or a researcher, or somebody programming for their own 
purposes, programming ease might well much more important.

Regards,
Mike


From lists at grahamwakefield.net  Sat Sep 20 14:05:14 2008
From: lists at grahamwakefield.net (Graham Wakefield)
Date: Sat Sep 20 14:05:37 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <1221904463.6435.30.camel@peter-laptop>
References: <20080919202250.61B7C3E2A3342@music.columbia.edu>
	<Pine.LNX.4.64.0809192359330.5776@ttleush>
	<B6FE463F-0996-4392-B2FA-40E1DD6DCCE3@grahamwakefield.net>
	<1221904463.6435.30.camel@peter-laptop>
Message-ID: <BD5CFC3D-CFDA-407F-A037-5D4056E77CD7@grahamwakefield.net>


On Sep 20, 2008, at 2:54 AM, Tim Blechmann wrote:

> On Fri, 2008-09-19 at 21:02 -0700, Graham Wakefield wrote:
>>> Tim Blechmann:
>>>>
>>>
>>> Have you looked at Vessel? It seems very nice and a quick
>>> way to test lua's realtimeness.
>>
>> Yes, I can speak from experience that it performs very well indeed;
>> very low jitter. This was one of the most attractive features of Lua
>> for me, when I first chose to use it.
>
> i hadn't heard of vessel before ... i was just skimming through your
> master thesis, thought ... seems interesting ...
> but i'm curious, did you do any analysis of the worst-case response
> times of the lua interpreter, when running in a real-time thread?  
> like,
> is entering/leaving the interpreter lock-free?

Well, standard Lua is entirely single-threaded. The code is very  
lean, I gave up worrying about the overhead. Most of the time seems  
to be spent in variable lookups.  You can extend Lua for multi- 
threading with locks, but it doesn't make much sense to do so (can  
send refs if you need). There are extensions to Lua for spawning jobs  
into secondary threads, such as LuaLanes.

Like most of the other projects that have been discussed, I'm still  
using C/C++ for the actual DSP, but Lua for the management,  
allocation etc. of the graph nodes, along with timing and everything  
else. I wouldn't use Lua to do actual DSP as such except for  
prototyping, though apparently the v2 (release early next year?) of  
LuaJIT is approaching speeds approaching C... might be worth keeping  
an eye on. LuaJIT 1.0 is already pretty fast!

>
>> Also, the allocator used by Lua can be very easily replaced: http://
>> www.lua.org/manual/5.1/manual.html#lua_Alloc
>> For my work I used dlmalloc as a drop-in replacement, which performed
>> very well. It's on my todo list to compare this with TLSF and of
>> course the rollendurchmesserzeitsammler.
>
> unfortunately tlsf is just a single-threaded allocator ...  
> therefore it
> is not usable, where the allocator needs to be accessed from multiple
> real-time threads ... well, for most computer music systems, that  
> may be
> the case, but we're living in 2008, where most of the personal  
> computers
> provide multiple processors ...

If anything, I would expect that in the future we might be looking at  
smaller granularity of threading, data-parallel and task-parallel  
etc, so I'm keeping tabs on the potential of these kinds of  
developments instead (Intel Building Blocks, OpenCL, etc). Figuring  
out the real-time safe, low latency ways to do this (including  
allocation) is on my plate over the coming year.

From radarsat1 at gmail.com  Sat Sep 20 22:03:20 2008
From: radarsat1 at gmail.com (Stephen Sinclair)
Date: Sat Sep 20 22:03:33 2008
Subject: [music-dsp] Re: programming languages for real-time audio
In-Reply-To: <2282385.1221920870214.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
References: <2282385.1221920870214.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
Message-ID: <9b3e2dc20809201903v6d6efa46w7bd69ecd9679de2f@mail.gmail.com>

On Sat, Sep 20, 2008 at 10:27 AM, Michael Gogins <gogins@pipeline.com> wrote:
> For a composer, or a researcher, or somebody programming for their own
> purposes, programming ease might well much more important.

It's not just "programming ease", though.  I mean, I don't find C or
C++ particularly "hard", per se.  But when writing an application it's
often just better to use a dynamic language, hence people's interest
in Python-like environments lately.  Then, when you go to do the audio
engine, having to re-write all the data structures in C just to meet
real-time needs seems kind of annoying and even limiting.  Equally,
restricting yourself to C in the first place to avoid this problem,
just because you know your application will have an audio output, also
feels limiting.

It's not just "ease", it's convenience, and making better use of both
your time and your mental resources.  My solution is usually to do the
complex parts of the application and then control an audio thread in C
using the barest parameter space, trying hard to replicate code as
little as possible.  But it'd be nice to just do the audio in the
language of choice, period.  With JIT compilers getting better and
better these days, I was wondering if it's getting to the point where
it's possible to do this now.

I think that one day when I have time I'm going to write simple
RtAudio bindings for one of these new JavaScript engines that claim to
be almost as fast as... well.. Java maybe, and just see how much raw
audio processing I can do.  And many articles on these new engines
claim to still have room for improvement, so things will only be
getting better I think.

Steve
From mdsp-erikd at mega-nerd.com  Sun Sep 21 03:39:39 2008
From: mdsp-erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Sun Sep 21 03:40:38 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <48D3EC25.1090507@sbcglobal.net>
References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com>
	<860667A7-7566-4042-B2B8-842B46274A9A@gmail.com>
	<001501c9056e$97774f90$0201a8c0@family>
	<9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com>
	<48D3EC25.1090507@sbcglobal.net>
Message-ID: <20080921173939.2a82d04f.mdsp-erikd@mega-nerd.com>

Darren Landrum wrote:

> Has anyone taken a close look at Ocaml for real-time DSP?

I have. I love Ocaml as a general purpose langauge and as language for
technical computing and as a language for off line DSP.

It is not in my opinion a good language for real-time DSP, so I 
tend to use C for that instead.

> By the way, here's the link to Faust, just in case:
> 
> http://faust.grame.fr/index.php
> 
> I don't recall if it got mentioned yet. It's a functional language for 
> DSP that compiled to efficient C/C++ code.

Faust does look interesting.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"I'll just say that having programmed in Lisp the shortcomings
of Java are glaringly obvious." -- Erann Gat
From rsolomon at gmail.com  Tue Sep 23 03:05:08 2008
From: rsolomon at gmail.com (Rory Solomon)
Date: Tue Sep 23 03:05:22 2008
Subject: [music-dsp] java sound, without hardware device
In-Reply-To: <28bd54c0809230000p613f13e7hfd7b77eea86d189@mail.gmail.com>
References: <28bd54c0809211305q5c16b3afhf2bd525efc021af8@mail.gmail.com>
	<28bd54c0809230000p613f13e7hfd7b77eea86d189@mail.gmail.com>
Message-ID: <28bd54c0809230005w7d6cc763n9f417ca30685e5ab@mail.gmail.com>

Hello,

I have some code I've written based on the Java Sound API that takes
multiple sound clips, and mixes them together in an interesting way
and plays the result. I am now trying to run this in a server
environment, where the resulting mix will be recorded to a file
instead of played to line out.

However the server I am trying to run this on does not appear to have
any audio devices installed, and I seem to be running into roadblocks
with Java Sound not being able to allocate any lines if there is not a
Mixer that supports it. (And with no hardware devices I'm getting no
Mixers.)

Does anyone know if this is possible?

Any info would be appreciated -

thanks!
Rory
From cournape at gmail.com  Tue Sep 23 03:41:00 2008
From: cournape at gmail.com (David Cournapeau)
Date: Tue Sep 23 03:41:14 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
References: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
Message-ID: <5b8d13220809230041k4799799fgf59726a33de1be9a@mail.gmail.com>

On Sat, Sep 20, 2008 at 5:22 AM, Michael Gogins <gogins@pipeline.com> wrote:
> Yes, I have examined OCaml and I have played with Faust.
>
> Faust may conceivably be useful to some persons. For most people, I think it would be just about as easy to write code using a class library such as the STK. However, I hope that Faust continues to be developed because (a) the code may be easier to read for signal processing tasks, and (c) once written the code may automatically be built into various kinds of plugins.
>
> I have considered making a generator so Faust code will compile into plugin Csound opcodes.
>
> OCaml as benchmarked with other functional languages compared with C++: slower. See this from http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all:

I don't want to go into 'benchmark are meaningless' meme, but I have a
hard time believing a factor 2-3 mean anything. I mean with the same C
code/same compiler, you can easily get this factor by running on
slightly different CPU, specially for floating point, or by slightly
different compiler options (see for example how ATLAS performances are
changed by some tiny-looking changes in some options/micro-revision
changes); you can certainly lose/gain such a factor using a different
compiler. IOW, I would say that being 2x slower (or faster) is not
statistically significant.

I am not saying that OCAML is not slower than C++ for dsp (I have no
idea - I would guess that for real-time, the gc may be a problem), but
if speed was a criteria, I would not base my judgement on those
benchmarks.

cheers,

David
From cournape at gmail.com  Tue Sep 23 03:50:59 2008
From: cournape at gmail.com (David Cournapeau)
Date: Tue Sep 23 03:51:22 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <20080921173939.2a82d04f.mdsp-erikd@mega-nerd.com>
References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com>
	<860667A7-7566-4042-B2B8-842B46274A9A@gmail.com>
	<001501c9056e$97774f90$0201a8c0@family>
	<9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com>
	<48D3EC25.1090507@sbcglobal.net>
	<20080921173939.2a82d04f.mdsp-erikd@mega-nerd.com>
Message-ID: <5b8d13220809230050m1da98f5v7bdcbba6f2aa2ad0@mail.gmail.com>

On Sun, Sep 21, 2008 at 4:39 PM, Erik de Castro Lopo
<mdsp-erikd@mega-nerd.com> wrote:
>
> It is not in my opinion a good language for real-time DSP, so I
> tend to use C for that instead.

We want more :) Did you write anything about your findings on the
limitations of ocaml for real-time dsp ?

>
> Faust does look interesting.
>

It does. I wondered if this could be applicable to numerical computing
too (they mention matrix/vector as a future direction in some of their
online slides). I think it is a much better alternative to C++
meta-programming for efficient code generation,

cheers,

David
From mdsp-erikd at mega-nerd.com  Tue Sep 23 04:30:26 2008
From: mdsp-erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Tue Sep 23 04:30:44 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <5b8d13220809230050m1da98f5v7bdcbba6f2aa2ad0@mail.gmail.com>
References: <9b3e2dc20808231028i20f2bf0do4704af908057adfd@mail.gmail.com>
	<860667A7-7566-4042-B2B8-842B46274A9A@gmail.com>
	<001501c9056e$97774f90$0201a8c0@family>
	<9b3e2dc20808231542h2aa9c13w1c5e7fc11184f9a1@mail.gmail.com>
	<48D3EC25.1090507@sbcglobal.net>
	<20080921173939.2a82d04f.mdsp-erikd@mega-nerd.com>
	<5b8d13220809230050m1da98f5v7bdcbba6f2aa2ad0@mail.gmail.com>
Message-ID: <20080923183026.08eb651b.mdsp-erikd@mega-nerd.com>

David Cournapeau wrote:

> On Sun, Sep 21, 2008 at 4:39 PM, Erik de Castro Lopo
> <mdsp-erikd@mega-nerd.com> wrote:
> >
> > It is not in my opinion a good language for real-time DSP, so I
> > tend to use C for that instead.
> 
> We want more :) Did you write anything about your findings on the
> limitations of ocaml for real-time dsp ?

I didn't write anything, but it basically comes down to insufficient
control of the garbage collector.

The other thing is that DSP programming is mainly imperative programming
and although you can do imperative programming in Ocaml, C is a better
imperative language than Ocaml.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Question #70427: Sitting beside women on public transport because
one is forced to
http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=70427&dgn=4
From gogins at pipeline.com  Tue Sep 23 07:49:14 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Tue Sep 23 07:49:37 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <14905870.1222170554334.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>

Csound and other software are not written only for you, they are written for a community of users. In my experience with trading systems, Csound, and other software, there are ALWAYS users for whom even a 15% performance difference is critical. 

Critical as in, "If it's not 15% faster, I can't use it." This is the literal, unexaggerated truth. 

My salary -- and the profits of my employer -- depends on it. It's also the reason why there is still a "float" version of Csound.

Regards,
Mike

-----Original Message-----
>From: David Cournapeau <cournape@gmail.com>
>Sent: Sep 23, 2008 3:41 AM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>On Sat, Sep 20, 2008 at 5:22 AM, Michael Gogins <gogins@pipeline.com> wrote:
>> Yes, I have examined OCaml and I have played with Faust.
>>
>> Faust may conceivably be useful to some persons. For most people, I think it would be just about as easy to write code using a class library such as the STK. However, I hope that Faust continues to be developed because (a) the code may be easier to read for signal processing tasks, and (c) once written the code may automatically be built into various kinds of plugins.
>>
>> I have considered making a generator so Faust code will compile into plugin Csound opcodes.
>>
>> OCaml as benchmarked with other functional languages compared with C++: slower. See this from http://shootout.alioth.debian.org/u32/benchmark.php?test=all?=all:
>
>I don't want to go into 'benchmark are meaningless' meme, but I have a
>hard time believing a factor 2-3 mean anything. I mean with the same C
>code/same compiler, you can easily get this factor by running on
>slightly different CPU, specially for floating point, or by slightly
>different compiler options (see for example how ATLAS performances are
>changed by some tiny-looking changes in some options/micro-revision
>changes); you can certainly lose/gain such a factor using a different
>compiler. IOW, I would say that being 2x slower (or faster) is not
>statistically significant.
>
>I am not saying that OCAML is not slower than C++ for dsp (I have no
>idea - I would guess that for real-time, the gc may be a problem), but
>if speed was a criteria, I would not base my judgement on those
>benchmarks.
>
>cheers,
>
>David
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From tom_info at ticino.com  Tue Sep 23 08:11:08 2008
From: tom_info at ticino.com (Tom O'Hara)
Date: Tue Sep 23 08:09:45 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <14905870.1222170554334.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
References: <14905870.1222170554334.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
Message-ID: <48D8DCDC.8020707@ticino.com>


 > "If it's not 15% faster, I can't use it." This is the literal, 
unexaggerated truth.

15%?  Sometimes it's a question of 1%!

> I would say that being 2x slower (or faster) is not statistically significant


I normally code in assembler, as C is generally 3x slower.  It's OK for 
background routines (calculating filter coefficients, for example), but 
for time critical stuff only assembler will do.  And yes, I already use 
the fastest DSPs the manufacturers provide, so changing chips is not an 
option.

Tom

From cournape at gmail.com  Tue Sep 23 08:23:58 2008
From: cournape at gmail.com (David Cournapeau)
Date: Tue Sep 23 08:24:13 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <14905870.1222170554334.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
References: <14905870.1222170554334.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
Message-ID: <5b8d13220809230523y1c0b90aflf178ff0f7ee2ab46@mail.gmail.com>

On Tue, Sep 23, 2008 at 8:49 PM, Michael Gogins <gogins@pipeline.com> wrote:
> Csound and other software are not written only for you, they are written for a community of users. In my experience with trading systems, Csound, and other software, there are ALWAYS users for whom even a 15% performance difference is critical.
>
> Critical as in, "If it's not 15% faster, I can't use it." This is the literal, unexaggerated truth.
>

Sure, I am well aware of that. But I never said 15 % did not matter. I
was saying that if you have a "variance" of 200 % for speed between
two implementations of the same language (and that's certainly true
for C/C++ considering the compiler as an implementation of the
language), a difference of 100 % between two languages is not
meaningful. This is all the more true if you need to squeeze a few %
of performances

cheers,

David
From gogins at pipeline.com  Tue Sep 23 08:59:57 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Tue Sep 23 09:00:12 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <21062714.1222174797647.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>

Software is not written in an abstract language, but in a concrete language. In practice, for critical software, the fastest implementation of the language is always used. So, these differences ARE significant.

The meaningful distinction then, is between the fastest implementation of one language, and the fastest implementation of another language.

Regards,
Mike

-----Original Message-----
>From: David Cournapeau <cournape@gmail.com>
>Sent: Sep 23, 2008 8:23 AM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>On Tue, Sep 23, 2008 at 8:49 PM, Michael Gogins <gogins@pipeline.com> wrote:
>> Csound and other software are not written only for you, they are written for a community of users. In my experience with trading systems, Csound, and other software, there are ALWAYS users for whom even a 15% performance difference is critical.
>>
>> Critical as in, "If it's not 15% faster, I can't use it." This is the literal, unexaggerated truth.
>>
>
>Sure, I am well aware of that. But I never said 15 % did not matter. I
>was saying that if you have a "variance" of 200 % for speed between
>two implementations of the same language (and that's certainly true
>for C/C++ considering the compiler as an implementation of the
>language), a difference of 100 % between two languages is not
>meaningful. This is all the more true if you need to squeeze a few %
>of performances
>
>cheers,
>
>David
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From cournape at gmail.com  Tue Sep 23 09:25:49 2008
From: cournape at gmail.com (David Cournapeau)
Date: Tue Sep 23 09:26:04 2008
Subject: [music-dsp] programming languages for real-time audio
In-Reply-To: <21062714.1222174797647.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>
References: <21062714.1222174797647.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>
Message-ID: <5b8d13220809230625u6b696939ucd7a347f545a78cd@mail.gmail.com>

On Tue, Sep 23, 2008 at 9:59 PM, Michael Gogins <gogins@pipeline.com> wrote:
>
> The meaningful distinction then, is between the fastest implementation of one language, and the fastest implementation of another language.

I guess I did not formulate my email correctly, because this was the
point I thought I was making :) I think the language shootout is not
adapted for this, because it is too coarse-grained. The language
shoutout is nice if you want to know the order of magnitude of the
languages, but it is not precise enough for anything more
fine-grained. Typically, would you choose java instead of fortran for
high performance linear algebra ? I believe a better comparison would
be some basic dsp implemented with a good C compiler and in ocaml.

cheers,

David
From gogins at pipeline.com  Tue Sep 23 13:14:14 2008
From: gogins at pipeline.com (Michael Gogins)
Date: Tue Sep 23 13:14:30 2008
Subject: [music-dsp] programming languages for real-time audio
Message-ID: <33004562.1222190055213.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>

The shootout does specify the implementation of the language. In the past, I recall seeing some shootouts with different implementations of the same language.

Of course, you are quite correct that the only truly valid benchmark involves performing the exact same task -- take these inputs, give me those outputs -- in the relevant languages.

With respect to software synthesis, I have done just that with all C++, all Java, Lua/C++, Python/C++, and Python/Csound implementations. 

The inputs were a sequence of notes generated by the logistic equation, and the outputs were soundfiles synthesized with a simple frequency modulation instrument. The all C++ implementation was faster than the Python/Csound implementation by about one percent, and 3 times faster than the all Java implementation; the others were slightly slower than the all Java. 

The Java test was done some years ago, and the results might be different today. All of these tests computed the audio signal one sample frame at a time. Normally, software synthesizers compute blocks of sample frames in each iteration of the inner loops. When Csound is used in this way, it is about 3 times faster than with 1 frame at a time. I would expect a similar speedup if I coded the all C++ and all Java synthesizers this way as well. This block efficiency thing may also be changing, since it depends mostly on how much code and data is hanging around in the fastest cache.

Regards,
Mike

-----Original Message-----
>From: David Cournapeau <cournape@gmail.com>
>Sent: Sep 23, 2008 9:25 AM
>To: A discussion list for music-related DSP <music-dsp@music.columbia.edu>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>On Tue, Sep 23, 2008 at 9:59 PM, Michael Gogins <gogins@pipeline.com> wrote:
>>
>> The meaningful distinction then, is between the fastest implementation of one language, and the fastest implementation of another language.
>
>I guess I did not formulate my email correctly, because this was the
>point I thought I was making :) I think the language shootout is not
>adapted for this, because it is too coarse-grained. The language
>shoutout is nice if you want to know the order of magnitude of the
>languages, but it is not precise enough for anything more
>fine-grained. Typically, would you choose java instead of fortran for
>high performance linear algebra ? I believe a better comparison would
>be some basic dsp implemented with a good C compiler and in ocaml.
>
>cheers,
>
>David
>--
>dupswapdrop -- the music-dsp mailing list and website: 
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links 
>http://music.columbia.edu/cmc/music-dsp 
>http://music.columbia.edu/mailman/listinfo/music-dsp



From gblargg at gmail.com  Wed Sep 24 16:46:12 2008
From: gblargg at gmail.com (Blargg)
Date: Wed Sep 24 16:46:31 2008
Subject: [music-dsp] Minimum-phase clarifications
Message-ID: <3bd682b30809241346r3589b941taede82b4e738d5be@mail.gmail.com>

I want to clarify my understanding of the minimum-phase transform. The
two main uses I understand it to have for digital audio are:

1) alter the time-domain response so that most of the energy is at the
front, and

2) reduce the number of taps in the filter kernel, to reduce
computation requirements without affecting how well it filters.

I'd like to focus on #2, the performance aspect. If one doesn't need a
linear phase response, there are more possible sets of coefficients
for the FIR that meet one's magnitude requirements, many of which
aren't linear-phase. Some of these sets have fewer non-zero
coefficients at the beginning and/or end, allowing fewer taps and thus
less computation in some applications.

Apparently one way of arriving at a shorter kernel is to generate the
kernel, then make the minimum-phase version of it and chop off the
(near) zeroes at the end. Based on some readings, the method used to
generate the starting kernel is critical in determining how well it
shortens.

Do I have things correct so far? I've not made much progress in
understanding how to generate optimal input kernels. I've implemented
the minimum-phase transform code and fed it several kernels, and I do
seem some shortening (particularly with a sinc windowed by a kaiser
with beta=9), but I get the idea there must be some way of generating
a more optimal input kernel that "bunches up" better with the
minimum-phase transform.

Do either of these two links describe methods of generating a kernel
to feed to the minimum-phase transform, that will result on lots of
zero/near-zero values at the end? I've had trouble understanding them,
so I just want to be sure they are going to help.

	http://www.dspguru.com/howto/tech/minph2.htm (the Homomorphic approach)
	
	http://users.ece.utexas.edu/~bevans/papers/2000/minPhase/

I've seen some mention of keeping the stopband ripple "positive"
helping, but I don't know how it could be negative in the first place.
The second link's method has a first step of doing some kind of
adjustment to the kernel before making the minimum-phase version, but
I couldn't make sense of the realdemo.m code. Some descriptions talk
about poles and zeroes, but I still haven't found any code that
calculates the poles and zeroes of an arbitrary impulse response.
Without code to help me visualize them, I can't make much sense of
them and how to adjust them.

If possible, I'd like to end up with an approach that works just as
simply as a windowed sinc or the "remez" method, where I specify the
basic parameters and get a shorter non-linear kernel than the linear
one would have been.

Thanks for any help. I've got more questions to follow, just want to
set the context first.
From darren.landrum at sbcglobal.net  Wed Sep 24 18:22:44 2008
From: darren.landrum at sbcglobal.net (Darren Landrum)
Date: Wed Sep 24 18:23:08 2008
Subject: [music-dsp] Lumped modeling and WDFs
Message-ID: <48DABDB4.7010406@sbcglobal.net>

Hello, all.

I've been trying to track down information about lumped modeling and 
wave digital filters (WDFs) as a possible method of circuit modeling. I 
found Dr. Julius Smith's textbook on the subject, and I've tracked down 
some papers here and there. However, even though my math is strong, my 
programming skills could really use some help, and I was hoping I might 
find some examples of how the different components (dashpots, springs, 
masses, and ports) might actually get implemented in a programming language.

I looked through the Music-DSP archives, and I couldn't find anything. 
I've found papers that describe the math, but not how to use the math. 
If anyone out there has any links or pointers, I would greatly 
appreciate it.

Thank you all for your time.

Regards,
Darren Landrum
From danstowell at gmail.com  Thu Sep 25 09:21:48 2008
From: danstowell at gmail.com (Dan Stowell)
Date: Thu Sep 25 09:22:05 2008
Subject: FAUST and Csound (was Re: [music-dsp] programming languages for
	real-time audio)
In-Reply-To: <000b01c91a99$7fa79f60$0201a8c0@family>
References: <21887329.1221855745815.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
	<000b01c91a99$7fa79f60$0201a8c0@family>
Message-ID: <286e6b7c0809250621yf6a52bdwc43e108fc2f60d18@mail.gmail.com>

I'd definitely like to see this; using faust-built units as
benchmarking test cases is a nice thought. All sorts of caveats of
course (as usual with benchmarks) but it'd be great to have such
music-dsp-specific benchmark data available.

Dan


2008/9/19 victor <Victor.Lazzarini@nuim.ie>:
> I had some chats with Yann (we keep bumping into each other at various
> conferences) about doing exactly this. I think it is a great idea (and
> possibly
> the only output FAUST does not have at this stage).
>
> One thing this might enable is to benchmark music languages (Csound vs.
> PD vs. SC3), which is something worth doing once and for all (I can see
> a paper in this...)
>
> Victor
>
> ----- Original Message ----- From: "Michael Gogins" <gogins@pipeline.com>
> To: "A discussion list for music-related DSP" <music-dsp@music.columbia.edu>
> Sent: Friday, September 19, 2008 9:22 PM
> Subject: Re: [music-dsp] programming languages for real-time audio
>
>
>> I have considered making a generator so Faust code will compile into
>> plugin Csound opcodes.
>
> --
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>



-- 
http://www.mcld.co.uk
From martin.eisenberg at udo.edu  Mon Sep 29 14:01:01 2008
From: martin.eisenberg at udo.edu (Martin Eisenberg)
Date: Mon Sep 29 14:00:00 2008
Subject: [music-dsp] Lumped modeling and WDFs
References: <48DABDB4.7010406@sbcglobal.net>
Message-ID: <001b01c9225d$597f7d00$0c01a8c0@Arbeitsgruppe>

From: "Darren Landrum" <darren.landrum@sbcglobal.net>

> I've been trying to track down information about lumped
modeling
> and wave digital filters (WDFs) as a possible method of circuit
> modeling. I found Dr. Julius Smith's textbook on the subject,
and
> I've tracked down some papers here and there. However, even
> though my math is strong, my programming skills could really
> use some help, and I was hoping I might find some examples of
> how the different components (dashpots, springs, masses, and
> ports) might actually get implemented in a programming
> language.

Well, here's a bare-bones inductor (not sure which is the
mechanical analog) in C++:

class Inductor {
  float state_;
public:
  Inductor()  { clear(); }
  void clear()  { state_ = 0; }
  float tick(float in) {
    float oldState = state_;  state_ = in;  return -oldState;
  }
};

Is realizing the more complex adaptors your problem? With a
little practice you can read the code directly from a block
diagram. Do you understand this link in simple cases, e.g. the
common 2nd-order IIR? Or are you wondering how to join all those
blocks into a running system? Perhaps you can point out a
specific block or circuit that you have trouble handling.


Martin

From martin.eisenberg at udo.edu  Mon Sep 29 17:00:01 2008
From: martin.eisenberg at udo.edu (Martin Eisenberg)
Date: Mon Sep 29 16:58:40 2008
Subject: [music-dsp] Minimum-phase clarifications
References: <3bd682b30809241346r3589b941taede82b4e738d5be@mail.gmail.com>
Message-ID: <002701c92276$5a6dcb40$0c01a8c0@Arbeitsgruppe>

From: "Blargg" <gblargg@gmail.com>

> Do either of these two links describe methods of generating
> a kernel to feed to the minimum-phase transform, that will
> result on lots of zero/near-zero values at the end? I've had
> trouble understanding them, so I just want to be sure they
> are going to help.
>
> http://www.dspguru.com/howto/tech/minph2.htm
> (the Homomorphic approach)

Except the first, I think all methods on that page rely on the
same ripple positivity constraint. Why the mentioned ripple
adjustment should enforce this constraint I can't say from the
top of my head.

> http://users.ece.utexas.edu/~bevans/papers/2000/minPhase/
>
> I've seen some mention of keeping the stopband ripple
> "positive" helping, but I don't know how it could be negative
> in the first place.

A complex spectrum H(w) may cross the frequency axis, as opposed
to just touching or winding around it. Typically the curve is
straight around the crossing so that the magnitude spectrum |H|
has a kink touching down on the axis, as you've probably often
seen. Negating any lobe between two such crossings to make a
smooth function leads to the so-called zero-phase response.
Negative ripple in a filter means that its zero-phase response is
less than the desired response, a definition that works in any
band.

Why does this matter to us? All the design methods in question
start from a prototype filter whose magnitude is supposed to
equal the *squared* magnitude of the minimum-phase result. But
for that to be possible the prototype magnitude must be smooth --
equivalently, the zero-phase response must be nonnegative.
In your second reference this is ensured in the simplest possible
way, by adding the negative extreme value (and scaling to keep
the passband at nominal gain).

> The second link's method has a first step of doing some kind
> of adjustment to the kernel before making the minimum-phase
> version, but I couldn't make sense of the realdemo.m code.

In the demo code H is the prototype linear-phase spectrum, H1 is
the zero-phase spectrum of H, and HR is the positivized target
magnitude spectrum. As far as I see, the only difference between
code and paper is that the paper assumes you can design prototype
filters to given ripple specifications whereas the code reads off
the ripple values from the given example filter, presumably to be
self-contained.

> Some descriptions talk about poles and zeroes, but I still
> haven't found any code that calculates the poles and zeroes of
> an arbitrary impulse response.

Finding the zeros of an FIR is simple in principle; apply a
root-finder to the polynomial that is the transfer function H(z).
There is standard software for that, though not all codes handle
high degrees (long IRs) well. Best ask for recommendations in
newsgroup sci.math.num-analysis if you want to play with
factoring.


Martin