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 wrote:

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

Um... does miniAudicle count? ;-) -Mike On Fri, Oct 16, 2009 at 2:00 PM, Hans Aberg wrote:

On 16 Oct 2009, at 17:28, Andrew C. Smith wrote:

...

...--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.

As an example on bindings, emacs-23.1 can produce a Mac OS X Nextstep/Cocoa Application by  ./configure --with-ns  make  make install which produces an app in the directory nextstep/; the file nextstep/INSTALL also tells how to compile it from Xcode. It can also bind to X11 and GTK.

It seems that the technique would allow for blending of components (though perhaps not the program).

 Hans

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

I was mostly thinking about the way of producing the binary - as traditional "configure-make" UNIX package or Xcode, and there are different bindings: Cocoa-NextStep, X11, GTK. It is easy to compile, and it should simplify modification and adding components. Hans On 16 Oct 2009, at 20:40, Andrew C. Smith wrote:

Right, what I should say is that I don't really want an editor for ChucK files. I basically just want a program that uses ChucK as its DSP engine. I am looking at the mini, though, and once I get it to compile properly I'll see if I can figure it out. One stumbling block is the absence of .xib files, though--Spencer's source only has the .nib files. Are the .xibs available? That would make it possible to extend/break the mini pretty well, I think.

Andrew

On Fri, Oct 16, 2009 at 2:15 PM, mike clemow wrote:

...

Um... does miniAudicle count?

;-)

-Mike

On Fri, Oct 16, 2009 at 2:00 PM, Hans Aberg wrote:

...

On 16 Oct 2009, at 17:28, Andrew C. Smith wrote:

...

...--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.

As an example on bindings, emacs-23.1 can produce a Mac OS X Nextstep/Cocoa Application by ./configure --with-ns make make install which produces an app in the directory nextstep/; the file nextstep/INSTALL also tells how to compile it from Xcode. It can also bind to X11 and GTK.

It seems that the technique would allow for blending of components (though perhaps not the program).

Hans

On Oct 16, 2009, at 3:53 PM, Brad Garton wrote:

...

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?

Yep.

Oops -- just re-read that. Max actually 'pumps' chuck for each vectors-worth of samples, so chuck isn't really running max, it's sort of the reverse. Instead of the CoreAudio driver grabbing the buffers from ChuCk, Max does. brad http://music.columbia.edu/~brad

Hi, I have playing with ChucK quite alot recently though I teach Max/MSP currently. Im finding that in many situations I choose to use Max due to the application building functionality it offers. Means you can build an app and then just give it to people to use. In the OSX world the apps tend to just run as well no installs. Having that kind of functionality could be really with useful for ChucK, the ability to integrate the code and the VM into a single executable file that a user can just run would be great. I guess this sort of functionality would maybe require more GUI objects directly from ChucK rather than integration with other languages for the GUI. Scott On Fri, Oct 16, 2009 at 4:28 PM, Andrew C. Smith wrote:

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 wrote:

...

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

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

hi, Never thought of that approach guess you could just write an executable script and give it a nice image in the finder. Like it. As for the Max issue I agree the ChucK object is great fun though I think the cost and licensing issues associated with Max would make me look towards processing or some other OSC aware language first, even though it may make the end product more complex to setup and use. scott On Sat, Oct 17, 2009 at 1:15 AM, Andrew C. Smith wrote:

Scott,

That's kind of the case, actually. Aside from GUI functionality not being available in the console, you could absolutely just create a script that runs "chuck crazysounds.ck" and as long as they were in the same directory the whole thing would work perfectly (enough). For the mini, I believe you can add arguments to it or something like that--either way, it's not that hard to just hit start on the VM and then open a file and chuck it.

If you want more GUI features (and are using a Mac) then Brad's chuck~ object for Max works pretty well. It's a nice alternative to MSP, because MSP just doesn't do it for me.

On Fri, Oct 16, 2009 at 5:56 PM, Scott Hewitt wrote:

...

Hi,

I have playing with ChucK quite alot recently though I teach Max/MSP currently.

Im finding that in many situations I choose to use Max due to the application building functionality it offers. Means you can build an app and then just give it to people to use. In the OSX world the apps tend to just run as well no installs.

Having that kind of functionality could be really with useful for ChucK, the ability to integrate the code and the VM into a single executable file that a user can just run would be great.

I guess this sort of functionality would maybe require more GUI objects directly from ChucK rather than integration with other languages for the GUI.

Scott

On Fri, Oct 16, 2009 at 4:28 PM, Andrew C. Smith wrote:

...

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 wrote:

...

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

_______________________________________________ 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

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Oh no, I can't believe I never thought of this. TAPESTREA totally uses ChucK as a DSP engine for all sorts of stuff. That's basically what I'm talking about, too. Thank you Internet. Andrew On Sat, Oct 17, 2009 at 3:16 PM, Andrew C. Smith wrote:

Oh, that's a good thought too. That's sort of what I proposed for Scott, since he talked about an application.

What I was thinking, though, would be more like a stand-alone synthesizer. So, (as an example--not what I'm working on) you could make a drum machine with controllable effects. ChucK would be the DSP engine for it, and it would make heavy use of public classes (and static functions within them) to act as buses for the effect parameters.

Bonus points if you encapsulate the entire thing into a script, so that you run a script and it detects the next bus number--it both writes and chucks the file containing:

public class BusX (where X = the next available bus number) { ... get/set static functions ... }

You wouldn't need to differentiate between control and audio buses, as you can set sampling rates on your own. Audicle might actually be a relevant program to look into, partly because it's contained entirely in OpenGL. The issue (for me) is that all of that stuff was made in 2004-2006 and never updated, so there are loads of deprecated methods and frameworks or libraries that just aren't really used. For example, the mini uses RBSplitView which hasn't been updated since 10.3.9, and the "Palette" refers to something from (I think?) a much earlier version of Interface Builder. Someone correct me if you can open the .nib files with Xcode 3.2, though. I'll update whenever I get a running version of a ChucK DSP engine. Maybe it could be a tutorial.

Andrew

On Sat, Oct 17, 2009 at 2:09 PM, Joe McMahon wrote:

...

On Oct 15, 2009, at 9:07 PM, 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?

I've done an Applescript program that computes a Long Now chime and then plays it using ChucK. The interactivity is limited to setting the date and then running ChucK as a shell command. Is that the kind of thing you meant?

 --- Joe M. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 17 Oct 2009, at 21:16, Andrew C. Smith wrote:

For example, the mini uses RBSplitView which hasn't been updated since 10.3.9, and the "Palette" refers to something from (I think?) a much earlier version of Interface Builder. Someone correct me if you can open the .nib files with Xcode 3.2, though. I'll update whenever I get a running version of a ChucK DSP engine. Maybe it could be a tutorial.

This links says that they are deprecated: http://en.wikipedia.org/wiki/.nib You can try in Terminal: touch test.nib open test.nib touch test.xib open test.xib The first 'open' says there is no app, the second opens Interface Builder. Then try to open the .nib from within that app; it says it can't open compiled nibs. Hans