[chuck-users] Audio Range and Zero-crossings, Hashes and OpenGl

Spencer Salazar ssalazar at CS.Princeton.EDU
Mon Mar 5 10:47:57 EST 2007


On Mar 4, 2007, at 2:44 PM, Veli-Pekka Tätilä wrote:

> Spencer Salazar wrote:
>> On Mar 4, 2007, at 8:30 AM, Veli-Pekka Tätilä wrote:
>>> 1. What's the range of the audio float datatype and what would be
>>> the best
>>> way to detect zero crossings?
>>> [...]
>>> I'm assuming here that samples are floats or doubles from -1 to 1 as
>>> in VST, <snip>
>> Yes.  Although, the -1 to 1 part isn't enforced within a UGen graph,
> Ah I see, so the rest of the value range is available when needed.  
> But I
> imagine that if larger values end up in the DAC they will be hard  
> clipped or
> wrapped.

This would be the expected behavior, yes, although empirically the  
exact upper/lower bounds before clipping can vary across different  
platforms or equipment.

>>> 3. Is there any way to decrease the latency on WIndows platforms
>>> for tru realtime MIDI playback and audio processing similar to  
>>> Reaktor?
>> You could try decreasing the audio buffer size through the --
>> bufsize### command line option (see http://chuck.cs.princeton.edu/ 
>> doc/
>> program/vm.html for more information).
> Will do that. HOwever I just read that ChucK is based on SDL and  
> DirectSound
> meaning a 20 ms latency is quite an achievement in many cards. It  
> would be
> great if the WIndows port of SDL had native ASIo support some day.  
> That
> would get rid of the latency issues with SDL apps in general.

ChucK does use DirectSound on Windows, which indeed makes attaining  
realtime latency problematic.  ChucK isn't based on SDL, but rather  
on RTAudio, which does have ASIO support, though ChucK doesn't  
support that backend currently.  So, ASIO is slowly making its way  
into ChucK, but we also don't have an ASIO platform to test on,  
making the process more difficult.

>>> 4. How does one use the ZeroX module for detecting zero crossings?
>>> Quote:
>>> Emits a single pulse at the the zero crossing in the direction of
>>> the zero
>>> crossing
>> Yes--this just means that for a zero crossing from > 1 to < 1 in its
>> input, it outputs a -1 for that particular sample, and for < 1 to >
>> 1, it outputs a 1.
> But what does it output when no zero-crossing is detected at the  
> now time,
> which is more than likely? I suppose that would be 0 and could  
> test, of
> course, but i'll be lazy and ask here.

Ah.  Yes, just 0.

> I also read that the OOP stuff is a bit on the way. The lack of  
> public and
> protected data doesn't bother me much but having constructor  
> support would
> rock. As well as the ability to declare abstract or interface classes
> similar to interfaces in Java or pure virtual classes in C++.

Yes--real constructors are definitely on the todo list, and ChucK  
actually reserves the "interface" and "implements" keywords for  
potential future use.

> Which reminds me of yet another query, I read somewhere that as  
> ChucK also
> supports multimedia, it would have OpenGl graphics support, too. Can I
> access it in chucK itself and if so, where's the reference? The manual
> doesn't say anything about openGl.

OpenGL support (GLucK) is currently in development limbo, but its  
something we'd very much like to make available in the near future.


More information about the chuck-users mailing list