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