Adam;

Great to see you here.

Yes, isn't it? I was enjoying Tomasz's posts elsewhere for a few years now before running into him at Steim. It's a small world.
 
Firstly, I would like to announce to you all that I successfully
defended my PhD this week and now that is done I will be spending more
time here collecting the great ideas that come through this list.


Both are great news! congratulations! What is your PhD on?
 
Presently I am working on converting the manual to asciidoc, which is
a simple formatting language that produces both html and pdf copies.
This will allow us to keep the manual and the website in sync. This
has been a sore point for a long time now.


Right, this is a good point. The threshold of entry should be lower there so everyone who would like to help can. I think most of the more senior users have their own field of expertise that many others will know less about and of course new users will see issues that the rest overlooks. To me the manual is a important thing as it will be the first port of call for many people who are considering ChucK; that's also why I felt the recent compilation issues needed a quick fix. If we don't make a good first impression we'll never reach world-domination.
 
I have signed up for a github account and I would be happy to put the
chuck manual there. This will allow everyone to grab from my branch
and then I can pull changes from everyone and then commit them back to
the project. How does that sound?

Good. But then we need a intro to this. A intro to using this system aimed at people who are not routinely using version management. Like me :-).
 

Future. I want to have a documentation sprint. How does December 19th
look? Anyone else interested? I would be online all day giving out
tasks and helping people get into the technical parts of adding to our
document and also looking for snippets of wisdom or errata to improve
the minutia.

This sounds like a good idea, and very fitting with the inspiration Tomasz here took from the recent Ardour sprint in Rotterdam and online.

Let me commit to covering the interaction between DSP in code and in UGens; that's a interesting topic that I feel has so far been under-appreciated even though it's one of the things where ChucK can really shine as compared to other systems.

I think that too much fragmentation of the project is not good. Ge has
done a great job and keeping everything together and I think that is
one of the reasons we have so many people here. It is easy to find
information (or to find out that the information doesn't exist) and it
is easy to ask questions to a list that actually responds. Having a
dev or working version of the docs is good but having it all in one
place for newbies definitely eases the transition, so I don't want to
break that "feature."


I respectfully disagree there. I do agree that Ge is doing a amazing job that can't be praised highly enough but the information is not all in one place. Most is in the manual but then some things are only in the examples or even just mentioned in Ge's thesis (whole chunks of that should likely be pasted straight into the manual). Then there are things that are only mentioned in the list archives or on the forum or WiKi, hinted at in the old docs on the site or even just in the VERSIONS file. I think there are also bits that aren't documented at all; there must be as every once in a while something pops up that has been implemented but never documented.

Of course this has so far not been a great issue as the scene is still small enough for the people who know how to find it all to answer all questions and this can certainly be attributed to Ge who set the tone of friendly help to all comers (quite unlike some lists I hear about).

To pick just one thing; just the other day I was talking about the "repeat" structure in ChucK on the Toplap list when debating the influence of syntax on musical movements (as well as kissing as a quantitative measurement of musical quality; it's a wonderful list). Even I myself can't remember where I found that one (might be Ge's thesis?). The manual mentions it's existence, but not how it works;

repeat(3)
  {
  <<<"this will be printed three times">>>;
  }
 
...a wonderful device, it can be used immediately even if you have just seen it once so it's a great introduction to loops, it's simplicity makes it great for casual impulsive livecoding with a drink at hand, but don't ask me where it's documented.

These are my current thoughts. What do you think?


Yes, yes, yes &yes. Great ideas, it's good to see you back on the case and we'll do this. I'm in and I hope we'll see a strong turnout of people writing, suggesting and proof-reading.

After this I'd like a sprint on the /examples/ dir. There are some bits in there that I find questionable. We can debate style (some structures have become out-dated) but I feel they should all run without errors or warnings (this is not currently the case) and there are some otherwise dubious bits here and there. I think I kept some notes on those somewhere but might have misplaced them.

Great initiative!
Kas.