Dear All,
chuck-1.2 is on the way.
(but this email will reach you before it does.)
As you may (or may not) be wondering: it is now February, where is
ChucK-1.2? We have pushed back the release (again), this time to March.
However, this _will_ be the final delay. We have been busy writing papers
(one of them, ironically, is about implementing ChucK) in the last month
or so, trying to meet submission deadlines (3 of which fell within the
same week). We are on the last spin cycle of paper writing, and can
return to full-time development on 1.2 in 2 weeks. You may be
wondering: how can we guarantee a March release? Answer: we release what
we have at the end of March, even if some things are not yet done.
As for the actual status of the new release:
---
done:
- 90% code/testing the new type system, which supports arrays (both
integer and associative), defining new objects, environments/contexts for
organizing the namespace, new operators (+=>, *=>, ^=>), object
references, many small fixes.
- 50% code/testing the emitter and new virtual machine bytecodes. Not
too much code needs to be written for supporting arrays/objects - heavy
testing is very much needed.
- various fixes in all parts of the system
todo:
- the other 10/50% of system
- function overloading
- more powerful library import mechansim
- more powerful unit generator import mechanism
- a very basic class library
- stereo/multichannel support
- testing testing
- documentation for new features
in progress:
- Adam Tindale is putting together (gasp) comprehensive documentation
- Ajay Kapur has been investigating using ChucK for real-time controllers
- Phil is researching more graphics-related Audicle/gluck ideas
- Folks at Stacken have been working on auto-conf (now waiting for us to
hand over new release)
- Gary Williams is working on tutorials in the beginning chuck blog
- Chris Turner is working on matching client/server messages for better
on-the-fly programming feedback
- Perry, Ananya, and I are writing paper and code for v2
- (any other development effort I missed?)
release dates:
---
v1.2 release: late March
doc overhaul release: April
audicle release: summer
gluck release: summer
In conclusion, we apologize for the delay and thank you for your
(incredible) patience.
Best,
The ChucK team
PS: This remind me of a previous post from almost a year ago, I have
included it below:
---------------------------------------------------------------------
On Sat, 10 Apr 2004, Ge Wang wrote:
---------------------------------------------------------------------
> Dear All,
>
> As you may (or may not) be wondering: it is now April, where is ChucK?
>
> We have pushed back the release (again), this time to May. However,
> this _will_ be the final delay. We will attend NIME
> (http://www.nime.org/) in early June to present the follow-up ChucK
> paper (see below) and to perform our piece: "On-the-fly Counterpoint"
> using ChucK (an "amusing" initial performance took place in November
> 2003 in Princeton). The initial release of ChucK will definitely
> happen before that, in late May 2004. Our efforts from now until then
> are completely devoted to the implementation/release.
>
> Additional status report:
>
> ----
> NIME 2004 (in Hamamatsu, Japan) - we will present:
>
> "On-the-fly Programming: Using Code as an Expressive Musical Instrument"
> It can be found on the on-the-fly programming site:
> http://on-the-fly.cs.princeton.edu/
>
> You can see a short video from the initial performance from here as
> well. Also, if you are further (still) interested in on-the-fly
> programming, Alex mentioned that a group of us are gluing together some
> kind of informal group
> (http://www.toplap.org/).
>
> ----
> In an (perhaps rather insane) attempt to pipeline tasks, we have been
> prototyping a "context-sensitive, on-the-fly programming environment"
> for use with ChucK. Its purpose to complement and visualize the
> language, enhancing the ability to do on-the-fly programming. The name
> of this environment: The Audicle. We recently submitted its paper to
> ICMC.
>
> With this done, the pipeline is now full, and there will be no more
> stalling! We have been coding/documentating/testing ChucK around the
> clock. Recent additions: flexible virtual machine options, tons of
> bugs fixes (tons of new bugs), improved audio engine interface and
> performance (thanks to Gary Scavone), much improved error reporting.
> Next: dynamic linking and class semantics.
>
> ----
> In conclusion, we apologize for the delay and thank you for your
> (incredible) patience.
>
> As always, please post/email comments and concerns!
>
> Thank you very much!
>
> Best,
> Ge!
>
> _______________________________________________
> chuck mailing list
> chuck(a)lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck
On Wed, 16 Feb 2005, Adam R. Tindale wrote:
> Hi All,
>
> When you do division on two durs a float is returned. When you divide a dur
> by a float you get a dur as well.
>
> There are some examples on the reserved words page on the docs site.
>
> Here is how you can divide two durs to make a new dur.
>
> 10::second => dur a;
> 5::second => dur b;
> a/b => float g;
> g::second => dur newdur;
>
> Doing
>
> a/b::second => dur q;
>
> gives a parse error however.
>
Have you tried (a/b)::second => dur q; ? I've noticed that the parser is
VERY nitpicking on arithmetic before the ::....
> This works nicely though.
>
> 10::second => dur a;
> a/2. => dur b;
>
> Hope that helps.
>
> art
>
> On Feb 16, 2005, at 3:11 PM, Philip Davidson wrote:
>
>> Micheal,
>>
>> math on durs is supported, but not completely
>> ( some revision to dur handing is needed )
>>
>> dur * float => dur ; should work.
>> not sure about float * dur => dur;
>> I don't believe that division is properly supported.
>>
>> this code would work
>> --
>> 1::second => dur beat;
>> beat * 0.5 => dur h;
>> -or-
>> beat * 0.5 => now;
>> --
>>
>>
>> where it stands for now...
>>
>> Phil
>>
>>
>>
>> On Feb 16, 2005, at 5:43 PM, Michael Heuer wrote:
>>
>>> Hello ChucKers,
>>>
>>> Is there any way to go from an int or float value of a variable to a
>>> duration? e.g.
>>>
>>> 1 => int value;
>>> value::second => dur some_unknown_number_of_seconds;
>>>
>>> What I'm really trying to do is math with durations and numbers,
>>>
>>> 1::second => dur w;
>>> (w / 2) => dur h;
>>>
>>> Thank you,
>>>
>>> michael
>>>
>>> _______________________________________________
>>> chuck mailing list
>>> chuck(a)lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck
>>
>> _______________________________________________
>> chuck mailing list
>> chuck(a)lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck
>>
>
>
> _______________________________________________
> chuck mailing list
> chuck(a)lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck
>
--
Mikael Johansson | To see the world in a grain of sand
mikael(a)johanssons.org | And heaven in a wild flower
http://www.mikael.johanssons.org | To hold infinity in the palm of your hand
| And eternity for an hour
Dear All,
There is a new incremental version out (1.1.5.5) which:
1) fixes a bug under XP where chuck --loop uses 100% cpu
(now it uses 0-5%)
2) improves stability under Mac OS X
It is available now:
http://chuck.cs.princeton.edu/release/
Best,
Ge!
>
> From: oliver oli <smoerk(a)gmail.com>
> Date: February 6, 2005 3:04:00 PM PST
> To: "Mailing list for programming language 'ChucK'"
> <chuck(a)lists.cs.princeton.edu>
> Subject: Re: [chuck] Audicle presentation award / video
> Reply-To: Mailing list for programming language 'ChucK'
> <chuck(a)lists.cs.princeton.edu>
>
>
> I don't know much about Audicle, I only watched the video. It's mainly
> a visualization of what is going on inside of ChucK. How many shreds
> are running and when they get activated, etc... There is also an
> editor which some nifty user interface, which I guess is based on
> OpenGL, too.
From the performance standpoint, I can say that the Audicle is much
more than a fancy editor / visualization. We have to keep in mind that
this language aims to facilitate on-the-fly programming. The Audicle
interface substantially changes how a performer might interact with
Chuck in realtime, because it fundamentally changes the characteristics
of the performance interface.
>
> But this stuff is completely optional, you can also do everything with
> plain chuck and an editor of your choice.
Except that you can do it more quickly and in different ways using
Audicle. Plus our plain editors are way less interesting to audience
members than are fancy visualizations.
> I don't think it makes any sense to try to make Audicle more screen
> reader friendly, because it's mainly 2D and 3D visualization. I guess
> it's possible to magnify everything in Audicle as it's based on
> OpenGL.
>
> But maybe it's possible to make the command line interface of chuck
> more accessible? Have you tried to run chuck? Is there anything which
> could be improved for a screen reader...?
As a composer/performer, I personally prefer virtual instrument GUIs of
some kind (even if they're dynamically defined) over command line
interfaces for performance. We need to get away from the suspicion
that your new music laptop performer is in fact checking his e-mailing
during the performance you're watching, and projecting
visualizations--especially visualizations like this that are integrated
with the code editor and are apparently effecting the way in which the
performer makes musical decisions--has a lot of potential as a cure.
--Jeff Treviño, Stanford University Computer Center for Research in
Music and Acoustics (CCRMA)
>
>
>
> Rich Caloggero wrote:
>> Somewhat dumb question here -- what exactly is
>> Audicle ? I assume its some kind of GUI, with Chuck on the back end
>> doing
>> the heavy lifting. My question is really - is it a win32 app or will
>> it only
>> run on X-windows. I'm a blind musician and have always wanted an
>> accessible
>> synthesizer, something I can actually tweak fairly easily. Most (all)
>> stand-alone boxes have incredibly difficult interfaces which can only
>> be
>> operated by sighted people. Software solutions are worse - completely
>> inaccessible GUI. Might there be any hope for audicle in this sense?
>> I'm
>> certainly no expert in win32 programming or GUI building in general,
>> but if
>> Cakewalk/Sonar can be made reasonably accessible, then why not
>> audicle?
>> For good models of how to create accessible interfaces, ones which can
>> expose their state to adaptive tech. like screen readers and
>> magnification
>> software, look at the gnome project, and Java Swing, both of which are
>> attempting to do this.
>> -- Rich Caloggero, MIT Adaptive Tech. for Info. and Computing
>
>
>
> _______________________________________________
> chuck mailing list
> chuck(a)lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck
Dear All,
We are happy to announce that the Audicle has won the
2004 ICMA Best Presentation Award, as voted by attendees
of the 2004 International Computer Music Conference (ICMC),
in Miami.
The video of the presentation is now available for bandwidth and
storage abuse (they are pretty big) - if you want to take a glimpse
at the audicle:
http://soundlab.cs.princeton.edu/listen/
big: audicle_icmc2004_sm.mov (130 megs)
bigger: audicle_icmc2004.mov (500 megs!!!)
Thanks to Ajay Kapur + Adam Tindale for filming the thing, and
for everyone's support!
Best,
Perry, Phil, Ananya, Ge
I've been fiddling with the ModalBar and TubeBell STK functions, and I wrote
a subroutine that took a TubeBell. as a parameter:
fun int presets( TubeBell bell ) { ... }
but accidentally called it with a param that was a ModalBar. This did not
gen a type error and I got silence until I added a param that doesn't exist
in a TubeBell. Then ChucK complained that it couldn't find TubeBell
strikePosition.
Howcum? (i.e., why no typing complaint? It took me an hour to find out why I
was getting silence...)
-- Gary
----
Chess: http://chessnut.net/
Homepage: http://garywilliams.org/
Blog: http://tfs_reluctant.blogspot.com/
ChucK Blog: http://b-chuck.blogspot.com/
Resume: http://garywilliams.org/resume.htm
Store: http://www.cafeshops.com/tfsreluctant/
Phone: (607) 775-0408
Permanent email: gwms(a)corninglink.com
As I noted on the features request page on the wiki, I think we need an
exit() function.
I noticed in my scalefunction.ck example on b-chuck, it would have been good
to issue an error message and exit in the bad-parameter value case -- but I
don't see exit() in the programmers guide.
Also, and include verb to allow inclusion of function modules and header
files would be helpful. (Similar to the #include in C...)
--Gary
----
Chess: http://chessnut.net/
Homepage: http://garywilliams.org/
Blog: http://tfs_reluctant.blogspot.com/
ChucK Blog: http://b-chuck.blogspot.com/
Resume: http://garywilliams.org/resume.htm
Store: http://www.cafeshops.com/tfsreluctant/
Phone: (607) 775-0408
Permanent email: gwms(a)corninglink.com
