Thanks all, it's good to hear people are building things. I have
looked into Processing, but just don't really have the urge to learn
it--would rather just work with Cocoa windows to allow for
nearly-infinite extensibility. I already got a Cocoa interface working
with OSC, using the Objective C library VVOSC (highly recommended for
anyone doing Cocoa programming with OSC). Like Brad, though, I'm
looking to get more control over the DSP environment with a direct
wrapper.
Brad, I didn't think about your Max object, which seems like a logical
model now that you mention it. In fact, I could probably do all of
what I'm doing in Max, but where's the challenge in that?
One thing, though, is that you're making ChucK output its sound to the
Max/MSP interface, while I really just want it to output it to its
default place (that is, CoreAudio or whatever else I make available
from a mini-like menu option). So, I don't really mind using OSC to
communicate over port 8888 (the ChucK-controller port), but I
basically just want to make the user only start up one application
instead of multiple apps, as is the case with the OSCSurface
controller.
So, Brad, do you first "make maxmsp" in chuck-maxmsp.1.2.1.2/src, then
use the resulting chuckdylib.so to run the engine in Max? This is
tentative, because I don't really know what I'm talking about, but can
NSCreateObjectFileImageFromFile with NSLinkModule link to a
chuckdylib.so-type library in any environment (not just Max)? And,
finally, thank you for commenting the source so heavily, including
things like "BIG HACK" to point out where ChucK might trip someone up.
I'll post a working product if I ever get one.
Andrew
On Fri, Oct 16, 2009 at 8:55 AM, Brad Garton
I prefer a 'tighter' connection between the DSP engine (in this case chuck) and the enclosing app-environment. Although I need to update it to reflect the latest chuck-ness (which shouldn't be too hard), I set chuck up for the maxp/msp chuck~ object as a loadable lib that can be built right into the application. This gives access to all chuck functionality within the app.
brad http://music.columbia.edu/~brad
On Oct 16, 2009, at 12:07 AM, Andrew C. Smith wrote:
Has anyone tried to wrap ChucK into a standalone program? I'm thinking (at the very least) it could just be made to run simultaneously and communication could be made over OSC, but it would be cool to have the whole thing communicate through 8888, the port that the console communicates on. Basically, the mini is an effective wrapper, right? I'm just wondering if anyone has created anything simpler, like even just a program that outputs ChucK sounds when you click buttons or something. It would be really cool for games (or toys, not really games) that let users play around with sounds using an integrated graphical interface. Anyone try it?
Andrew _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users