determining the type of an Object in code
Hi list, Is there a way to determine an object's type programmatically? Cheers, Mike -- http://semiotech.org http://semiotech.org/michael
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.
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
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
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 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
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
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
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
Mike 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. 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. Is the ChucK wiki the best place to post it for collaboration? 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
Dan,
On Thu, Sep 4, 2008 at 11:51 PM, Dan Zinkevich
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
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
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
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!
On Fri, Sep 5, 2008 at 11:40 AM, Michael Heuer
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.
There weren't spaces at the beginning of every line. (fixed: pbpaste | sed 's/^/ /g' | pbcopy) -- Tom Lieber http://AllTom.com/
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
Oh, nice. Those look cool too. Perhaps the electromusic forum is a
better place for this kind of thing?
-mike
On Fri, Sep 5, 2008 at 5:39 PM, 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 _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
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
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.
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,
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;
<<
On Sun, Sep 7, 2008 at 2:47 PM, Michael Heuer
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:
Sorry, this bit might be useful too class Qux { fun int garply() { return 42; } }
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
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
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.
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
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
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
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
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
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.
On Tue, Sep 9, 2008 at 8:26 AM, Kassen
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
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
mike clemow; Good idea. So, I just added a Chuck/Lib page to the Wiki:
Great! I tweaked my example slightly to work more like adc and dac (which will look cleaner and perhaps make people confuse the two types of brackets...) and added it. Also got started on the libs page itself. It's just a start, I hope others will "come out to play". Cheers, Kas.
Tom Lieber
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.
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
Michael Heuer; 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" ?
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 :¬). Yours, Kas.
On Wed, Sep 17, 2008 at 5:41 PM, Kassen
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
participants (8)
-
Dan Zinkevich
-
Daniel Zinkevich
-
Kassen
-
Michael Heuer
-
mike clemow
-
Peter Todd
-
Stefan Blixt
-
Tom Lieber