December 2009 - chuck-users - lists.cs.princeton.edu

granular music recommendations?
by AlgoMantra 23 Jul '24

23 Jul '24

Yo All....I'm trying to download and study some of the best music out there which features granular synthesis. I haven't heard much yet beyond Iannis Xenakis, but I'd love to know what your favorites are. Perhaps it would be worthwhile putting up a torrent of the same. If possible, kindly provide links to mp3 files or any other type of free downloads. (What do you think of Jaron Lanier's music?) http://www.jaronlanier.com/musicdownload.html cheers! ------- -.- 1/f ))) --. ------- ... http://www.algomantra.com

12 28

Scale & diatonic
by Hans Aberg 12 Oct '11

12 Oct '11

I have made a program, scale.ck, that admits one to work with scales, including tuning stretch, céleste tremulant, retune them, and then save to a file, with a line of code that can be pasted back into the source, available at next program startup. Scale tunings can be put into tuning banks, and otherwise defined by your favorite method. Details in the file. I have also updated my program for diatonic tuning systems, diatonic.ck. Just a few changes: adding some common tunings, fixing typos. The files are available here: http://www.math.su.se/~haberg/tuning_systems/ Hans

4 6

FLOSS (user editable) manual for ChucK
by Tomasz Kaye's brain 11 Jan '10

11 Jan '10

Hi all. I noticed that there doesn't seem to currently be a user editable version of the ChucK manual online (http://wiki.cs.princeton.edu/index.php/ChucK/Manual this page is the nearest thing i found). While learning things there have been a few cases where I thought small changes to the manual wording would make things clearer (for instance my recent question about how Envelope works). I wondered about moving a copy of the ChucK manual to FLOSS Manuals, where it can be edited by users. http://en.flossmanuals.net/flossmanuals. I used this site in a recent Ardour booksprint I took part in. It's not perfect (sometimes navigation is a little unintuitive), but works well. It uses version history (different versions can be compared too). A user is appointed as a maintainers of a particular manual. Chapters can be edited by anyone with a FLOSS account, but maintainers get to decide when new versions of chapters are 'published' (made visible in the canonical version of the FLOSS manual, the one that guest visitors to the FLOSS manuals site will see) http://en.flossmanuals.net/FLOSSManuals/Maintainers . A few preliminary questions about the idea: @Ge: would you be okay with the current manual being copied to another site, and edited? (i couldn't find license details on the current manual). What do people think of this idea in general? Would people use it? Would it greatly confuse matters to have one more url for ChucK documentation? (any other issues?)

9 58

Chuck-ing SinOsc inputs
by Robert Poor 31 Dec '09

31 Dec '09

What is the predicted effect of: SinOsc s1 => SinOsc s2 => dac; ? I was expecting some form of FM, but instead I'm met with stony silence (*). I understand that the .op parameter controls how the input to a UGen is interpreted, but I don't see any documentation on the effect of chucking to a SinOsc input. If the real answer "go read Ge's thesis", I can handle that, but I was hoping for more instant gratification. Thanks in advance... - Rob (*) Of course, I've also initialized gains and frequencies to reasonable values. The full code is: SinOsc s1 => SinOsc s2 => dac; 330.0 => s1.freq; 1.0 => s1.gain; 440.0 => s2.freq; 1.0 => s2.gain; 1::second => now;

2 2

LiSa duration issue
by Kassen 30 Dec '09

30 Dec '09

Fellow ChucKists, Dear Dan, Two minor issues with LiSa.duration(). When we set the recording buffer to any size over 100::second a error will be given. However, the error won't make it clear it's coming from LiSa. In larger .ck files that also involve -for example- fft and the like it becomes a minor chore to detect the source of that warning message. This does not match the behaviour of other UGens and is generally inconvenient so I'd like to suggest pre-pending "LiSa; " to it. Though extremely minor I feel this is a issue. The second point is more subjective and open for debate. I feel that 100::second for the max duration made sense back when LiSa could only .record() but these days we can fill her memory using valueAt() and using longer buffers becomes practical. On top of that loading files straight into LiSa has been hinted at. Are there reasons to not extend this max to 10::minute or something in that order of magnitude? Would there be real issues with setting it to 1::hour and leaving people to shoot their own RAM-foot if and when they really wanted to? We allocate and free this memory properly, right? It is already possible to casually have ChucK blow your RAM out the window if you really wanted to; float foo[1000][1000][1000][1000]; //don't actually run this Yours, Kas.

2 2

Issue/bug tracker system?
by Tomasz Kaye 30 Dec '09

30 Dec '09

Would an issue/bug tracker system be useful to ChucK people? Working on the manual sprint got me thinking about the way bugs are currently handled. From a users point of view i think that a web based tracking system has the following advantages: 1. It removes doubt that I might be filing a duplicate bug report (I don't want to needlessly make noise). 2. It would avoid having to pester people to find out what the status of a bug is. As a test I went ahead and registered one with lighthouse which seems like a nice system (free to use for open source projects) http://chuckissues.lighthouseapp.com/ My favourite bug is listed there already ;) Any thoughts, comments etc appreciated. Would devs use this? Thanks, Tomasz

7 13

Hid open by string [bug]
by Kassen 22 Dec '09

22 Dec '09

Fellow ChucKists, Dear Spencer. I was going over the VERSIONS file, looking for more things that are lacking in the manual and found the .open( string name ) member function for Hid and HidIn. As far as I can tell this works fine, provided we know the exact name of the device. The following example will instead crash; HidIn hi; hi.open( "foo" ); ...this is of course assuming you don't accidentally have a device named "foo". The following does work for me; HidIn hi; hi.open("SynPS/2 Synaptics TouchPad"); It seems like the existence of the device isn't properly verified before ChucK attempts to open it. Tested using the latest mini on Ubuntu 9.10 Yours, Kas.

4 9

vista and addressing soundcards (RTAudio?)
by Kassen 19 Dec '09

19 Dec '09

Fellow ChucKists, Are there any known issues addressing the Vista sound system? There was a post about this here; http://electro-music.com/forum/viewtopic.php?t=38812 and it strikes me that the results of --probe come up with rather unrealistic sample rates for the available outputs. Does this relate to any known issues? I do think that our version of RTAusdio predates Vista's changes to the Windows sound system but I find it a bit hard to imagine that they changed the hooks *that* badly. Any Vista experts who could shed some light on this? Kas.

1 0

--callback&--blocking (RTAudio?)
by Kassen 18 Dec '09

18 Dec '09

Fellow ChucKists, Dear Gary, I'm currently working on extending the manual section on the comandline flags for starting the VM and ran into --callback and --blocking. While mentioned in the online docs (which I'm basing my text on with some additional notes) these flags aren't explained in any depth beyond them being related to buffering. I suspect they relate to the interaction between RTAudio and the host-system/ soundcard but the way in which they do so isn't at all clear. Is there a place where more info could be found? Yours, Kas.

2 2

Documentation Sprint
by Adam Tindale 17 Dec '09

17 Dec '09

Hi All, We have finished our documentation sprint and I'd like to sum up a bit. Sorry for the thread going a bit nuts, it was necessary to get organized. Thanks for your patience. We have migrated the documentation to FLOSS manuals. You can see the results of the day here: http://en.flossmanuals.net/ChucK/Introduction We had a few very active people working very hard today. I'd like to thank Tomasz, Kas, Scott, and Michael. They did a great job. The good news is that we were able to port all of the docs over. We have a few things that need some touch ups but it is complete. We have added some new sections to the docs about user submitted libraries. We have fixed many small typos, errors, and errata. We have also initiated four more people into the documentation system so that I can get some ongoing help. The bad news is also plentiful. The current web style cannot be changed. We require deeper access to the css files in order to make our documentation clear. The PDF output provided by FLOSS manuals is insufficient. We have established a relationship with the founder and main dev of FLOSS manuals who is excited to help us. We have also created a number of new bugs in their system. Truly ChucKian. I plan to spend the next month in contact with the FLOSS manual dev list to figure out our issues. In January I will organize another sprint to integrate the solutions we develop across the whole manual. Basically, we are making a tradeoff: greater user contribution for lesser control of layout and formatting. I hope to work with the ChucK team to migrate our web documentation to FLOSS manuals as we centralized to that system. We made it a lot farther than I hoped today. We were able to develop new documentation and not just rehash the old stuff with a new skin. This is a major win for the community and I invite you to sign up for an account and help us to continue building the documentation. --art

3 3