[chuck-dev] Fwd: Oh no, I fixed it: log level bug.

[Ge Wang]

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
>> <ssalazar at cs.princeton.edu> 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 at lists.cs.princeton.edu
>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>>> 
>>> _______________________________________________
>>> chuck-dev mailing list
>>> chuck-dev at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>>> 
>> _______________________________________________
>> chuck-dev mailing list
>> chuck-dev at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev
>
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev