| Author |
Message |
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
 Posted: Sun May 11, 2008 5:10 am Post subject:
ChucK dissertation!!! draft 5.11.2008
Subject description: The horror! Let's rip it apart! |
  |
|
Dear fellow ChucKists,
I hope this finds you well! The ChucK dissertation is finally nearing the finish line, with the final defense scheduled for Friday May 16th. I am traveling back to Princeton to present it.
In the meantime, this is one of the latest, and nearly final draft of the thesis, all chapters except conclusion are done.
I haven't made any drafts public until now and here. As always, I would greatly appreciate any feedback/comments/complaints/diatribes/suggestions/proofreading on all or any part of the thing (especially in the next day or two before this thing goes to be bound)!
So here you go! Thanks and sorry in advance!!!
http://ccrma.stanford.edu/~ge/stuff/public/draft-5.11/
Feel free to post comments here, and/or email them to me. Thanks you!!!
Yours,
Ge! |
|
|
Back to top
|
|
 |
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Sun May 11, 2008 8:54 am Post subject:
|
|
|
Wow Ge, 182 pages, you wrote a book! I didn't know ChucK went to college, I thought his knowledge grew from a magic bean into the sky! I'll definitely give this one a read. You know, ChucK is a tool and I've always been very satisfied with producing tools of any sort, be they software or hardware, because they will be used to produce so much more than the tool itself. Your work has opened my eyes (and ears) to the world of music creation, and for that I thank you. Well done!
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon May 12, 2008 5:08 am Post subject:
|
|
|
I've been firing-off rather a lot of comments on this privately by email but thought I should also (and publicly) add how happy I am that we now have this centralised tome of ChucKist philosophy. This work consolidates a lot of the facts and reasons that were previously scattered all about or even merely implicit in syntax.
Oh, and Ge uploaded a updated version, it's in the same dir.
_________________
Kassen |
|
|
Back to top
|
|
|
kijjaz
Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4
|
| Posted: Mon May 12, 2008 6:40 pm Post subject:
|
|
|
Ge! Thanks for your great contribution. I'm going to start reading very soon.
And i'll update with you as soon as possible. |
|
|
Back to top
|
|
|
Frostburn
Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9
|
| Posted: Wed May 14, 2008 8:23 am Post subject:
|
|
|
Well done and comprehensible. Good work Ge!
I'm only half way though but I noticed a bug in your code on page 77 (page 94 in the pdf reader)
| Code: | // patch
adc => Gain g => OnePole p => blackhole;
// square the input
adc => g;
// multiply
3 => g.op;
//...rest of the code... |
Re-chucking has no effect as far as I've tested.
Shouldn't it be:
| Code: |
adc => Gain g;
adc => Gain g2 => g;
3 => g.op; //Now g has square input
|
?
Have you changed how it used to work?
_________________
To boldly go where no man has bothered to go before. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Wed May 14, 2008 8:39 am Post subject:
|
|
|
| Frostburn wrote: |
Have you changed how it used to work? |
Actually, I think that back when Perry wrote that example it used to work like that.
It's like this in the "examples/deep" dir as well, that's (now) wrong too and should be changed.
I can see advantages to the newer implementation. For example if a gain is set to subtract and you would double-ChucK to it unchucking will become ambiguous since in that case the two connections aren't equivalent. We could -of course- have something like a "last in, first out" rule for that but like it is now it's cleaner, though indeed at the price of the occasional "dummy" Gain.
_________________
Kassen |
|
|
Back to top
|
|
|
Frostburn
Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9
|
| Posted: Wed May 14, 2008 12:54 pm Post subject:
|
|
|
| Ge Wang wrote: | ...while technology is central to what
we do, it is what we do with technology that truly matters.
-Thank you for reading. |
And thank you for writing it. 
I truly enjoyed the walk through the history, ChucK and experience.
I've enjoyed the world of audio synthesis using ChucK and made a few MIDI controlled instruments that are fun to play. So thank you (and all who contributed) for this wonderful programming environment.
Some feedback though...
Removing the duality of oschestra vs. score makes ChucK well suited for audio synthesis, live-coding and general HID madness but at the same time it makes it harder to write "offline" musical pieces that stand on their own.
As it stands ChucK makes sharing code easy but doesn't do so well with sharing music (in the classical sense). The lack of standard scoring and notation system makes it harder to reason about rhythm and melody in ChucK.
It is clear the ChucK is geared towards "live and online" but your dissertation doesn't address the "offline" aspect of composing stand-alone pieces with ChucK.
Is there going to be a ChucK native system for using and communicating musical information or is everyone free (or forced) to make their own tempo and scoring systems and graphical trackers/whatnots for composing?
_________________
To boldly go where no man has bothered to go before. |
|
|
Back to top
|
|
|
ge
Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA
|
| Posted: Thu May 15, 2008 2:56 am Post subject:
|
|
|
Thank you all very much for the continued encouragement and support! The most recent disaster is now posted:
http://ccrma.stanford.edu/~ge/stuff/public/drafts/
I am leaving for Princeton today, and will continue hacking on the document. Thank you for your comments so far! Also, crazy thanks to Kassen for having read through the entire ChucKian dissertation catastrophe and providing extremely helpful comments and edits!
As we say, we'll keep on ChucKin'.
By the way, the double UGen chucking is coming back, after being removed for the last few releases. It's just so useful!
Best,
Ge! |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu May 15, 2008 3:50 am Post subject:
|
|
|
| Frostburn wrote: |
Some feedback though...
Removing the duality of oschestra vs. score makes ChucK well suited for audio synthesis, live-coding and general HID madness but at the same time it makes it harder to write "offline" musical pieces that stand on their own.
As it stands ChucK makes sharing code easy but doesn't do so well with sharing music (in the classical sense). The lack of standard scoring and notation system makes it harder to reason about rhythm and melody in ChucK.
It is clear the ChucK is geared towards "live and online" but your dissertation doesn't address the "offline" aspect of composing stand-alone pieces with ChucK.
Is there going to be a ChucK native system for using and communicating musical information or is everyone free (or forced) to make their own tempo and scoring systems and graphical trackers/whatnots for composing? |
To voice my opinion; I think MIDI and to a lesser degree Csound reflect on a implied level reflect what their creators believe "a note" (and other musical structures) are. I don't think that in acoustical music this is even that clear and that such assumptions can be dangerous or limiting in electronic music. ChucK leaves this more open; you are free to develop your own "instrument" and "note" classes and take it from there according to your own ideas.... but indeed setting up such a framework can be time consuming. Personally I feel that if we'd have things like public Events (for cross-file notes) and the ability to properly extend Ugen (for instruments) we'd be quite far already, likely this would have to be combined with garbage collection for larger scores.
It's a good point though, I could imagine keeping this kind of structure in mind when the whole "static data in public classes" evolves because at the very least that is the kind of thing we should be able to do relatively easily. Since we could do most of this ourselves already even a "include" function might solve most of the effort?
| Ge wrote: | | Also, crazy thanks to Kassen for having read through the entire ChucKian dissertation catastrophe and providing extremely helpful comments and edits! |
Really no problem at all, I think I got at least as much out of it as you did. Without note-keeping I would never have read with that much attention and never noticed so many of the finer details. I think it's great how this document -where all of these thoughts on ChucK are centred- is leading to more debate about the future of ChucK and anticipate this will only continue in the following weeks after a "official" release.
| Quote: | | By the way, the double UGen chucking is coming back, after being removed for the last few releases. It's just so useful! |
Ok, but do consider my note about the possible ambiguity above.
_________________
Kassen |
|
|
Back to top
|
|
|
Frostburn
Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9
|
| Posted: Fri May 16, 2008 2:21 am Post subject:
|
|
|
| ge wrote: | | By the way, the double UGen chucking is coming back, after being removed for the last few releases. It's just so useful! |
Oh please don't bring it back...
The personal reason: I'm using chucking as a way to make sure that the thing is connected... double chucking would mess my code up.
A more general reason: The only place I can think double chucking UGens is useful is squaring the input. The rest of the .op modes wouldn't have any reasonable benefit.
Please consider making a WaveShaper UGen that could be used, among other things, to square the input. It should have at least all the elementary functions and have a default behaviour like an oscillator with sync mode 1 (phase modulation). [ Remember to make sure it accepts input on the whole range, not just 0.0 to 1.0... and do this for the GenX family too (at least the Chebyshev one) ]
Example:
| Code: |
adc => WaveShaper ws => dac;
second => now; //listen to the unmodified signal
"srq" => ws.mode; //square the input
second => now; //listen to the squared signal;
"tanh" => ws.mode; //Change from sqr to hyperbolic tangent distortion
second => now; //rock on!
"sqrt" => ws.mode; //square root time
second => now; //output zero if the input is negative
|
EDIT: added this as a feature request here.
_________________
To boldly go where no man has bothered to go before.
Last edited by Frostburn on Fri May 16, 2008 2:45 am; edited 1 time in total |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Fri May 16, 2008 2:37 am Post subject:
|
|
|
| Frostburn wrote: | | [ Remember to make sure it accepts input on the whole range, not just 0.0 to 1.0... and do this for the GenX family too (at least the Chebyshev one) ] |
I must agree with this feature request. I'm working on a tube amp model (in another thread on electro-music.com) and I have to play silly games with biasing and gain to make the signal fit into the 0.0 to 1.0 range. Worse yet, guess what happens when the output is too large? The signal wraps around to a negative value. That is, a signal of value 1.1*max (forget what max is) wraps around to -0.9*max. So a large sinusoid gets brutally chopped into smithereens instead of just clipping (yes, I like the word smithereens, hehe). Perhaps these two phenomena are worthy of some study by the esteemed ChucK dev team? Just a thought. Keep on ChucKin'!
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Fri May 16, 2008 3:24 am Post subject:
|
|
|
| Frostburn wrote: |
The personal reason: I'm using chucking as a way to make sure that the thing is connected... double chucking would mess my code up.
|
Hmmmmm, but you could still poll the Ugen to see what's connected to it, right?
| Quote: |
A more general reason: The only place I can think double chucking UGens is useful is squaring the input. The rest of the .op modes wouldn't have any reasonable benefit.
Please consider making a WaveShaper UGen that could be used, among other things, to square the input. It should have at least all the elementary functions and have a default behaviour like an oscillator with sync mode 1 (phase modulation). [ Remember to make sure it accepts input on the whole range, not just 0.0 to 1.0... and do this for the GenX family too (at least the Chebyshev one) ]
|
Yes, I agree, we need at least one Gen that takes bipolar inputs for wave-shaping. The wave-shaping situation is right now less then ideal.
I have, BTW, a nice design for overdrive here but the core of the design isn't mine and I'm not sure I can talk about it. It has some nice properties; it leaves the zero crossings in place and also leaves the points where the signal is 1 or -1 be and shapes continuously between those and it can get the amount of drive from a additional audio signal (say a envelope), it'll stay continuous if the "drive" modulation signal is, which I like. There are limitations though in that the input shouldn't exceed -1 to 1 and the drive range should be between 1 and 2 or it'll go out of it's -1 to +1 range.
Good overdrive isn't so easy...
_________________
Kassen |
|
|
Back to top
|
|
|
soundcyst
Joined: Feb 17, 2008
Posts: 18
Location: santa cruz, ca
|
| Posted: Sat May 17, 2008 11:46 am Post subject:
|
|
|
i haven't had a chance to read this yet, and i hope the defense went well, but regarding double chucking to square the input, wouldn't it be easier and less ambiguous to implement a double-chuck operator? ==> that requires double-unchucking? ==<
or would this screw up the code parser and make things abusively complex?
maybe '=> or some other character instead of a 2nd =? |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sat May 17, 2008 3:41 pm Post subject:
|
|
|
Sounds too specialised to me, especially with double-un-ChucKing.
I wonder if this is really useful at all beyond squaring signals and if not we're not better served with a "Pow" Ugen (bonus points for referencing old video-games, I think!) with a .power( float ) parameter defaulting to 2.
_________________
Kassen |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Sat May 17, 2008 6:18 pm Post subject:
|
|
|
Yes, in fact why not make all of the math functions available as a math Ugen? That would be really useful when implementing functions such as neural net backpropagation in Ugen form. Well, as if the dev team weren't busy enough as it is. What ever happened to that MAUI for Linux/PC release, BTW? I'd lub to get opinions on ChucK Lab from my fellow electro-music.com ChucKists!
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
kijjaz
Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4
|
| Posted: Sun May 18, 2008 11:04 am Post subject:
|
|
|
I've read some but not all of the document.
I really enjoy the introduction parts .. about computer and computer music programming etc.
I've got some new suggestions for the correction you might agree also:
page 48 chapter 3:
The polar type offers an equivalent, alternative representation of complex num-
bers in terms of a magnitude and phase value. The magnitude and phase values
can be accessed via .mag and .phase. (Figure 3.7)
* (2,.5*pi) => polar pol; // polar
pol.mag => float m; // m is 2
pol.phase => float p; // p is .5?
kijjaz: should be %(2,.5*pi)
- - -
page 51:
// use in combination
2::minute + 30::second => dur bar;
// same value as above
2.5::minute => dur bar;
if run within a same program, user might experience this and get confused?
'bar' has already been defined in the same scope...
- - -
page 59:
3.3.8 Programming with Events
ChucK events are a native class within the ChucK language. We can create an
Event object, and then chuck (=>) that event to now. At this point, the event
places the current shred on the event’s waiting list and suspends the current shred
(letting time advance from that shred’s point of view). When *the the* event is trig-
gered, one or more of the shreds on its waiting list is shreduled to run immediately.
This trigger may originate from another ChucK shred, or from activities taking
(hmm... we've got a double the)
- - -
I'll continue more. I'll look forward to this report.
it's one very cool music synthesis document! |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
