Hi Ge, I was running the stk/clarinet.ck example. No soundfiles involved at all. It was usually only in creating and destroying shreds that there was a problem. Actually, now that I think about it, glitching also occurred when I would change focus to another program and carry out some action, i.e. scrolling through the chuck manual in Adobe Reader. This is on an Intel with Pentium M, running Windows XP Pro with SP2. The PIII was running the same version of chuck, 1.2.0.5; the only difference I can think of, offhand, is that it was running an older version of Windows XP Pro, with either SP1, or no service packs at all. So possibly it's an issue with something in SP1 or SP2. Unfortunately, I am planning to use chuck with a MIDI controller and joystick, so latency is an issue. I have a performance coming up on April 30th, with an electroacoustic ensemble, so I will be interacting with improvising instrumentalists in real time. I'd love to use chuck, if the performance is good enough. I do have a cheap M-Audio MobilePre USB soundbox, which I haven't yet tested with chuck. Possibly that will help with the glitching problem. However, if I need to boost chuck's priority, and it works, then I'm perfectly willing to do that. Is there any reason I SHOULDN'T do so? Btw Ge, I was at your presentation last Tuesday in Chicago (DorkBot meeting), which got me excited about chuck gave me the idea to try chuck for the upcoming performance. I'm really excited to see this software develop further! ~David On 4/20/06, Ge Wang wrote:

Hi David!

...

However, to get it to run well on my new Dell laptop running WinCrap XP, I had to go CTL-ALT-DEL, open up processes, and set the priority of chuck.exeto "realtime". Otherwise, when I create and delete shreds, I was getting unwanted glitching. Is there some way to automate this process, so that chuck always has realtime priority? A command line flag would be really helpful I guess.

On windows, there isn't a way to automatically boost the priority (and usually shouldn't have to). This glitching on windows seems to be a new feature of 1.2.0.5. One way to alleviate the problem is to specify a larger audio buffersize (which will increase your latency, but doesn't matter too much if you aren't using interactive input, like joystick, kb, etc.):

> chuck --bufsize2048

for example, sets the buffer size to 2048. Try different powers of two.

...

Also, is it normal for me to need to do this?

Hmm, one shouldn't have to do this... We hope to track the cause down for the next release. It may have something to do with loading sound files, the implementation for that did change a little. Do these shreds that glitch load sound files?

...

Strangely, despite maxing out the CPU, on an old PIII desktop with only 256 MB RAM (as opposed to 1 gig on the laptop) I had no problems like this and creating and deleting shreds occurred very smoothly. That was with a clean install of WinCrap, however.

That is strange, were both computers running the same version of chuck? If not, you might try running the PIII chuck on your new computer.

We hope to fix this soon.

Best, Ge! _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi Joerg!

btw: anyone using chuck for education? i am planning to use chuck in a class at university...

I think several institutions have started to use chuck as a teaching tool, both for audio synthesis and programming. We taught and are teaching the Princeton Laptop Orchestra with ChucK, and have been pleasantly surprised by the result. Last semester, we taught ChucK to 15 freshmen (none of whom had prior programming experience). They were hooked from the start (the assignments eventually included building a on-the-fly generative drum machine, a soundscape, duo and trio performances). The bulk of the success, I believe, was due to the sheer creative will and energy of the students (they all were fantastic), but it also proved to us that ChucK can be a viable and beneficial teaching tool. Here is a highly encouraging quote (reproduced here from the README to the drum machine assignment) from Anna, a student in last semester's course (and a world-class cellist): "... However, when everything worked the way it was supposed to, when my spontaneous arrangement of computer lingo transformed into a musical composition, it was a truly amazing experience. The ability to control duration and pitch with loops, integers, and frequency notation sent me on a serious power trip." It wasn't all smooth sailing, of course, a multitude of bugs/features were discovered, and a lot of on-the-fly fixing took place. But no one got discouraged, and we introduced a lot of features and bug fixes (and new bugs) as a result. Also, we taught using Max/MSP at the same time, which turned out to be fruitful, pedogogically since it exposed two very different paradigms, and practically because Max and ChucK tended to crash in different places, and having options for the task-at-hand is usually good. Perry, Dan Trueman, Scott Smallwood, and students can provide better, potentially different, and more extended perspectives, this was just my 2::cent on ChucK and PLOrk. If anyone else is using ChucK in the classroom (I know of folks at UVic, McGill, GA Tech, and few other places that use chuck to various degrees), we'd love to hear about it. Perhaps we can eventually make a list of places that use ChucK for education, and share our materials/experiences. (Feel free to fire away.) Best, Ge!

I'm taking a class with Gary Scavone at McGill, and though most of our sound coding has used Stk, Gary added a ChucK overview to the curriculum this year. One of my immediate motivations for learning it is for my imminent final class project, a ChucK FM improvisation. If I remember to record it, I'll put it up on the wiki! Also trying to power-learn vim... fun! --Tim On 20-Apr-06, at 7:30 PM, Ge Wang wrote:

If anyone else is using ChucK in the classroom (I know of folks at UVic, McGill, GA Tech, and few other places that use chuck to various degrees), we'd love to hear about it. Perhaps we can eventually make a list of places that use ChucK for education, and share our materials/ experiences.

Hi All,

...

I was running the stk/clarinet.ck example. No soundfiles involved at all. It was usually only in creating and destroying shreds that there was a problem. Actually, now that I think about it, glitching also occurred when I would change focus to another program and carry out some action, i.e. scrolling through the chuck manual in Adobe Reader. This is on an Intel with Pentium M, running Windows XP Pro with SP2.

Same thing here with the PDF file, and I also noticed it when switching to programs like Firefox or N.

Interesting that it seems likely to occur on fast machines running XP SP2, but not not on a PIII. I was also able to reproduce the same type of glitches changing windows on my XP SP2 Pentium M 1GB RAM laptop. So, XP users, let's try this - run chuck with the --level10 flag, which should internally boost chuck's priority: > chuck --level10 foo.ck ... For me this got rid of the glitches. If this works in genereal, we can make this a default. Also feel free to try other values. Let us know! Best, Ge!

Tom Lieber wrote:

On 4/20/06, Ge Wang wrote:

...

So, XP users, let's try this - run chuck with the --level10 flag, which should internally boost chuck's priority:

> chuck --level10 foo.ck ...

For me this got rid of the glitches. If this works in genereal, we can make this a default. Also feel free to try other values.

Let us know!

Worked for me.

for me too. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

Also, respectfully, if you're opening PDF files or running other programs while trying to do live ChucK performance, then you deserve to get clix :-) Seriously, though, boosting priority is indeed a good idea. We believe that ChucK should be the highest priority process. PRC On Thu, 20 Apr 2006, Ge Wang wrote:

Hi All,

...

...

I was running the stk/clarinet.ck example. No soundfiles involved at all. It was usually only in creating and destroying shreds that there was a problem. Actually, now that I think about it, glitching also occurred when I would change focus to another program and carry out some action, i.e. scrolling through the chuck manual in Adobe Reader. This is on an Intel with Pentium M, running Windows XP Pro with SP2.

Same thing here with the PDF file, and I also noticed it when switching to programs like Firefox or N.

Interesting that it seems likely to occur on fast machines running XP SP2, but not not on a PIII. I was also able to reproduce the same type of glitches changing windows on my XP SP2 Pentium M 1GB RAM laptop.

So, XP users, let's try this - run chuck with the --level10 flag, which should internally boost chuck's priority:

> chuck --level10 foo.ck ...

For me this got rid of the glitches. If this works in genereal, we can make this a default. Also feel free to try other values.

Let us know!

Best, Ge! _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 4/21/06, David Powers wrote:

Number 2 wouldn't happen in a performance, but number 1 certainly would occur, and would seem essential for live coding, at least until audicle reaches a really stable point in its development.

Speaking of Audicle and performance, has anyone gotten Audicle to run on Windows XP in a way that didn't stutter? My laptop is 2GHz and has 780 (or so) MB of ram and every time I touch anything related to the interface it stutters and interface updates become unbearably slow. Even typing code is next to impossible. At some point there will probably be some optimalisation and cpu's can be expected to become faster but this doesn't seem right. My laptop is aging now but I can't imagine that everybody else is running cpu's that are several orders of magnitude faster. In the demonstration videos it looks like Mac's are used, could it be that some sort of Mac speciffic optimalisation was used that didn't translate so well to IBM compattibles? Did I simply miss some video related settings? I don't understand any of the video card's settings, it's been years since I played games on a pc, the last video card with 3d settings that I understood a little was a monster 1 with 4 MB. I'd be very gratefull if somebody with some knowledge of those things could at least give some indication of what to look for. Kas.