Hey Kassen, Interesting. The mini actually hasn't changed much recently, so its hard to think of specific changes that would have caused these problems. Maybe the underlying wxWidgets or GTK libraries have been updated recently, and something miniAudicle is doing is no longer agreeable to one or both of these libraries? If so, an interesting experiment would be to do a fresh recompile of the last version of miniAudicle with the same set of -dev libraries, and see if the same errors pop up. Anecdotally, I am no stranger to weird GTK error messages popping up occasionally in miniAudicle on whatever version of Linux I happen to be running. spencer On Oct 19, 2009, at 8:31 AM, Kassen wrote:

Spencer,

Last week I was practising/performing livecoding in the Mini on my little radio show. I got quite a few error messages on the console refering to some sort of GDM (I think) issue. No crashes, just errors that didn't use to be there. This was on Ubuntu Linux.

I think they mostly appeared at replacing shreds. Sadly I didn't yet have the time to look into this more closely, but this means that the updates did indeed cause some new minor issues. Full report soon, I hope (things have been a bit mad here lately).

Yours, Kas. _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

Hi all, The deprecated functions in RtAudio are a relatively easy fix. I will get around to it by December but I see no rush, as those functions are still supported until at least the next major OS release. RtAudio from 2005 ... wow, that's many releases old! I've mentioned to Ge many times that it would be nice if Chuck used the STK distribution "as is", rather than needing to concatenate all the files together. I haven't kept up that much on Chuck developments but I see soundfile support was added recently. That support could have been had for "free" using the STK FileWrite and FileRead classes many years ago, but I think those classes may not even be in Chuck. What is the problem with using the STK .h and .cpp files "as is" in Chuck? Regards, --gary On 2009-10-19, at 7:03 PM, Andrew C. Smith wrote:

Hm, I can't say whether this is a bug or not, but there were many audio methods that were deprecated in Snow Leopard that are still in use, mostly in the RtAudio files. The RtAudio files are all from 2005, also, and Gary Scavone just released a new version this June. It's still possible to compile under the 10.5 SDK, of course, but it's not exactly great news to be using old methods.

I think this is a pretty big issue, although not necessarily urgent, and it's something that I almost feel like I could investigate--building under Snow Leopard with more up-to-date methods. I wanted to check to see if this is of interest to the developers, though, because if so then I'll keep track of the changes I make. It would be pretty cool to have a fully-updated 64-bit build of ChucK, after all.

Andrew

On Mon, Oct 19, 2009 at 5:33 PM, Spencer Salazar wrote:

...

Hey Kassen,

Interesting. The mini actually hasn't changed much recently, so its hard to think of specific changes that would have caused these problems. Maybe the underlying wxWidgets or GTK libraries have been updated recently, and something miniAudicle is doing is no longer agreeable to one or both of these libraries? If so, an interesting experiment would be to do a fresh recompile of the last version of miniAudicle with the same set of - dev libraries, and see if the same errors pop up. Anecdotally, I am no stranger to weird GTK error messages popping up occasionally in miniAudicle on whatever version of Linux I happen to be running.

spencer

On Oct 19, 2009, at 8:31 AM, Kassen wrote:

...

Spencer,

Last week I was practising/performing livecoding in the Mini on my little radio show. I got quite a few error messages on the console refering to some sort of GDM (I think) issue. No crashes, just errors that didn't use to be there. This was on Ubuntu Linux.

I think they mostly appeared at replacing shreds. Sadly I didn't yet have the time to look into this more closely, but this means that the updates did indeed cause some new minor issues. Full report soon, I hope (things have been a bit mad here lately).

Yours, Kas. _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

Hi Kas, RtAudio has had ASIO support since version 4.1, released in October 2002. I don't know why it hasn't been in use in Chuck. As you say, it is the most stable choice in Windows and the only one that easily allows channel counts greater than 2. Regards, --gary On 22-Oct-09, at 3:45 PM, Kassen wrote:

Hi Garry.

The deprecated functions in RtAudio are a relatively easy fix. I will get around to it by December but I see no rush, as those functions are still supported until at least the next major OS release. RtAudio from 2005 ... wow, that's many releases old!

That would be good, as using the newer version or RtAudio would also solve the lack of ASIO on Windows, right? I have been campaigning for that for a long time now. Plain Windows audio drivers for realtime instrumentalist applications are a exercise in masochism, at least on XP.

What is the problem with using the STK .h and .cpp files "as is" in Chuck?

Data-types.

The STK lacks a concept of duration and so classes like Envelope in the plain STK set duration-based member functions in float. In ChucK we should clearly set duration in "dur". ChucK also changed the range of some parameters away from MIDI-based ranges to a 0-1 range. Also; we made some fixes to STK bugs that I'm not sure were send upstream.

I'm not sure what you mean by ChucK having added soundfile support recently. I suppose it depends on what you call "recent", but I'm sure it has been there since I have been around which is about since the Dracula version. I don't think I can remember any significant changes in that area over this period.

Syncing might still be good, but IMHO not without taking care that the way that ChucK uses the STK stays within this more ChucKist perspective on UGen control.

Yours, Kas. _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

...

What is the problem with using the STK .h and .cpp files "as is" in Chuck?

Just to be clear: RtAudio.cpp/.h are the same in both the ChucK and standard versions--we're talking about the ModalBar, Envelope, FM etc. UGens, right?

...

around to it by December but I see no rush, as those functions are still supported until at least the next major OS release.

Well, I asked in part because I was trying to work on the ChucK functions to iron the errors out of building toward the 10.6 SDK. Also, I ended up writing some stuff that wouldn't work with 10.5 SDK because of new Cocoa methods, and wouldn't work on 10.6 because of the RtAudio methods. I feel like I managed to hack it to just omit the problem functions, but I can't seem to find that modified RtAudio.cpp file... In case you don't have Snow Leopard, or you're not working on it yet, the functions that are deprecated are AudioHardwareGetProperty, AudioDeviceSetProperty, AudioHardwareGetPropertyInfo, AudioDeviceGetProperty, AudioDeviceGetPropertyInfo, AudioStreamGetProperty, AudioStreamSetProperty, and AudioDeviceAddPropertyListener. It seems like a pretty small set of functions, and nothing very complicated at all--just setter and getter methods that I would assume are replaced by @property and @synthesize, but who knows. My ugly hack involved using your playsaw program to probe for devices, then just using those property values as constants to drive my code. Um, I can't say it ever worked, though. Thanks, Gary, I didn't expect you to necessarily be listening in. Should be careful what I say on this list. Andrew On Thu, Oct 22, 2009 at 3:45 PM, Kassen wrote:

Hi Garry.

...

The deprecated functions in RtAudio are a relatively easy fix.  I will get around to it by December but I see no rush, as those functions are still supported until at least the next major OS release.  RtAudio from 2005 ... wow, that's many releases old!

That would be good, as using the newer version or RtAudio would also solve the lack of ASIO on Windows, right? I have been campaigning for that for a long time now. Plain Windows audio drivers for realtime instrumentalist applications are a exercise in masochism, at least on XP.

...

What is the problem with using the STK .h and .cpp files "as is" in Chuck?

Data-types.

The STK lacks a concept of duration and so classes like Envelope in the plain STK set duration-based member functions in float. In ChucK we should clearly set duration in "dur". ChucK also changed the range of some parameters away from MIDI-based ranges to a 0-1 range. Also; we made some fixes to STK bugs that I'm not sure were send upstream.

I'm not sure what you mean by ChucK having added soundfile support recently. I suppose it depends on what you call "recent", but I'm sure it has been there since I have been around which is about since the Dracula version. I don't think I can remember any significant changes in that area over this period.

Syncing might still be good, but IMHO not without taking care that the way that ChucK uses the STK stays within this more ChucKist perspective on UGen control.

Yours, Kas.

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

Thanks a lot, both to Ge and to Gary, and everyone else as well. It helps a lot, at least for me, to just hear a little bit of explanation of the source code's intentions, since it's sometimes difficult to tell what's going on with all of the larger ChucKian structures defined in various .h files. Glancing through the STK updates, stuff like Granulate would be awesome to see in ChucK--it would capitalize on the language's ability for quick sketches (via STK) which is (in my opinion) right up there with its sample-level control as one of the best design features/goals in ChucK. I finally got a dynamic library compiled, and some functions that pull samples through CoreAudio into a Cocoa program. Thanks especially to both Gary and Brad Garton, for the chuck~ object which I took as a sort of template. This has 1.2.1.3, though--I'm not sure what kind of environment I'm going for, but something toy-like that can be packaged as a standalone. Right now it just plays a sine wave, but once I get something cool working I'll send it along. Andrew On Fri, Oct 23, 2009 at 6:08 AM, Ge Wang wrote:

Greetings Gary and all!

First of all, thanks again for RtAudio - it's super useful, for ChucK (and pretty much anything we've implmented at that level at Princeton and CCRMA: TAPESTREA, sndpeek, rt_lpc, etc.).

...

The deprecated functions in RtAudio are a relatively easy fix.  I will get around to it by December but I see no rush, as those functions are still supported until at least the next major OS release.  RtAudio from 2005 ... wow, that's many releases old!

Yeah, we are a bit behind the times.  I think the main reason is this: we've taking an "if it ain't broken (more than say garbage collection in ChucK, or well, name your favorite disaster area), don't fix it" approach.  STK is working great (modulo bugs/inconsistencies we've introduced in the port to ChucK), and even though we may not have the latest features, what is in ChucK/STK is currently way functional (and considered stable, by ChucK standards, huh huh).

Another, also practical issue is that we've modified a lot (at least at the surface level) of the RtAudio we used, which for us has always been quite independent of STK.  In short, we have been lazy here.

...

From a linux point of view, we do have an clear impetus to upgrade to an

later RtAudio, as the version we use doesn't support ALSA/Jack in the same binary.

...

From a windows point of view, the priority is finding a way to be more

ASIO-friendly.

Yet another consideration is STK itself, we've made pervasive (though again fairly shallow changes) to the version we had to support all the STK functionalities.

I do remember Gary asking me on several ocasions about what types of changes we'd like to see in RtAudio and STK to facilitate integration. That's totally awesome of Gary, by the way.  I haven't had made the time to properly investigate this (also remembering how long it took Ari and I to integrate/modify the current version of STK in ChucK).  Now that I am recommitting myself to the development, I will make it a priority to look more deeply into this.

As a point of information, I've been also been using RtAudio at CCRMA in the Music, Computing, and Design courses - in this scenario, we have been encouraging the latest version of RtAudio.  This has been a greatly positive thing, though we have encountered a recent weirdness - 4.0.6 on the latest Apple MacBook Pro hardware seems to have issues setting sample rate (in some cases, it favors 96K no matter what you ask for, and in other cases, it arbitrarily chooses a sample rate), and this behavior has been duplicated on several machines with independently written/debugged code.  This doesn't seem to happen at all with older version of RtAudio. We found this about 3 weeks ago.  Apologies for not reporting earlier.

...

I've mentioned to Ge many times that it would be nice if Chuck used the STK distribution "as is", rather than needing to concatenate all the files together.  I haven't kept up that much on Chuck developments but I see soundfile support was added recently.  That support could have been had for "free" using the STK FileWrite and FileRead classes many years ago, but I think those classes may not even be in Chuck.

What is the problem with using the STK .h and .cpp files "as is" in Chuck?

I hope the above offers some explanation, or at least observations.

Once again, thank you Gary for RtAudio, and for continuing on with STK. They truly rock, and we do look forward to making the ChucK framework better at taking advantage of current versions.  Thinking practically, it will be large undertaking (certainly worthwhile), and will not happen at a rate that's likely to please many (even those with drastically lowered expectations thanks to working with ChucK).  In the meantime, if someone can offer a patch to use non-deprecated methods in the current, rather old, RtAudio (and still have it compilable on 10.3.9 or 10.4 and later), it would be a helpful stopgap.

All the best, Ge!

...

On 2009-10-19, at 7:03 PM, Andrew C. Smith wrote:

...

Hm, I can't say whether this is a bug or not, but there were many audio methods that were deprecated in Snow Leopard that are still in use, mostly in the RtAudio files. The RtAudio files are all from 2005, also, and Gary Scavone just released a new version this June. It's still possible to compile under the 10.5 SDK, of course, but it's not exactly great news to be using old methods.

I think this is a pretty big issue, although not necessarily urgent, and it's something that I almost feel like I could investigate--building under Snow Leopard with more up-to-date methods. I wanted to check to see if this is of interest to the developers, though, because if so then I'll keep track of the changes I make. It would be pretty cool to have a fully-updated 64-bit build of ChucK, after all.

Andrew

On Mon, Oct 19, 2009 at 5:33 PM, Spencer Salazar wrote:

...

Hey Kassen,

Interesting.  The mini actually hasn't changed much recently, so its hard to think of specific changes that would have caused these problems.  Maybe the underlying wxWidgets or GTK libraries have been updated recently, and something miniAudicle is doing is no longer agreeable to one or both of these libraries?  If so, an interesting experiment would be to do a fresh recompile of the last version of miniAudicle with the same set of -dev libraries, and see if the same errors pop up.  Anecdotally, I am no stranger to weird GTK error messages popping up occasionally in miniAudicle on whatever version of Linux I happen to be running.

spencer

On Oct 19, 2009, at 8:31 AM, Kassen wrote:

...

Spencer,

Last week I was practising/performing livecoding in the Mini on my little radio show. I got quite a few error messages on the console refering to some sort of GDM (I think) issue. No crashes, just errors that didn't use to be there. This was on Ubuntu Linux.

I think they mostly appeared at replacing shreds. Sadly I didn't yet have the time to look into this more closely, but this means that the updates did indeed cause some new minor issues. Full report soon, I hope (things have been a bit mad here lately).

Yours, Kas. _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev