[chuck-users] code reusability

mike clemow michaelclemow at gmail.com
Fri Jun 11 12:08:27 EDT 2010


Hey, I'd like to recall this thread:
https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.html

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time.
 I really liked the concept.  It did not work well with command line
arguments, however, the benefits as far as code-reuse were really nice.
 Obviously, things had to be imported in the correct order, but I think that
there might be a way around it, if each file you import also imported its
prerequisites.  IMHO, Chuck really needs something like this in order to
make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built
in.  It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop &
$ chuck + import.ck       // imports entire library
$ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have
to also open the import.ck file and run it before running any other code.
 You have to repeat all this when it crashes (which is something that
happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code...  easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike




On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman <dtrueman at princeton.edu>wrote:

> i believe in the next release you'll be able to open MIDI/Hid devices by
> name...
>
> On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:
>
> > Okay, that's pretty much what I did. Trying all the devices until I find
> > the one with the proper name is a good idea, thanks !
> >
> > Tom
> >
> > On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:
> >> Hi Thomas!
> >>
> >> What I use for this kind of case (my Akai LPD8, for example) is a class
> with
> >> it's own sporked listener shred.
> >>
> >> At instantiation it could try to open all MIDI devices in turn, until
> the name
> >> of the device is whatever the name of your controller is. from there on
> you can
> >> add members and member functions that reflect whatever you want to do
> with the
> >> device, including a public event that other shreds could wait for. In
> the case
> >> of controllers with leds you'd probably also have member-functions that
> your
> >> code could use to set these, with your class handling the MIDI.
> >>
> >> If you build something like that once it will save you a lot of time in
> the
> >> long run and only having to do MIDI (with all of its magic numbers) once
> should
> >> make your coding a lot more pleasant. The class could sit in its own
> file (if
> >> you make it public), or you could simply copy and paste it to the bottom
> of
> >> your current project.
> >>
> >> Hope that helps?
> >> Kas.
> >
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>



-- 
http://michaelclemow.com
http://semiotech.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100611/4348efe3/attachment.html>


More information about the chuck-users mailing list