Chuck-devs, While working on a chuck embedding project of my own, a had a bit of an idea in relation to future chuck projects. To fit chuck into my target application, I had to define an interface and make a few minor changes to get things to work properly. In all cases so far, I just call the main method with arguments depending on if I want it to start looping, or send an OTF command. Besides the application specific stuff, here are the changes I've made: 1. When calling {"chuck" "--loop"}, you must create a new thread. 2. Replaced a few "exit" calls after OTF commands (on success and failure) with returns. "exit"ing from a library is not a good idea. In addition, I've got some design yet to do, as well as figure out how to set variables, etc. Anyway, I'm not the only one doing an embedding. Brad and Martin have ported chuck to Max/MSP and pd respectively. I imagine chuck will be an attractive option for adding interactive procedural music to games and other applications in the future. Perhaps we should create and extend a standard chuck library interface, so the behavior of the library will become more well understood and the cost of the embedding will be easier, as well as stay current with the source tree. Graham
On Wed, Nov 01, 2006 at 06:39:38PM -0500, Graham Coleman wrote:
Perhaps we should create and extend a standard chuck library interface, so the behavior of the library will become more well understood and the cost of the embedding will be easier, as well as stay current with the source tree.
I think this is an excellent idea actually. It would certainly be much easier to keep chuck~ and any other project synced with the source tree. martin robinson
participants (2)
-
Graham Coleman
-
Martin Robinson