Re: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
Date | 2006-03-24 22:57 |
From | Victor Lazzarini |
Subject | Re: 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 |
Date | 2006-03-24 23:05 |
From | Istvan Varga |
Subject | Re: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound)) |
Attachments | None |
Date | 2006-03-24 23:09 |
From | Istvan Varga |
Subject | Re: ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound)) |
Attachments | None |
Date | 2006-03-24 23:23 |
From | Richard Dobson |
Subject | Re: 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 |
Date | 2006-03-24 23:27 |
From | Richard Dobson |
Subject | Re: 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 |