[chuck-users] Anyone else running ChucK dual-core in 64-bit mode?

[Michel Koppelaar]

On Sat, 28 Apr 2007 10:55:30 -0700
Ken Restivo <ken at restivo.org> wrote:

*snip*

> 
> I asked a friend who does a lot of C++ work to take a brief look at this.
> 
> He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code? 
>

I took a look myself. I had to use gcc -E to see what on earth all those #define's
are doing! It does look like a pointer size issue, but it would take me too much time to try and understand the source. I know C, but no C++. 
 
> He also didn't hold out much hope that any of its developers would show any interest in fixing this stuff either. The OBJ_MEMBER_UINT's are all over the filter, osc, xxx(?!), and stk ugens, as well as the Std lib. The obj->data stuff is in chuck_instr.cpp but nowhere else. But it's hard to tell how much stuff like this is lurking elsewhere in the code.
> 
> I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then.
> 

Ironically, I got interested in ChucK because CSound seemed a very kludgy way to do audio programming. - Oh well, there's always SuperCollider ;)


Michel