ChucK takes long time to abort

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

I am a new ChucK user, developing stuff for realtime performance.

As I've been developing my code, I have needed to abort chuck fairly often in order to make changes. I have several questions:

First, why does it take so long for the VM to "clean up" and abort after I tell it to (with Ctrl-C)? Even if I kill the process with the task manager, it still seems to take several minutes.

Second, if I were to start a second VM while the first VM is still in "Cleanup" mode, what happens to new code added? Can I assume that the first VM is effectively gone, or is it still doing stuff with programs and resources (e.g. the midi device, etc.).

-- Larry

Blue Hell · Posted: Tue May 27, 2008 4:29 pm Post subject:

Larry

Did use ChucK really just a couple of times, but didn't see such slow aborts.

When I have programs (of my own) that won't shut down it usually is because one of the threads is still waiting for an event or a semaphore, this could be related to some device driver not behaving as expected.

Kassen · Posted: Tue May 27, 2008 6:12 pm Post subject:

Hey, Larry.

This is definitely not normal, quitting should take something like half a second or so, though it can take more if there's some issue that makes it crash. What version are you using? I've had some issues with the latest ASIO version (for this board) quitting in less then clean ways.

Unless you are defining public classes (which you can only clean from the VM by quitting it) there is no real need to quite the VM to update code. This may be a workaround until we diagnose the issue.

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

Yes, I am creating public classes. My goal is to create a set of public classes that can be accessed by various instantiated classes to manage my equipment. While I am getting these working, I find it necessary to quit the VM all the time. Since these classes need to refer to each other, I'm not sure how do it by updating private classes.

I am using v1.2.1.1, as downloaded during the last week.

Also, in the absence of include files, I need a way to provide a large number of standard definitions for various things like patch settings, etc, as it is really painful to have to use integer values for everything.

I'd be happiest with include files in which I could define constants private to whichever file includes them, but I'm ok with a set of public constants.

I'm coming from a C++ background, so I tend do things C++ style, although I do have Java experience as well.

Speaking of which, is there a way to specify that a particular item is a constant, so that it can't be changed?

-- Larry

Kassen · Posted: Wed May 28, 2008 4:17 pm Post subject: Re: Public classes - yes

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

Thanks!

Blue Hell · Posted: Wed May 28, 2008 5:29 pm Post subject:

Larry, I edited out the email addie that was a bit too obvious in your post, I know it's probably on the internet like everywhere, but still I think we should be a bit careful with 'm here.

Kassen · Posted: Thu May 29, 2008 4:31 am Post subject: Re: Thanks!

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

Well, I'm using a midi device, since my goal is to interface to my keyboard setup. Its a USB MidiSport 1x1. That device seems to work fine - seemed responsive enough to play as a thru device without any audible glitches.

-- Larry

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

I've narrowed it down to the attached program. If I run chuck and then abort, or run some simple keyboard handling stuff, it quits right away. But after I run the attached program (gmidi.ck), it takes five minutes to quit.

All this program does is open the midi in and out devices for later use. I've tried putting in me.exit() calls, but this does not change the behavior.

-- Larry

gmidi.ck

Description:

Download

Filename:

gmidi.ck

Filesize:

1.31 KB

Downloaded:

79 Time(s)

Kassen · Posted: Sat May 31, 2008 11:13 am Post subject: Re: Program causing problem

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

Unfortunately, I have tried the task manager approach, and it still takes the 5 minutes. This sounds like it might be one more reason to hate my Gateway.

I haven't tried updating the drivers, so I'll see if that makes a difference. But I haven't had this type of issue with any other program, and I've been using the Midi Sport for several years.

Thank you for your help!

BTW, I noticed that there are a number of methods on the MidiIn/Out ugens that aren't documented (at least in the pdf doc that comes with the distribution). (e.g. Name()). Is there a more comprehensive list of such methods?

One challenge I have at the moment is that which device is assigned to my Midisport output changes depending on the configuration of the computer. For example, if I boot with the wireless card, and plug the midisport in after startup, the output port is device 2, but if I boot from scratch with my sound card (Creative Audigy 2 ZS) and the midisport both attached, the output port is device 1.

I don't want to have to keep modifying my chuck setup program each time I run the system, so I'd like a way of enumerating the devices and getting the info from them so I can determine the correct device automatically.

I'm not sure how to do this, other than check the name string. Can I (and if so, how) compare strings or something? Or is there some other device info I can check?

It would probably be helpful to be able to do similar things with the audio devices, to make sure my adc and dac gens go exactly where I want them to.

-- Larry

Kassen · Posted: Sat May 31, 2008 11:43 pm Post subject:

Here you go;

larryreed · Joined: May 27, 2008 Posts: 18 Location: California

Thanks for the --verbose9 tip, and the help on strings.

strings are not in the manual, which is why I got confused. At first, I thought there just wasn't any support for it, but then I realized there had to be if only to support the midi device name() method. So I tried constructing some string arrays, and voila!

Here is the verbose output after hitting ctrl-C. I run chuck --verbose9 --loop in one window, and chuck + gmidi.ck in the other. I get a bunch of output, so forgive me for including it all. The hang is while is is trying to shut down the real-time audio. Not a clue about this, I'm not doing any audio at all, and it doesn't matter whether I have my sound card installed or not.

Anyway, I've taken up too much of your time already. I found that by implementing stubs for my gmidi and midithru programs, I can develop a lot quicker, because so much of what I'm doing at the moment is the command infrastructure, and doesn't really need the midi stuff.

So I only have to deal with the timeout issue when I am testing the actual midi operations.

Thanks again!

-- Larry

chuckout.txt

Description:

verbose output for 5-minute abort problem

Download

Filename:

chuckout.txt

Filesize:

6.54 KB

Downloaded:

71 Time(s)

Kassen · Posted: Mon Jun 02, 2008 6:48 am Post subject:

Well, then... Then strings need to be on the list for inclusion in the manual as well :¬). New users of ChucK are a very valuable resource because they tend to find lots of stuff that's underdocumented that more experienced users glance over.

I'm happy to help, BTW, as long as I'm can address issues whenever I have a moment to spare it's all fun puzzles to me and considering how much ChucK has done for me it's only fair to do something back :¬)

That said; your issue here looks like it's beyond my skills to fix and you're going to need one of the Dev's. If it's really in the realtime audio that might actually point at a bug in the library that's used for that... or a issue with your soundcard... and that's beyond me, I fear.

At least we got a lot closer to pinpointing it. If you didn't already I suggest a mail to Ge and simply linking to this topic.