Re: [chuck-users] priorities for next release
Yes, we would all like this, I think. At least we have a WiKi page where everybody can post additions, remarks and requests which should at least decrease the strain on maintaining the manual. I believe Adam Tindale was the last to be semi-officially in charge of the manual but other things took his time. I'd volunteer but I'd need a proofreader as I'm not a native English speaker and I still don't speak any Latex at all (the manual is done in Latex)
At least most things can be found by searching the list archives and the manual isn't *that* out of date. Aside from the latest greatest stuff this matter might be one of the worst missing bits.
Hi All, I have been silent for a long while. I am always happy to proofread and hack stuff into the manual and make the commits (as long as Ge doesn't kick me off CVS). Like Ge, I just got a teaching gig and I am a bit swamped being new at all this. I have pleaded in the past for other people to submit tutorials or find mistakes in the manual and pass them on to me and the whole ChucK team. It now seems that there are so many experts that this dream is coming true. Most of what I did for the manual was to edit the original APIs into some semi readable form. A lot of that work was done by Ge and Phil and I just merely put it into LaTeX. There have been many people talking on the list about knowing how something works and not seeing it in the manual. If you do know and it isn't there, just write something up and tell me where you would like it be. The hardest part for me is starting something. If you get it started then the rest isn't so bad. I haven't worked on the manual in a long time and I am seeing that it is badly out of date. I will do my best to devote some time to it in the coming months (I am hoping to teach ChucK, so a good manual helps me too). If you have something you would like added to the official docs please send it along to me directly or via the list and I will be happy to add it. --art _________________________________________________________________ Former Police Officer Paul Gillespies TAKE BACK THE INTERNET tips and tricks, watch the video now http://safety.sympatico.msn.ca/
On 8/29/07, Adam Tindale
Hi All,
Hi, Adam, good to hear from you again! I have been silent for a long while. I am always happy to proofread and
hack stuff into the manual and make the commits (as long as Ge doesn't kick me off CVS). Like Ge, I just got a teaching gig and I am a bit swamped being new at all this.
Congratulations. I have pleaded in the past for other people to submit tutorials or find
mistakes in the manual and pass them on to me and the whole ChucK team. It now seems that there are so many experts that this dream is coming true. Most of what I did for the manual was to edit the original APIs into some semi readable form. A lot of that work was done by Ge and Phil and I just merely put it into LaTeX.
You still did a very good job and having a manual at all was a big improvement. before the manual I had to manually save all usefull web-pages because I also wanted to ChucK when away from the web. There have been many people talking on the list about knowing how
something works and not seeing it in the manual. If you do know and it isn't there, just write something up and tell me where you would like it be. The hardest part for me is starting something. If you get it started then the rest isn't so bad.
I haven't worked on the manual in a long time and I am seeing that it is badly out of date. I will do my best to devote some time to it in the coming months (I am hoping to teach ChucK, so a good manual helps me too).
If you have something you would like added to the official docs please send it along to me directly or via the list and I will be happy to add it.
I believe the last larger update was by Spencer. Generally I think centralising the notes about the manual would be a good idea. This would create a spot that would be the first to look if something seems missing, we could colaborate on documenting exactly what is missing or wrong and it would make it easier for different people to work on it. Basically I think the WiKi is perfect for this. However, I have some problems with how the WiKi works. I've been adding notes on the manual and bugs that I found or that new users on the forum ran into there and many of those got solved but once they do they stay on the WiKi. It's my opinion that things would get much clearer, clearer and more usable if we'd delete solved issues from there or at least move them to a "solved issues" section. Right now it's usable to the in-crowd of ChucK users but probably hard to decypher for new users and I shudder to think what the "bugs" page looks like to somebody considdering to jump in, there's a frightfull amount of terrible bugs there, nearly all of which have been long solved. If we keep the current policies up I imagine it will be completely unusable to anyone in a year or two. I've pointed this out before and also pointed out that I would be happy to clean this a little but I'm not going to delete/move that much stuff without a official go-ahead, I'm still a guest there, I feel, and guests shouldn't start throwing out the trash without some discussion. Anyway, I would be happy to have a look at what areas are seen as the most urgent by new users (MIDI always leads to questions, in my experience) and try to do a section on some of those. Another, much lager, matter is that it seems that some people expect that it's a good idea to start ChucKing by reading the manual front to cover. Now we have a lot of experts on teaching here that know a lot more then I do but to me that doesn't sound like a particularly practical idea or that ChucKian. perhaps most usfull would be a good "how to read this manual/ what would be a good place to start/ introduction" section, preferably on the topic of creating a little techno while having fun and not on how to create a sinewawave after a week of deep meditation on cpu architecture Kas.
Another, much lager, matter is that it seems that some people expect that it's a good idea to start ChucKing by reading the manual front to cover. Now
Here's a pie-in-the-sky idea... (mm... pie....) Probably the single thing I actually _like_ about MS VC++ is the context-sensitive help (hit F1 on a function name to get a definition) and the auto-completion. I know not everyone likes it, but for a language intended for live use, being able to get all possible matching function names and then quickly jump to a short description I think would be very useful. At the moment I usually leave the Chuck website up in another desktop workspace while I'm chucking, and flip to it and do a manual search, but I think context-sensitive help would be way, way faster. (Speed in accessing useful information is key here..) Something like that in miniAudicle would be fantastic. (Then again, I usually use Emacs, but if I had a reason to switch I might consider it...) Steve
Stephen Sinclair wrote:
Something like that in miniAudicle would be fantastic.
agree++ -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions
Something like that in miniAudicle would be fantastic. (Then again, I usually use Emacs, but if I had a reason to switch I might consider it...)
Just to clarify.. the reason I mention this in the thread about Chuck rather than starting a new one about miniAudicle is that I think it would be interesting for Chuck to have built-in command-line-accessible functions for accessing documentation. Something like "pydoc" for python perhaps. Steve
Hi Dan and all, I've been playing around with the GenX functions and so far I find them really useful. Being able to create different curves was something I missed from the beginning. So many thanks for that. However I've found that the coefs member is a bit troublesome in that I would prefer it returned a reference to the array of coefficients instead of being a write only function which only accepts arrays. If it would return a reference to the array I imagine I wouldn't get confuse every time I assign the coefficients. So instead of [1.,2.,3.] => gen.coefs I think it would be more consistent with Chuck's language if one had to assign them like: [1.,2.,3.] @=> gen.coefs() But this is not what I find more lacking. I would like to be able to access any member of the array at any time, in order to, for instance, dynamically change the phase or strength of a particular harmonic. And also being able to have access to the .cap() function. So I'd like to do things like: GenX gen; [1., 2., 3., 4. ] @=> gen.coefs; for( 0 => int i; i < gen.coefs().cap(); i++ ) { //do something } instead of having to create first a temporal array, assign it to coefs and use the cap() from the first array in the for-loop. So, at the current state, the code above would translate to GenX gen; [1., 2., 3., 4. ] @=> float a[]; a => gen.coefs for( 0 => int i; i < a.cap(); i++ ) { // do something } and also, I'd like to be able to do: .5 => gen.coefs()[1]; Is all this now possible? and, if not, do you think it is worth having it in future releases? thanks, eduard
hi Eduard, it would be really cool to be able to update individually coeffs dynamically, but it's actually impossible with the classic unit generators; changing one coefficient requires recalculating the entire table, so even if the arrays were addressed as you suggest, updating a single element of the array would trigger a complete table recalculation (and likely a click of some sort, given the brief discontinuity). that said, i'll talk over the array assignment approach with Ge and see what he thinks. i'm glad you find these useful and thanks for the ideas! dan On Aug 31, 2007, at 5:29 PM, eduard aylon wrote:
Hi Dan and all,
I've been playing around with the GenX functions and so far I find them really useful. Being able to create different curves was something I missed from the beginning. So many thanks for that. However I've found that the coefs member is a bit troublesome in that I would prefer it returned a reference to the array of coefficients instead of being a write only function which only accepts arrays. If it would return a reference to the array I imagine I wouldn't get confuse every time I assign the coefficients. So instead of
[1.,2.,3.] => gen.coefs
I think it would be more consistent with Chuck's language if one had to assign them like:
[1.,2.,3.] @=> gen.coefs()
But this is not what I find more lacking. I would like to be able to access any member of the array at any time, in order to, for instance, dynamically change the phase or strength of a particular harmonic. And also being able to have access to the .cap() function. So I'd like to do things like:
GenX gen; [1., 2., 3., 4. ] @=> gen.coefs; for( 0 => int i; i < gen.coefs().cap(); i++ ) { //do something }
instead of having to create first a temporal array, assign it to coefs and use the cap() from the first array in the for-loop. So, at the current state, the code above would translate to
GenX gen; [1., 2., 3., 4. ] @=> float a[]; a => gen.coefs for( 0 => int i; i < a.cap(); i++ ) { // do something }
and also, I'd like to be able to do:
.5 => gen.coefs()[1];
Is all this now possible? and, if not, do you think it is worth having it in future releases?
thanks,
eduard _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi Dan and all, I've been playing around with the GenX functions and so far I find them really useful. Being able to create different curves was something I missed from the beginning. So many thanks for that. However I've found that the coefs member is a bit troublesome in that I would prefer it returned a reference to the array of coefficients instead of being a write only function which only accepts arrays. If it would return a reference to the array I imagine I wouldn't get confuse every time I assign the coefficients. So instead of [1.,2.,3.] => gen.coefs I think it would be more consistent with Chuck's language if one had to assign them like: [1.,2.,3.] @=> gen.coefs() But this is not what I find more lacking. I would like to be able to access any member of the array at any time, in order to, for instance, dynamically change the phase or strength of a particular harmonic. And also being able to have access to the .cap() function. So I'd like to do things like: GenX gen; [1., 2., 3., 4. ] @=> gen.coefs; for( 0 => int i; i < gen.coefs().cap(); i++ ) { //do something } instead of having to create first a temporal array, assign it to coefs and use the cap() from the first array in the for-loop. So, at the current state, the code above would translate to GenX gen; [1., 2., 3., 4. ] @=> float a[]; a => gen.coefs for( 0 => int i; i < a.cap(); i++ ) { // do something } and also, I'd like to be able to do: .5 => gen.coefs()[1]; Is all this now possible? and, if not, do you think it is worth having it in future releases? thanks, eduard
participants (6)
-
Adam Tindale -
Atte André Jensen -
dan trueman -
eduard aylon -
Kassen -
Stephen Sinclair