[chuck-users] code reusability

Sat Jun 12 11:21:23 EDT 2010

I would be happy to help make something too, although I would say we should
use Python for two reasons:

1) I know Python much better than Perl.
2) Python enforces much more legible code.

I would love to be able to be able to create a wrapper for the executable
keeps Chuck VM alive and adds the appropriate class definitions to the
running VM.  When Chuck crashes, for instance, this process should notice
Chuck is not running, restart the VM and load up the last library set used
(unless the user begins a new session).  This would actually reduce the need
for #include <blah> statements, since your library could just be loaded when
Chuck starts--public classes and all.

Lucky for us, Andrew, we live in the same city.  :)  If you're into this, I
have some time coming up and would be glad to start working on this sooner
rather than later.

Mike

2010/6/11 Andrew C. Smith <andrewchristophersmith at gmail.com>

> Yeah, that's my concern. I mean, that doesn't really work for using public
> classes as buses or something. Or, in my case, I use a public class called
> Scala to control the global tuning of all my microtonal Scala.mtof(int
> midiNote) functions.
>
> Anyway, good to see this. Maybe we can collectively work to make something
> even more adaptable? I'm willing to learn Perl a bit better.
>
> Andrew
>
>
> On Jun 11, 2010, at 3:47 PM, mike clemow wrote:
>
> You make non-public classes, and the perl script basically appends those
> classes to your script and creates a temporary file to send to the vm.
>
> it's hacky, but it works.
>
> #ifdef does NOT work.  only #include (myfile)
>
> mike
>
> 2010/6/11 Andrew C. Smith <andrewchristophersmith at gmail.com>
>
>> It's not clear to me--does #ifdef work? If not, you'd end up instantiating
>> the same public class more than once.
>>
>> Also, a single file can only define one public class at a time, right? So,
>> you'd have to spork a different shred for every class, and not just throw
>> them all into one file. I may be misunderstanding the code though, because I
>>  don't know Perl very well at all, and I'm preoccupied with something else
>> right now.
>>
>> On Jun 11, 2010, at 1:50 PM, mike clemow wrote:
>>
>> Scott Wheeler's script is exactly that.  You should have a look.  The only
>> thing is that it doesn't handle chuck command line args well.
>>
>> maybe some perl guru would be willing to have a go at modifying it.
>>
>> Mike
>>
>>
>>
>> 2010/6/11 Andrew C. Smith <andrewchristophersmith at gmail.com>
>>
>>> Hm, what about setting up some kind of python (or perl, etc...) script to
>>> pre-process ChucK and handle all statements preceded by a #? So, you could
>>> totally do the whole #IFDEF thing and make that work. That might be a
>>> worthwhile library of stuff to do.
>>>
>>> Andrew
>>>
>>>
>>> On Jun 11, 2010, at 12:08 PM, mike clemow wrote:
>>>
>>> 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
>>>
>>>  _______________________________________________
>>> 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
>>
>>  _______________________________________________
>> 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
>
>  _______________________________________________
> 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/20100612/09c45d33/attachment.htm>