
Hey Mike,
Since the release of 1.2.0.5, I have been working with miniAudicle, and I really like what I see so far (up to this point, I had been using the commandline version of ChucK). So, I am not sure if there is a separate email list for the miniAudicle, or if I should send the email here, or to the Audicle list... so...
awesome! glad its working out for you. Uhhh, its fine by me if miniAudicle questions go either here or to the audicle list, but if anyone thinks thats too off-topic (Ge...?) maybe i could set up a separate list for those questions. But in any case, as it looks like these questions are related to chuck in general, we can probably discuss them here.
Here are the issues that I see so far...
(1) Would it be possible to allow for miniAudicle to have multiple paths that it would search for finding these libraries?
This is certainly possible, and seems like a pretty good idea to me. It would also be useful for things like sndbufs and WvOuts, where your sound files could theoretically be in any numbers of distinct directories. It would probably have to be a part of chuck rather than just the miniAudicle, since miniAudicle cant do that without changing the machine.add() implementation.
(2) Am I using 'machine.add(...)' for its intended purpose (in loading classes)? Might there be a good reason to add another 'machine.load(...)' that does the same thing as 'add', except it does not spork a new shread for each call? This 'load' function could also be made to keep track of what files have been loaded, and any time there is a file that gets loaded more than once, any subsequent loads could just be ignored? (This might also change the miniAudicle interfact to include a button to load, in addition to the other buttons.) Would this function be best named 'load'/'include'/'import'? Which one?
Seems reasonable to me to use machine.add() for loading classes. while machine.add() does spork a new shred, programs that only define a new public class will exit immediately anyways. Also, chuck already rejects files that try to redefine public classes, with a compilation error. So functionally machine.add() operates very similarly to such a load routine, even though they might be conceptually different operations. Although there are certainly cases where extended class library loading functionality would be desirable.
(3) Any thoughts on why the classes do not load when I have subsequent code in my program (after the 'machine.add')?
Thats strange... I have not come across this behavior in similar programs. Are you getting any unusual messages on the Console Monitor? thanks! spencer