chuckles
Joined: Apr 02, 2007 Posts: 72 Location: San Diego, California
|
Posted: Fri Apr 13, 2007 9:48 am Post subject:
Riddle me this Subject description: Two questions: ChucK timing and CSound adaptations? |
 |
|
Still trying to get my head around ChucK's design...OK, hopefully this will make sense.
ChucK has a sense of deterministic time (or at least as good as the underlying OS support of it). That is, you can create a loop or shred or something where the time can be exactly specified. This feature appears to be really central to ChucK's design.
The thing I can't understand is this: let's say you create some quite complex shreds; for instance a reverb unit with a lot of allpass filters, etc. or an AM synth that uses thousands of oscillators. Then you write the performance part of the code for the events to occur at specific times. What happens when the time it takes the CPU to compute a shred is longer than the specified time between events?
I'm sort of jumping the gun here. My programs so far are so simple that the CPU barely breaks a sweat when I run them.
The other question is this: with all the thousands of CSound instrument (and even score) files that exist in the world, has anyone looked into how hard it is to convert a typical CSound instrument to run in ChucK?
Keep smiling...
c. |
|
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Fri Apr 13, 2007 3:03 pm Post subject:
Re: Riddle me this Subject description: Two questions: ChucK timing and CSound adaptations? |
 |
|
chuckles wrote: |
ChucK has a sense of deterministic time (or at least as good as the underlying OS support of it). That is, you can create a loop or shred or something where the time can be exactly specified. This feature appears to be really central to ChucK's design. |
Quite right. I don't think it's OS dependant; ChucK, at least within ChucK will have very well defined, very deterministic and very tight timing.
Of course all bets are off once you involve MIDI or other realtime input; those will depend on the OS as will the latency of the output sound.
Quote: | The thing I can't understand is this: let's say you create some quite complex shreds; for instance a reverb unit with a lot of allpass filters, etc. or an AM synth that uses thousands of oscillators. Then you write the performance part of the code for the events to occur at specific times. What happens when the time it takes the CPU to compute a shred is longer than the specified time between events?
|
Well, then there will bew glitches, simple as that. If you start asking for -say- 1000% of cpu time it will likely be quite silent. It is possible to ask more of the cpu then it can deliver. If that weren't true we could simply port all weather similations to ChucK and define the math as taking a ms... Of course that won't fly, there are no free lunches. You can, however, render your wave-files offline. If you realy need it to be realtime you can turn down the sample-rate for some significant savings.
Quote: |
The other question is this: with all the thousands of CSound instrument (and even score) files that exist in the world, has anyone looked into how hard it is to convert a typical CSound instrument to run in ChucK?
|
Not that I know of. For simple instruments it should be very feasable though there may be a need for restructuring in order to preserve CPU. FOr instruments that depend on Csound opcodes that have no ChucK Ugen equivalent it would be much harder. With both being open-source it should be possible to port some of those, I think there is some stuff borowed from Csound in there already in the filters section.
Translating score files would be very doable since they are basically just defining time and events and ChucK is all about those. For scores that make extensive use of makros some custom CHucK code would be needed to keep it managable, that would be quite intertesting.
Disclaimer; I think there has been at least one major Csound update since I looked into it.
....And welcome on board! _________________ Kassen |
|