Hello, As many have already noticed, the current release version of ChucK does not run in real-time audio mode on Mac OS X Lion. Until now! In advance of a formal release, we are providing builds of the current SVN source for anyone who is having trouble getting ChucK to run on Lion. ChucK (Mac OS X Universal command line executable): https://ccrma.stanford.edu/~spencer/chuck/chuck-1.2.1.4-beta-1.tgz miniAudicle (Mac OS X Universal binary): https://ccrma.stanford.edu/~spencer/chuck/miniAudicle-0.2.1-beta-1.tgz Lion users, please let us know if you continue to have difficulties with real-time audio with these builds. Updating ChucK to use the latest version of RtAudio fixed a host of Lion issues; a minor bugfix in RtAudio resolved the remaining issue. There are a lot of other cool things coming too when the new version of ChucK is released. Special thanks to Gary Scavone for making peace between Mac OS X Lion and RtAudio. Peace! spencer + chuck team
Just downloaded and installed and ran the "Hello, world" test with an
awe-inspiring test tone!
Thanks!
~~Dennis
"Make me one with everything, please"
~~ Dalai Lama to the hot-dog vendor...
http://www.soundcloud.com/usrsbin
http://audiozoloft.org
On Tue, Aug 16, 2011 at 5:42 PM, Spencer Salazar
Hello,
As many have already noticed, the current release version of ChucK does not run in real-time audio mode on Mac OS X Lion. Until now! In advance of a formal release, we are providing builds of the current SVN source for anyone who is having trouble getting ChucK to run on Lion.
ChucK (Mac OS X Universal command line executable): https://ccrma.stanford.edu/~spencer/chuck/chuck-1.2.1.4-beta-1.tgz
miniAudicle (Mac OS X Universal binary): https://ccrma.stanford.edu/~spencer/chuck/miniAudicle-0.2.1-beta-1.tgz
Lion users, please let us know if you continue to have difficulties with real-time audio with these builds.
Updating ChucK to use the latest version of RtAudio fixed a host of Lion issues; a minor bugfix in RtAudio resolved the remaining issue. There are a lot of other cool things coming too when the new version of ChucK is released.
Special thanks to Gary Scavone for making peace between Mac OS X Lion and RtAudio.
Peace! spencer + chuck team _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Spencer Salazar wrote:
As many have already noticed, the current release version of ChucK does not run in real-time audio mode on Mac OS X Lion. Until now! In advance of a formal release, we are providing builds of the current SVN source for anyone who is having trouble getting ChucK to run on Lion.
ChucK (Mac OS X Universal command line executable): https://ccrma.stanford.edu/~spencer/chuck/chuck-1.2.1.4-beta-1.tgz
miniAudicle (Mac OS X Universal binary): https://ccrma.stanford.edu/~spencer/chuck/miniAudicle-0.2.1-beta-1.tgz
Lion users, please let us know if you continue to have difficulties with real-time audio with these builds.
Updating ChucK to use the latest version of RtAudio fixed a host of Lion issues; a minor bugfix in RtAudio resolved the remaining issue. There are a lot of other cool things coming too when the new version of ChucK is released.
Special thanks to Gary Scavone for making peace between Mac OS X Lion and RtAudio.
Peace! spencer + chuck team
Great news, Spencer! Does this mean that a 64-bit linux build might also be in the works? michael
Great work, Spencer! I too am curious how this will affect the other OS's. For example; ASIO on Windows should provide low latency performance as well as multi-channel and the whole OSS/ALSA/Jack situation on Linux had quite some people confused. As I understand it the newer RTAudio should solve all that in one swoop? Yours, Kas.
Hello!
Michael --
64-bit support on all platforms is blocked by one fundamental and
deep-rooted implementation issue in ChucK proper -- there are swaths
of assumptions about byte-lengths of intrinsic C/C++ storage types.
Due to the extent of these issues and the degree of testing that would
be required upon resolving them, we can't justify making 64-bit a
priority at this point.
Kassen --
Indeed, updating RtAudio will allow us to more easily provide ASIO
support and sort out the Linux audio landscape in perhaps a more
sensible way, which I am very pleased about. Probably the most
immediate manifestation will be in the form of a separate ASIO binary
aimed at "power users"; down the line I envision command line flags to
select which audio backend you want to use, within a single binary.
By the way, do you have links to mailing list or forum posts related
to the Linux audio confusion? I must have missed or forgotten that
thread, and it would be good to understand more specifically whats
leading to the confusion.
spencer
2011/8/18 Kassen
Great work, Spencer!
I too am curious how this will affect the other OS's. For example; ASIO on Windows should provide low latency performance as well as multi-channel and the whole OSS/ALSA/Jack situation on Linux had quite some people confused. As I understand it the newer RTAudio should solve all that in one swoop?
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hey Spencer!
Indeed, updating RtAudio will allow us to more easily provide ASIO support and sort out the Linux audio landscape in perhaps a more sensible way, which I am very pleased about. Probably the most immediate manifestation will be in the form of a separate ASIO binary aimed at "power users"; down the line I envision command line flags to select which audio backend you want to use, within a single binary.
Yes, this makes sense to me. For one thing this scenario already proved itself with the "unofficial" ASIO version that was there already. it'd be a good idea to also consider a ASIO version of The Mini, in this context. There was talk about this on the list in the past, searching for ASIO should get you some of Stephen Sinclair's notes on compiling it in.
By the way, do you have links to mailing list or forum posts related to the Linux audio confusion? I must have missed or forgotten that thread, and it would be good to understand more specifically whats leading to the confusion.
Actually it was quite simple; there was a .deb package that a lot of new users took. Quite a sensible choice, of course. That package was for Jack, which is also a sensible choice... but then it turned out that quite a few of those new users were unaware of how to use Jack and didn't yet know how to start the server, etc. This led a disappointingly silent first experience. I'd like to suggest that we try for a binary that first check whether there is a Jack server running and connects to it if there is. If not it'd fall back on ALSA. With no ALSA available it could take OSS as a last resort, though I wonder how likely that situation is in practice. If that could/would work we would probably be done with all of those questions for a very long time and it'd be very convenient too. I suppose flags should over-ride this, for example if Jack is running and using soundcard A and you want ChucK to use ALSA on soundcard B for some reason. Does that make sense? Does it sound realistic? Yours, Kas.
participants (4)
-
Dennis Moser
-
Kassen
-
Michael Heuer
-
Spencer Salazar