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

23 Oct 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  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