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

Fri Oct 23 22:02:24 EDT 2009

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