mike clemow;

I wanted to write a class that would abstract arrays like the Collection class in SuperCollider. I guess I can't. I would have to write a class for each type of object that I wanted to make Collections of.

I think you are right. I'd like a way to address arrays because there are many things one might like to do to arrays that don't depend on the type; removing a object, inserting one, randomising or reversing the order of the locations, etc, and right now you can't. The same goes for Ugens, it might be nice to be able to reason about those in a more abstract way, for example to re-connect them yet I don't think you can write a function that takes something of type "Ugen" as a argument or returns one. Yours, Kas.

Hi Daniel, I personally believe that it's in the best interest of the Chuck community if this discussion stays on-list. I hope that's okay with you--I'm not trying to step on anyone's privacy here. How exactly are you getting around the typing issue? Cheers, Mike On Wed, Sep 3, 2008 at 6:50 PM, Daniel Zinkevich wrote:

Hi list,

New here, and to ChucK in general, but I'm also working on a similar collection class. Don't want to step on anyone's toes, Mike, let's talk dzinkevich@gmail.com

DFZ

On Wed, Sep 3, 2008 at 6:29 PM, mike clemow wrote:

...

I wanted to write a class that would abstract arrays like the Collection class in SuperCollider. I guess I can't. I would have to write a class for each type of object that I wanted to make Collections of.

-Mike

On Wed, Sep 3, 2008 at 5:17 PM, Kassen wrote:

...

2008/9/3 mike clemow

...

Hi list,

Is there a way to determine an object's type programmatically?

I don't think so, I thought for a moment that we could write a massively overloaded function but then remembered arrays are separate types and

int foo[ ];

is a different type from

int bar[ ] [ ];

So we'd need a infinitely overloaded function...

I'm not sure why you could need this. I'm not sure in what kind of situation you would get a object from somewhere yet be unaware of it's type; because of our strong typing I don't think we ever get such objects (which can be nice yet is related to limitations as well).

Could you illustrate the issue?

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael

Dan, On Thu, Sep 4, 2008 at 11:51 PM, Dan Zinkevich wrote:

I haven't gotten around the typing issue yet, I'm working exclusively w/ floats, since they're relatively simple to convert to ints and durs.

That's true, I hadn't thought about that. Similarly, I'm working with one datatype: an object that is supposed to contain the data necessary to play a grain in granular synthesis. I have a limited set of grain-types worked out and I'm trying to built higher and higher levels of semantics to describe them. I'm leaning heavily on arrays for this. Or that's my plan, anyway. To be honest, so far I'm just going through SuperCollider documentation and stealing ideas for methods... ;-)

I started out w/ ChucK and put together a pretty reusable class this past weekend, that includes all your standard add/subtract/merge/pop/no dups, etc, as well as a few different sorting algos (up/down/converge/diverge/random for now), with the long-term idea to create a flexible sequencer or arpeggiator. It would be great to apply these to a collection-like superclass, so I was hoping any headway (if any) could be shared before I get too married to floats.

That sounds really helpful, actually. One thing I learned from the SC docs on their Collection class was that they have borrowed a bunch of tricks from functional programming that, in the context of arrays, might make it a bit more worth while to use functors in Chuck. A lot of their Collection methods take functions as parameters and iterate the function with the array values as inputs to the functions and return the results as an array or collect them as a single item. This might be very helpful in the case of floats, since you could encapsulate a lot of mathematical operations as functors and save on all that "for( 0 = int i; i < ... " business.

Is the ChucK wiki the best place to post it for collaboration?

Sounds like as good a place as any. -Mike

DFZ

mike clemow wrote:

...

Hi Daniel,

I personally believe that it's in the best interest of the Chuck community if this discussion stays on-list. I hope that's okay with you--I'm not trying to step on anyone's privacy here. How exactly are you getting around the typing issue?

Cheers, Mike

On Wed, Sep 3, 2008 at 6:50 PM, Daniel Zinkevich wrote:

...

Hi list,

New here, and to ChucK in general, but I'm also working on a similar collection class. Don't want to step on anyone's toes, Mike, let's talk dzinkevich@gmail.com

DFZ

On Wed, Sep 3, 2008 at 6:29 PM, mike clemow wrote:

...

I wanted to write a class that would abstract arrays like the Collection class in SuperCollider. I guess I can't. I would have to write a class for each type of object that I wanted to make Collections of.

-Mike

On Wed, Sep 3, 2008 at 5:17 PM, Kassen wrote:

...

2008/9/3 mike clemow

...

Hi list,

Is there a way to determine an object's type programmatically?

I don't think so, I thought for a moment that we could write a massively overloaded function but then remembered arrays are separate types and

int foo[ ];

is a different type from

int bar[ ] [ ];

So we'd need a infinitely overloaded function...

I'm not sure why you could need this. I'm not sure in what kind of situation you would get a object from somewhere yet be unaware of it's type; because of our strong typing I don't think we ever get such objects (which can be nice yet is related to limitations as well).

Could you illustrate the issue?

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael

Can't you use <pre> to format code on the wiki? http://meta.wikimedia.org/wiki/Help:Wikitext_examples /Stefan On Fri, Sep 5, 2008 at 5:40 PM, Michael Heuer wrote:

mike clemow wrote:

...

Dan,

On Thu, Sep 4, 2008 at 11:51 PM, Dan Zinkevich wrote: <snip/>

...

Is the ChucK wiki the best place to post it for collaboration?

Sounds like as good a place as any.

Posting to the wiki requires you to reformat the code

"note: In your code listings, remember to put a space before every line in the code, including empty lines - otherwise the wiki will render the code into multiple blocks."...

and even then it might screw it up, e.g.

http://wiki.cs.princeton.edu/index.php/ChucK/foo.ck

The forum accepts ChucK source files as attachments

http://electro-music.com/forum/forum-140.html

michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

For what it's worth, I have updated my List APIs to use resizeable arrays and posted them to the forum at http://electro-music.com/forum/viewtopic.php?t=21725 Each file contains some "unit tests" so you might look to those for examples on how to use the list classes. michael

2008/9/5 Michael Heuer

For what it's worth, I have updated my List APIs to use resizeable arrays and posted them to the forum at

http://electro-music.com/forum/viewtopic.php?t=21725

Hey! This is really nice. I never realised you could refer to Object and UGen like that (I looked it up and the manual does mention Object as well as UGen). I tried to do something this for UGen a few times but I think I always mis-typed it as "Ugen" or something. Thanks! Hmmm, after testing I found that sadly the following will run (without errors) but won't "fly"; =============== SawOsc s => UGen patchpoint => dac; second => now; new LPF @=> patchpoint; second => now; ======================== It seems that asignment to a UGen doesn't affect the Ugen-graph? Yours, Kas.

Kassen wrote:

2008/9/5 Michael Heuer

...

For what it's worth, I have updated my List APIs to use resizeable arrays and posted them to the forum at

http://electro-music.com/forum/viewtopic.php?t=21725

Each file contains some "unit tests" so you might look to those for examples on how to use the list classes.

Michael,

Do I understand correctly that the top file, the one that deals purely with Object's, works but is mainly of interest from a academic perspective? I like what you are doing but it's not clear to me how we would get the results out at the other end without being able to tell anything about the type, beyond it being a "Object" and getting it's memory location.

Is this purely meant as a abstract demonstration?

Yours, Kas,

Hello Kas, ChucK has a cast operator, so you should be able to cast the result of List.get(int), Iterator.next(), or the object parameter in a forEach(UnaryPredicate) to what you expect the Object to be. This works: ArrayList list; Qux qux0; Qux qux1; Qux qux2; list.add(qux0); list.add(qux1); list.add(qux2); list.get(0) $ Qux @=> Qux qux; <<>>; $ chuck --silent list_of_qux.ck 42 :(int) michael

I was wondering whether that would work! Like this works, for instance: SinOsc s; s @=> Object o; o $ SinOsc @=> SinOsc osc; 500 => osc.freq; osc => dac; 1::second => now; It's the same principle, anyway. cheers, mike On Sun, Sep 7, 2008 at 3:47 PM, Michael Heuer wrote:

Kassen wrote:

...

2008/9/5 Michael Heuer

...

For what it's worth, I have updated my List APIs to use resizeable arrays and posted them to the forum at

http://electro-music.com/forum/viewtopic.php?t=21725

Each file contains some "unit tests" so you might look to those for examples on how to use the list classes.

Michael,

Do I understand correctly that the top file, the one that deals purely with Object's, works but is mainly of interest from a academic perspective? I like what you are doing but it's not clear to me how we would get the results out at the other end without being able to tell anything about the type, beyond it being a "Object" and getting it's memory location.

Is this purely meant as a abstract demonstration?

Yours, Kas,

Hello Kas,

ChucK has a cast operator, so you should be able to cast the result of List.get(int), Iterator.next(), or the object parameter in a forEach(UnaryPredicate) to what you expect the Object to be. This works:

ArrayList list; Qux qux0; Qux qux1; Qux qux2;

list.add(qux0); list.add(qux1); list.add(qux2);

list.get(0) $ Qux @=> Qux qux; <<>>;

$ chuck --silent list_of_qux.ck 42 :(int)

michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael

A proposal: This is great stuff, actually. I'm really excited about the prospect of putting together a really great List/Collection/Array class lib so that we no longer have to look on in envy of SuperCollider's arrays (just speaking from experience here ;-). I'm totally willing to re-work my current code, which abstracts a pattern of grain definitions for granular synthesis, to use or extend a more abstract superclass of objects in an array. I have time to work on this (and get course credit for it, happily). So, there's Michael's List, ListArray, etc classes and we also have heard from Dan, who's working on something similar. I'm wondering if we can pool our efforts and make something really useful and complete. Is there any interest in this? If yes, how should we go about setting this up? -Mike On Mon, Sep 8, 2008 at 1:57 AM, Kassen wrote:

2008/9/7 Michael Heuer

...

Hello Kas,

ChucK has a cast operator, so you should be able to cast the result of List.get(int), Iterator.next(), or the object parameter in a forEach(UnaryPredicate) to what you expect the Object to be. This works:

Wow! Great stuff!

Thanks a lot for taking the time to figure this out and share.

Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael

Absolutely--the more the merrier. It pains me to see the community duplicating the effort over and over again. So, there's Mie's code, Dan's code, your code (Michael), and my code. Where should we start? Mine's not a good place, since it's really specific, although it will make a good extension of the base classes. How should we organize this? -Mike On Mon, Sep 8, 2008 at 1:04 PM, Michael Heuer wrote:

mike clemow wrote:

...

A proposal:

This is great stuff, actually. I'm really excited about the prospect of putting together a really great List/Collection/Array class lib so that we no longer have to look on in envy of SuperCollider's arrays (just speaking from experience here ;-).

I'm totally willing to re-work my current code, which abstracts a pattern of grain definitions for granular synthesis, to use or extend a more abstract superclass of objects in an array. I have time to work on this (and get course credit for it, happily).

So, there's Michael's List, ListArray, etc classes and we also have heard from Dan, who's working on something similar. I'm wondering if we can pool our efforts and make something really useful and complete.

Is there any interest in this? If yes, how should we go about setting this up?

Hopefully we can invite "Mies" into the mix:

http://electro-music.com/forum/topic-19513-0.html

http://chuck-lib.wikispaces.com/Utils

michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael

On Tue, Sep 9, 2008 at 8:26 AM, Kassen wrote:

How about simply having a WiKi section for "library -like" code?

Good idea. So, I just added a Chuck/Lib page to the Wiki: http://wiki.cs.princeton.edu/index.php/ChucK I think that anyone who's working on code to enhance the usefulness of arrays or other similar efforts, should post their code here. Also this would make a good platform for collaboration, like Kassen suggested. So, once I'm through with getting a prototype working, I'll post my miserable hack and all you smart CS people can help clean it up. ;-) Meanwhile, if anyone's working on stuff that is effort along a similar vein, then please post it. Since, Mies is working on what looks like a "definitive" project, in the sense that it's goal is to collect a set of functions that will rival the RTC-lib for Max, then the Wiki might provide an interesting testing ground for ideas. Sound good? -Mike On Tue, Sep 9, 2008 at 8:26 AM, Kassen wrote:

mike clemow;

...

How should we organize this?

How about simply having a WiKi section for "library -like" code?

I like this simple snippet a lot lately;

=============== public class buses { static Gain @ bus[8]; }

new Gain[8] @=> buses.bus; ==========================

Really basic but it gets you a lot of options in improvised routing. For example to keep FX separate from instruments. From here on any shred and send sound to and/or take sound from those buses.

We could collect such extra features for ChucK build in ChucK itself for everyone to share. The WiKi could be a nice place to archive these and it's also a nice place to collaborate on making them?

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://semiotech.org/michael

Tom Lieber wrote:

On Fri, Sep 5, 2008 at 11:40 AM, Michael Heuer wrote:

...

mike clemow wrote:

...

Dan,

On Thu, Sep 4, 2008 at 11:51 PM, Dan Zinkevich wrote: <snip/>

...

Is the ChucK wiki the best place to post it for collaboration?

Sounds like as good a place as any.

Posting to the wiki requires you to reformat the code

"note: In your code listings, remember to put a space before every line in the code, including empty lines - otherwise the wiki will render the code into multiple blocks."...

and even then it might screw it up, e.g.

http://wiki.cs.princeton.edu/index.php/ChucK/foo.ck

There weren't spaces at the beginning of every line. (fixed: pbpaste | sed 's/^/ /g' | pbcopy)

I noticed that Processing has a menu option "Copy for Discourse" which does this for you. Perhaps a new feature for the Mini, "Copy for Wiki" ? michael

On Wed, Sep 17, 2008 at 5:41 PM, Kassen wrote:

Somewhat unrelated but I noticed that the Spore "creature creator" demo (a demo for a new computer game) has a feature to directly export a video of your creation to Youtube. This struck me as a rather clever move of theirs to get some free viral marketing. Currently they seem to be finding out what happens if you lower the treshold far enough in the form of videos deemed obscene but some but that's beside the point.

It struck me that it might be nice for a future update to the Audicle to have a feature like that for sharing performances. Likely this wouldn't be suitable for documenting bugs because a crashed Audicle would mean no video but as a way of sharing short performances I like it.

Hopefully CPU's will be fast enough for such plans by the time we'd get round to this :¬).

Probably would be more practical CPU wise to record all user input etc, probably along with audio, then render to video after. I think Fluxus has some similar features now (not sure about the video rendering, but I definitely read something about recording keystrokes / OSC - not exactly sure). Cheers, Peter