Fellow ChucKists, I'm rather displeased right now, which is a bit of a euphemism for "I feel like breaking stuff". I have a issue in my sequencer that I'm sure relates to floating-point denormalisation (involving a feedback loop on a LiSa) as I have CPU spikes that occur after a while and stay present after re-starting ChucK. These are quite hard to pinpoint as they take a while to surface. Even if I would find the culprit I'd then have to see whether it still exists in the current version of ChucK because I'm running into this on the latest ASIO version that we have around, which is downright out of date. All of this is very, very frustrating, frustrating to the tune of looking for what's wrong for three days on end. It's probably fixable but it's frustrating that there is no canonical ASIO version of ChucK and that there hasn't been more attention to floating-point denormalisation. One of the main advantages over SC is that we can do sample-accurate feedback in CK, yet we throw much of that away if we risk this. There is also no Windows version out of the box that can use multi-channel audio and have acceptable latency. Both seem quite serious to me. Could something be done about this? I've been thinking about how hard it would be to port my setup to a hardware PIC or even SC. None of this should be necessary at all; a out-of-the-box ASIO version is quite reasonable and I believe that from the time denormalisation has been a issue there have been instructions to simply round to 0. Yours, Kas.
Hi Kassen! I feel your pain! We'll definitely get on it. There are actually macro's throughout to combat floating point denormalization (for example, measures are taken in the general UGen architecture and also strategically added to all of STK in ChucK where there is feedback that could lead to denormalization), but perhaps they have not yet made their way into LiSa. Do you have a minimal example of the feedback loop that leads to floating-point denormalization? ASIO is long due and I am sorry it's not part of the canonical ChucK release yet. Spencer has actually been be gearing up for massive ChucK/miniAudicle development here at CCRMA. We will priority boost ASIO support! Rock on, Ge! On Wed, 3 Nov 2010, Kassen wrote:
Fellow ChucKists, I'm rather displeased right now, which is a bit of a euphemism for "I feel like breaking stuff".
I have a issue in my sequencer that I'm sure relates to floating-point denormalisation (involving a feedback loop on a LiSa) as I have CPU spikes that occur after a while and stay present after re-starting ChucK. These are quite hard to pinpoint as they take a while to surface. Even if I would find the culprit I'd then have to see whether it still exists in the current version of ChucK because I'm running into this on the latest ASIO version that we have around, which is downright out of date.
All of this is very, very frustrating, frustrating to the tune of looking for what's wrong for three days on end. It's probably fixable but it's frustrating that there is no canonical ASIO version of ChucK and that there hasn't been more attention to floating-point denormalisation. One of the main advantages over SC is that we can do sample-accurate feedback in CK, yet we throw much of that away if we risk this. There is also no Windows version out of the box that can use multi-channel audio and have acceptable latency.
Both seem quite serious to me. Could something be done about this? I've been thinking about how hard it would be to port my setup to a hardware PIC or even SC. None of this should be necessary at all; a out-of-the-box ASIO version is quite reasonable and I believe that from the time denormalisation has been a issue there have been instructions to simply round to 0.
Yours, Kas.
Ge Wang wrote:
I feel your pain! We'll definitely get on it. There are actually macro's throughout to combat floating point denormalization (for example, measures are taken in the general UGen architecture and also strategically added to all of STK in ChucK where there is feedback that could lead to denormalization), but perhaps they have not yet made their way into LiSa. Do you have a minimal example of the feedback loop that leads to floating-point denormalization?
ASIO is long due and I am sorry it's not part of the canonical ChucK release yet. Spencer has actually been be gearing up for massive ChucK/miniAudicle development here at CCRMA. We will priority boost ASIO support!
And 64-bit linux support! :) michael
2010/11/3 Ge Wang
Hi Kassen!
Hey Ge! I suppose it's clear that that message was send in a bit of a emotional mood. Indeed these are important topics and a bit more attention to them here&there would be good so it might be good to push them a little... But I should also point out that I went back to a older version (I have backups, fortunately) and enjoyed a good live session after all jamming with my friend Rob who wrote his own system in Pure Data.
I feel your pain! We'll definitely get on it. There are actually macro's throughout to combat floating point denormalization (for example, measures are taken in the general UGen architecture and also strategically added to all of STK in ChucK where there is feedback that could lead to denormalization), but perhaps they have not yet made their way into LiSa. Do you have a minimal example of the feedback loop that leads to floating-point denormalization?
I appreciate that this is a complex issue, I'll try to get you a example. Part of my problem is that even I can't find exactly where and what is going wrong here now; it's quite involved. With ChucK we can have a very fast iteration rate, but if the bug takes a few minutes to surface that rate can go down quite dramatically, with quite a few false-positives.... I suppose I got this issue having a fast iteration rate, which made sure bugs that take a while to surface will only come up after changing quite a few things. There might be a lesson there.
ASIO is long due and I am sorry it's not part of the canonical ChucK release yet. Spencer has actually been be gearing up for massive ChucK/miniAudicle development here at CCRMA. We will priority boost ASIO support!
Thanks! Between the atrociously long latency of WMA (I have no idea what Redmond was thinking there), the existence of ASIO4ALL, the issues with multi-channel WMA, and the updates to RTAudio since ChucK was conceived I think this is a winning situation all round. I'm also looking forward to the update to the Mini, Spencer's work is always top notch. Thanks! Kas.
Hey all,
Spencer has actually been be gearing up for massive ChucK/miniAudicle development here at CCRMA.
A couple of shameless miniAudicle requests/ideas... 1. The ability to send highlighted bits of code to the VM as a shred ala SuperCollider. 2. Fix ChucK shell. It crashes on the most recent mini on OSX. One can attach from Terminal to get around this. 3. Tabs on OSX like on Linux??? Thanks. Happy ChucKing. Kurt -- -------------------------------------------------- www.kurtkotheimer.com --------------------------------------------------
Kurt; 3. Tabs on OSX like on Linux???
And ctrl+n should, in addition to creating a new tab/buffer, place the keyboard focus in this buffer. I'd call this a bug. Ctrl+tab should cycle through the buffers, also placing keyboard focus in the relevant field. Strictly speaking this would be a new feature but essentially it's a matter of conforming to standards; I think all modern programs using tabs do this. These two operations require a mouse, which slows usage down, at least on Linux. Yours, Kas.
Ctrl+tab should cycle through the buffers, also placing keyboard focus in the relevant field. Strictly speaking this would be a new feature but essentially it's a matter of conforming to standards; I think all modern programs using tabs do this.
Yes, good keyboard behavior is also necessary if a program is to be usable by blind people using screen readers. Thanx. -- Rich From: Kassen Sent: Thursday, November 11, 2010 11:50 AM To: ChucK Users Mailing List Subject: Re: [chuck-users] annoyances Kurt; 3. Tabs on OSX like on Linux??? And ctrl+n should, in addition to creating a new tab/buffer, place the keyboard focus in this buffer. I'd call this a bug. Ctrl+tab should cycle through the buffers, also placing keyboard focus in the relevant field. Strictly speaking this would be a new feature but essentially it's a matter of conforming to standards; I think all modern programs using tabs do this. These two operations require a mouse, which slows usage down, at least on Linux. Yours, Kas. -------------------------------------------------------------------------------- _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (5)
-
Ge Wang -
Kassen -
kurt -
Michael Heuer -
Rich Caloggero