[chuck-users] Class Libraries, File Naming Conventions, and 'machine.add(...)'

[Spencer Salazar]

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