Csound Csound-dev Csound-tekno Search About

Re: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))

Date2006-03-24 22:57
FromVictor Lazzarini
SubjectRe: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
The oscil code is very similar to stuff I've seen
for hardware with no floating-point maths. It's
great, but hard to read. One problem it has, though,
is that it becomes somewhat less precise freq-wise as the
function table size gets very large.

SuperCollider has a fast sine oscillator based on a filter
equation (a bit like a reson) that might be similar
to Richard's pvsadsyn code (not having looked checked it).
But that one (the SC one) is somewhat unstable.

Victor

>
> Michael Gogins wrote:
> > Thanks, that's useful.
> >
> > As you may recall, oscillator indexing in Csound is
> > highly optimized -- was that done by Richard Dobson? It
> > would be interesting to see if that particular part of
> > those systems is likewise optimized.
>
> If you mean the original oscil etc code (and the
> (in)famous power-of-two  restriction), it goes back all
> the way to Barry Vercoe. The only  oscillator code I have
> contributed is in pvsadsyn. Which is somewhat  different
> from running 1024 instances of oscil!
>
> Richard Dobson
>
> --
> Send bugs reports to this list.
> To unsubscribe, send email to
> csound-unsubscribe@lists.bath.ac.uk

Date2006-03-24 23:05
FromIstvan Varga
SubjectRe: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
AttachmentsNone  

Date2006-03-24 23:09
FromIstvan Varga
SubjectRe: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
AttachmentsNone  

Date2006-03-24 23:23
FromRichard Dobson
SubjectRe: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
Victor Lazzarini wrote:
> The oscil code is very similar to stuff I've seen
> for hardware with no floating-point maths. It's
> great, but hard to read. One problem it has, though,
> is that it becomes somewhat less precise freq-wise as the
> function table size gets very large.
> 

It is in essence a fixed-point system, where you get to choose where the 
point goes: how much you have to the left of the point comes from the 
table size, with less to the right (interpolation subdivisions) as the 
table approaches maximum (hard-wired in the code). In the limit, with a 
maximum table size (16MBytes!), you are reduced to truncated lookup (it 
could very easily be enhanced to perform round-to-nearest, but it is 
arguably too rare an issue to worry about); but the assumption is that 
with tables that size, interpolation is unnecessary. I've never tried 
it, but I think that assumption is fairly safe at "normal" sample rates.

Richard Dobson

Date2006-03-24 23:27
FromRichard Dobson
SubjectRe: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
Istvan Varga wrote:

> 
> The oscils opcode is similar (also basically a second order filter),
> and is faster than using the oscil opcodes. It only allows i-rate
> amplitude and frequency, though.

This is the problem with these "maximum oscillators " tests - they tend 
to use  a plain fixed-freq oscil, which (as a filter equation) is very 
cheap. The time-varying oscil we actually need to use, most of the time, 
is a very different matter, and inevitably pulls the stats right down.

Richard Dobson