Hello- I'm an OpenBSD ports[0] developer and I'd like to add ChucK to our ports tree. I've made a little progress this morning, but I've run into a few compilation errors that I hoped you could help debug (assuming this is the appropriate list for such inquiries). First, I'm using GCC 3.3.5 on OpenBSD -current/i386 to build ChucK version 1.2.1.2. For us, it seems to make the most sense to build ChucK using OSS (since Jack seems to require ALSA -- which we do not provide, though we have Jack in our tree -- in the end). When building, then, with src/makefile.oss, I get: [...] g++ -D__LINUX_OSS__ -c -I/usr/local/include -D__CK_SNDFILE_NATIVE__ chuck_compile.cpp In file included from chuck_compile.cpp:41: ugen_stk.h:174: error: syntax error before `__extension__' ugen_stk.h:174: error: syntax error before `?' token ugen_stk.h:174: error: syntax error before `)' token ugen_stk.h:174: error: syntax error before `:' token ugen_stk.h:174: error: ISO C++ forbids declaration of `__swap16md_x' with no type ugen_stk.h:174: error: syntax error before `}' token In file included from chuck_compile.cpp:41: ugen_stk.h:71:1: unterminated #if ugen_stk.h:36:1: unterminated #ifndef gmake: *** [chuck_compile.o] Error 1 C++ isn't my strong suit, but the referenced lines in src/ugen_stk.h seem entirely innocuous to me. Can you suggest any further steps to debug this issue? Thanks! [0] http://www.openbsd.org/ports.html -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/]
On Mon, Sep 29, 2008 at 9:21 AM, Will Maier
Hello-
I'm an OpenBSD ports[0] developer and I'd like to add ChucK to our ports tree. I've made a little progress this morning, but I've run into a few compilation errors that I hoped you could help debug (assuming this is the appropriate list for such inquiries).
First, I'm using GCC 3.3.5 on OpenBSD -current/i386 to build ChucK version 1.2.1.2. For us, it seems to make the most sense to build ChucK using OSS (since Jack seems to require ALSA -- which we do not provide, though we have Jack in our tree -- in the end). When building, then, with src/makefile.oss, I get:
[...] g++ -D__LINUX_OSS__ -c -I/usr/local/include -D__CK_SNDFILE_NATIVE__ chuck_compile.cpp In file included from chuck_compile.cpp:41: ugen_stk.h:174: error: syntax error before `__extension__' ugen_stk.h:174: error: syntax error before `?' token ugen_stk.h:174: error: syntax error before `)' token ugen_stk.h:174: error: syntax error before `:' token ugen_stk.h:174: error: ISO C++ forbids declaration of `__swap16md_x' with no type ugen_stk.h:174: error: syntax error before `}' token In file included from chuck_compile.cpp:41: ugen_stk.h:71:1: unterminated #if ugen_stk.h:36:1: unterminated #ifndef gmake: *** [chuck_compile.o] Error 1
C++ isn't my strong suit, but the referenced lines in src/ugen_stk.h seem entirely innocuous to me. Can you suggest any further steps to debug this issue?
The error is on the declaration of the Stk::swap16 function. Is it possible this word swap16 is a macro somewhere in the BSD headers? It seems to be perhaps replacing the word swap16 with __swap16md_x, but I have no idea why. What do you see with "grep -r swap16 /usr/include" ? The unterminated #if errors don't make much sense to me. Steve
Hi Stephen- On Mon, Sep 29, 2008 at 09:50:26AM -0400, Stephen Sinclair wrote:
The error is on the declaration of the Stk::swap16 function. Is it possible this word swap16 is a macro somewhere in the BSD headers? It seems to be perhaps replacing the word swap16 with __swap16md_x, but I have no idea why. What do you see with "grep -r swap16 /usr/include" ?
Quite a bit, actually (now that I'm all hopped up on tea and thinking clearly). We define several swap* macros that interfere here. Thanks for the nudge in the right direction!
The unterminated #if errors don't make much sense to me.
Once I undef swap{16,32,64}, those go away. With a few patches[0], I can get most of ChucK to compile. It looks, though, like src/util_hid.cpp is going to take quite a bit more work. Neither the Linux or OS X implementations there will work on OpenBSD (we don't provide input.h, and our joystick.h doesn't seem to have everything needed). If any developers would be interested in working on util_hid portability, I'd be happy to provide access to an i386 OpenBSD box. How much of this interface needs to actually be implemented? I've been reading the code, and it seems that at least some of it could simply remain unsupported while still making ChucK at least somewhat usable. Thanks again! [0] http://www.lfod.us/~will/chuck-openbsd.diff -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/]
Will Maier; How much of this interface needs to actually be
implemented? I've been reading the code, and it seems that at least some of it could simply remain unsupported while still making ChucK at least somewhat usable.
Strictly speaking I don't think you need it at all to have a usable ChucK; ChucK was fine before we had it. Personally I'm a big fan of the Joystick HID interface; I find game controllers to often be very expressive, inspirational in design and relatively affordable compared to commercial controllers meant for music... but you don't actually need any to ChucK. I wouldn't make porting ChucK dependant on a complete HID game device implementation. The one in ChucK is incomplete as well and doesn't (yet) support HID output (for things like leds, rumble and force-feedback). I hope that helps a bit. Yours, Kas.
On Mon, Sep 29, 2008 at 11:20 AM, Kassen
Will Maier;
How much of this interface needs to actually be implemented? I've been reading the code, and it seems that at least some of it could simply remain unsupported while still making ChucK at least somewhat usable.
Strictly speaking I don't think you need it at all to have a usable ChucK; ChucK was fine before we had it.
Personally I'm a big fan of the Joystick HID interface; I find game controllers to often be very expressive, inspirational in design and relatively affordable compared to commercial controllers meant for music... but you don't actually need any to ChucK.
I wouldn't make porting ChucK dependant on a complete HID game device implementation. The one in ChucK is incomplete as well and doesn't (yet) support HID output (for things like leds, rumble and force-feedback).
I hope that helps a bit.
Yes, I think for cases like this ChucK sorely needs a ./configure portion to its build, but I don't know if that will happen. I'd be happy to write some autotools stuff for it, but I don't know if Ge would go for it. Anyways, autotools would be enough to detect that HID is not supported by the platform and disable it in the build. It might be helpful. Steve
Hi Kas- On Mon, Sep 29, 2008 at 05:20:26PM +0200, Kassen wrote:
Strictly speaking I don't think you need it at all to have a usable ChucK; ChucK was fine before we had it. Personally I'm a big fan of the Joystick HID interface; I find game controllers to often be very expressive, inspirational in design and relatively affordable compared to commercial controllers meant for music... but you don't actually need any to ChucK.
I wouldn't make porting ChucK dependant on a complete HID game device implementation. The one in ChucK is incomplete as well and doesn't (yet) support HID output (for things like leds, rumble and force-feedback).
Cool -- thanks for the input (no pun intended, honestly). ;) I'd love to have HID support on OpenBSD someday since, as you say, it opens up lots of very cool options. For now, though, I implemented a null-HID skeleton to make things build on OpenBSD. With my updated patchset[0], I can build chuck itself and run the examples. Whee! As I said before, I'm very happy to provide access to an OpenBSD machine if any ChucK developers are interested in extending support to our system. If there's anything I can do to make it more likely that you'll incorporate my patchset upstream, I'm happy to do that work, too. Thanks again for the quick help (and the wonderful software)! [0] http://www.lfod.us/~will/chuck-openbsd-2.diff -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/]
Hi Kas-
Hi Will, For now, though, I implemented a null-HID skeleton to make things
build on OpenBSD. With my updated patchset[0], I can build chuck itself and run the examples. Whee!
That's good news! In your patch I didn't notice any reference to KBHit, a older, more simple, interface in ChucK to the computer's keyboard. I'm not sure whether that depends on true HID support, you may want to check that out ( there's a demo in /examples/event/ ). If that does work you're in luck because keyboard input can be very convenient in debugging ChucK code and of course with so many keys there's a lot of space for instrument design. It might also be good to point out that the true "joy of joypads" comes with low latency audio though when this is missing MIDI output linked to a external synth is still loads of fun. At least you're up&ChuKing now, quite fast as well so that speaks highly of you and ChucK's portability. It'll be interesting to see how BSD with it's pride in stability will get along with ChucK's style of crashing as a performance art ;¬). Congratulations on your progress so far! Yours, Kas.
Hi Kas- On Tue, Sep 30, 2008 at 03:48:02AM +0200, Kassen wrote:
That's good news!
I agree; I had a good time noodling yesterday. So far, so good...
In your patch I didn't notice any reference to KBHit, a older, more simple, interface in ChucK to the computer's keyboard. I'm not sure whether that depends on true HID support, you may want to check that out ( there's a demo in /examples/event/ ). If that does work you're in luck because keyboard input can be very convenient in debugging ChucK code and of course with so many keys there's a lot of space for instrument design.
Thanks for the pointer; the KBHit demos _do_ work without any further modification (excellent!). I'll also probably look into OSC eventually, too (very cool to see it supported as well).
It might also be good to point out that the true "joy of joypads" comes with low latency audio though when this is missing MIDI output linked to a external synth is still loads of fun.
Ah, MIDI. rtmidi.c supports IRIX, Mac OSX, Windows and Linux but not, sadly, OpenBSD. We have a pretty standard OSS-based MIDI API (read/write/poll the device file), but the RtMidi* abstraction doesn't seem to have this yet. Again, if there's interest in adding OpenBSD (or OSS) MIDI support, I'm happy to provide whatever support I can. Thanks again! -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/]
participants (3)
-
Kassen -
Stephen Sinclair -
Will Maier