> Congratulations Andrew, very impressive, and helpful screen cast.
Thanks Nick.
> LLVM definitely a great way to go.
Yeah, LLVM is a great project. It's pretty hard to find programming
language projects that aren't trying to find ways to use LLVM at the
moment ;)
> It's a quick step from here to your N sines additive synthesis
> example with independent amplitudes and frequencies for each sine
> controlled from scheme. Though I guess the limit on complexity is
> that you have to build a complex thing into one AudioUnit, rather
> than N AudioUnits, for efficiency. But then the runtime compilation
> should make this more efficient than N sines in an existing computer
> music language as separate UGens.
dotimes works wonders for additive synthesis ;)
Actually there are a few different ways of tackling complexity. As
you say you can box everything up into a single function call like the
simple examples in the screencast - which is very efficient. Or you
can run multiple custom AU instances each with a simpler function
definition - less efficient. Or you can still abstract away via calls
to other compiled "library" code - also very efficient. The
screencast didn't get this far but you can freely call other functions
you've previously compiled in your session. So I imagine that over
time people will write and call their own "library" functions. Like
this filter example.
;; define graph
(define aucode1 (au:make-node "aumf" "code" "MOSO"))
(au:connect-node aucode1 0 *au:output-node* 0)
(au:update-graph)
;; define a simple low pass filter - imagine this is library code
(define filter
(lambda (sample frequency channel data)
(let ((p0 (f64g data (+ 0 channel)))
(p1 (f64g data (+ 2 channel))))
(set! p0 (+ p0 (* frequency (- sample p0))))
(set! p1 (+ p1 (* frequency (- p0 p1))))
(f64s data (+ 0 channel) p0)
(f64s data (+ 2 channel) p1)
p1)))
;; compile filter - i.e. compile library
(sys:compile filter)
;; whitenoise calls filter library code passing random sample and
setting cutoff (0-1)
(define my-filtered-noise
(lambda (sample time channel data)
(* 0.3 (filter (random) 0.1 channel data))))
;; allocate shared memory
(define dat (objc:data:make (* 8 4)))
;; call noise filtered code which internally calls filter
(au:code:load aucode1 "dsp" my-filtered-noise dat)
You could of course also choose to run the filter function in it's own
AU and stick it after the noise AU in the signal graph. It's also
possible to define global memory for the filter to use such that you
don't need to use a shared memory object. This is helpful if you want
to write library code that doesn't rely on the availability of a
shared memory object. I'm not planning on providing DSP libraries
though as I expect people are either (a) going to roll their own or
(b) use existing audiounits. In either case there doesn't seem to be
much point in me writing DSP library code (other than for my own use
of course).
> Since the data input memory is shared, I guess you can update the
> shared data at any rate from the scheme code, with effects happening
> not delayed even by the blocksize of the audio calculations. But of
> course, even if you update phase rate, you can still get
> discontinuities in a higher derivative; so anticipating, how will
> enveloping triggers work; two doubles of data storage, one switch
> and one comparator to hold previous value?
Sorry Nick, I'm not sure I follow you here? Are you talking about
zippering - smoothing out parameter changes? In which case yep, you
would implement like any other zippering situation. Of course there
are lots of different ways to implement this depending on the situation.
> I assume you'll be gradually refining all this to reduce the amount
> of code to be typed overall.
Very early days for the compiler as I'm really still just playing
around. I'm hoping for major improvements over the next 12 months or
so. There are lots of bugs, inconsistencies, gotchas and black holes
that need addressing.
As far as excessive typing is concerned - yes and no. Yes, I'll
certainly be making abstractions for my own use, but I'm expecting
other's will want to roll their own.
Nice algodancing by the way, very stylish I thought :)
Cheers,
Andrew.
>
> best,
> Nick
>
>
>
> On 7 Sep 2009, at 09:14, Andrew Sorensen wrote:
>
>> Impromptu version 2.0 is now available for download at:
>> http://impromptu.moso.com.au/downloads.html
>>
>> Impromptu v2.0 is a major release with three significant
>> architectural changes.
>>
>> 1) A new impromptu x86 compiler
>> 2) Audio signal processing directly in Impromptu.
>> 3) A new concurrent garbage collector
>>
>> The new impromptu x86 compiler uses LLVM for backend code
>> generation and supports runtime compilation of scheme functions to
>> x86 machine code. In particular the compiler has been added to
>> impromptu to support the efficient compilation of scheme code for
>> data processing tasks such as image processing, audio signal
>> processing and OpenGL. The compiler is exposed at runtime through
>> the sys:compile call which accepts a scheme closure and returns a
>> foreign function which may be called freely from scheme. (help
>> sys:compile #t) will give you a bunch of examples.
>>
>> On-the-fly audio DSP programming is now supported directly within
>> the impromptu scheme environment by allowing x86 code (i.e.
>> compiled scheme code) to be hot-swapped into the kernel of a custom
>> code AudioUnit. You may use one or more of these custom code
>> audiounits anywhere in your audiounit chain - as both generators
>> and or effects. Code is hot-swapped into an AU kernel by passing a
>> given scheme closure to the au:code:load function. There is also a
>> mechanism for sharing memory between the AU and the scheme runtime.
>> (help au:code:load #t) will give you a bunch of examples.
>>
>> The primary motivation for the new GC is to provide greater
>> performance with larger heap sizes.
>>
>> v2.0 also adds support for Snow Leopard but is no longer provided
>> as a Universal Binary. Intel only from v2.0 forward.
>>
>> A brief screen-cast demonstrating the new on-the-fly audio
>> functionality can be found at: http://www.vimeo.com/6096554
>>
>> Cheers,
>> Andrew.
>
Received on Tue Sep 08 2009 - 04:21:45 BST