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

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

Scale
by Hans Aberg 16 Dec '09

16 Dec '09

I've updated scale.ck - it now contains close to 50 measured gamelan pelog and slendro tunings, plus a few others, available here: http://www.math.su.se/~haberg/tuning_systems/ Hans

1 0

Integer divisions
by Hans Aberg 15 Dec '09

15 Dec '09

I find the integer divisions C rule is problematic when working with intervals. Suppose I have [8/7, 7/6, 7/6, 8/7] and implement it as [Interval.r(8/7), Interval.r(7/6), Interval.r(7/6), Interval.r(8/7)] Then this is the same as: [Interval.r(0), Interval.r(0), Interval.r(0), Interval.r(0)] One has to add ".0" one of the numerator/denominator: [Interval.r(8.0/7), Interval.r(7.0/6), Interval.r(7.0/6), Interval.r(8.0/7)], One possible rule might be converting 32-bit int to 64-bit floats, and then only back to int when needed. The question if it then affects some ChucK legacy code. Hans

6 14

banshee
by David Loberg Code 15 Dec '09

15 Dec '09

Any suggestions on how to create a scraped string effect in ChucK? (like in Henry Cowell's Banshee) http://upload.wikimedia.org/wikipedia/en/f/f0/Cowell-The_Banshee.ogg thanks david David Loberg Code School of Music Western Michigan University Kalamazoo, MI 49008 code(a)wmich.edu

2 1

mini shortcuts mistery
by Kassen 14 Dec '09

14 Dec '09

Fellow ChucKists, dear Spencer. For me the mini on Linux, using the Gnome desktop, has lately been acting up. Shortcuts like ctrl-c, ctrl-v, ctrl-x stop working after a while, so do the ones for adding and replacing shreds. Strangely ctrl-d *does* work in this state. No other programs have shown this behaviour and it's not consistent; they disappear after a while and so far I haven't seen them return. I think only the latest version does this. I'd like to document under what conditions this happens but it's quite inconsistent. Yours, Kas.

1 0