It seems that Chuck_Array4::zero() in chuck_oo create a "Debug Assertion Failed" Error. The Microsoft vector class is complaining about "vector subscript out of range". I am using VS2005.

For what it's worth, I got the exact same error after building with Visual Studio 2005 and trying to run some of the example files. I then built with Visual C++ 6.0 and the problem went away. I assume it's the std::vector class it's complaining about. The STL implementation in VS 2005 is completely different than VC++ 6.0, so it wouldn't surprise me if there are STL-related issues with VS 2005 builds if the ChucK code has only been tested with VC++ 6.0. Dylan

On 6/21/07, Philippe Lamarche wrote: BTW, i am running Chuck on Asio since a few days. Brilliant!

Please know that I am not sure at all if this create bugs or not, but it's a start I guess.

Well, let's test it then :¬) I'm not at all familiar with compiling on XP so I'd be very gratefull if this .exe could be posted somewhere or perhaps you could send it to me (if it's deemed too experimental right now?). I have a Emu1616m here and access to a RME cardbus so that's two architectures already. This is great news! Thanks, Kas.

On 6/21/07, Philippe Lamarche wrote:

I am a member of electro-music and I debated posting it there since then. If you think it's ok to post the exe there, I will.

I'm sure it is. Likely it'll need a pointer to the ChucK (and other) lisences but that's the only issue I can think of. EM in general welcomes things like this. I am not, however, sure EM permits .exe as a extention for attachments (we get a LOT of very dubious spam-posts). You might have to rename it and post it with some instructions to name it back. If you run into any trouble you can mail Stein; stein.grebstad (at) editors.electro-music.com He runs the server the atachements and other files are on and he can without any doubt set you up. We'll need to watch this though. I think this should be out and up quickly and get tested but we shouldn't forget about it and get bug-reports on it in half a year when it's the first chuck.exe somebody might see, unaware of the experimental nature. Another option would be the WiKi. Can the WiKi take 1.4MB (or so) attachments? Yours, Kas.

On 6/21/07, Philippe Lamarche wrote:

Hi, I just posted a message with the executable.

It should work... i hope.

It works here! Multi-channel works as well. "In-depth" evaluation at the forum topic, not to move the discussion but to hopefully keep reports in one place as much as possible. Likely this should go on the main list as well? Yours, Kas.

On 6/23/07, Ge Wang wrote:

Next we should also figure out how to best roll this into the distro. Should we include two exe's? Another eventual option is to finally upgrade to the newest RtAudio, which has runtime support for multiple API's - this will happen sooner or later we think, and we hope to work with Gary Scavone to make transition smoothly. What to do in the meantime?

I looked over the RTAudio notes on multiple API's in anticipation of the arival of the .exe and that definately seems like the way to go in the future. I'd say that would also be the way to go for Linux. If you want only one of the two I think ASIO is the obvious choice because there is ASIO4ALL to turn a WM style soundcard into a ASIO suporting one but the other way around doesn't exist (And would be similar to trying to sell a kit that can turn a Ferari into a Trabant). On that topic I think it's very good news that this works with ASIO4ALL according to Consul. This Windows Media style of audio drivers is realy, realy, terribly slow which I can't stress enough is very bad for realtime (musical) performance. The one thing that's good about it -to me- is that it made me think a lot about creative input quantisation. I realise Princeton is basically all Mac's. If you're used to a Mac I think it might be hard to imagine how attrociously bad and slow Windows Media drivers are. Maybe two exe's would be best. The files should be very similar which hopefully the zip compression will pick up on? Also, in the interest of getting lots of feedback on this I still think this should go to the main users list as well but I think that's for Philippe or you to post. It'd be good to know about incompatibilities, issues or potential fire-hazards before this goes into the main distribution. Kas.

Hi Philippe, The latest release of RtAudio is 3.0.3. It was a minor update from 3.0.2. I am working on version 4.0, which will include a number of new features that will likely be of interest to ChucK users. The main changes include: - new support for non-interleaved user data - additional input/output parameter specifications, including channel offset - new support for dynamic connection of devices (like USB) - new support for stream time - revised callback arguments, including separate input and output buffer arguments - revised C++ exception handling - discontinued support of blocking functionality There are a few API changes, mainly in the openStream() and callback functions. The new stream parameters allow one to specify a channel "offset" on a multichannel device, for example, allowing you to use only channels 7 and 8 if desired. I am also discontinuing support for the SGI "al" API, given that I cannot test it anymore. I've finished the CoreAudio and Windows APIs (DirectSound and ASIO). As well, I've made a JACK interface that works in both OS-X and Linux. However, I have yet to work on the ALSA and OSS implementations. Given my current "to do" list, it is unlikely I will finish this up before the end of the summer. So, if you're in a hurry, go with version 3.0.3 but keep in mind that you'll probably want to switch to 4.0 when it becomes available. Regards, --gary On 23-Jun-07, at 12:57 PM, Philippe Lamarche wrote:

I will try to integrate the new version of RTaudio and see what comes up with it. If i understand correctly version RTAudio 3.0.2 is alreay in Chuck. This version has multiple API capacity. I think that I am already compiling for multiple API, but since ChucK doesn't provide any argument to the Rtaudio constructor, it always take ASIO because it's higher in the list than DS. If we can provide an argument to RTaudio constructor, probably coming from the command line, it should work.

I will try it in a few days.

Thanks, Philippe.

On 6/23/07, Kassen wrote: On 6/23/07, Ge Wang wrote:

Next we should also figure out how to best roll this into the distro. Should we include two exe's? Another eventual option is to finally upgrade to the newest RtAudio, which has runtime support for multiple API's - this will happen sooner or later we think, and we hope to work with Gary Scavone to make transition smoothly. What to do in the meantime?

I looked over the RTAudio notes on multiple API's in anticipation of the arival of the .exe and that definately seems like the way to go in the future. I'd say that would also be the way to go for Linux.

If you want only one of the two I think ASIO is the obvious choice because there is ASIO4ALL to turn a WM style soundcard into a ASIO suporting one but the other way around doesn't exist (And would be similar to trying to sell a kit that can turn a Ferari into a Trabant). On that topic I think it's very good news that this works with ASIO4ALL according to Consul.

This Windows Media style of audio drivers is realy, realy, terribly slow which I can't stress enough is very bad for realtime (musical) performance. The one thing that's good about it -to me- is that it made me think a lot about creative input quantisation. I realise Princeton is basically all Mac's. If you're used to a Mac I think it might be hard to imagine how attrociously bad and slow Windows Media drivers are.

Maybe two exe's would be best. The files should be very similar which hopefully the zip compression will pick up on?

Also, in the interest of getting lots of feedback on this I still think this should go to the main users list as well but I think that's for Philippe or you to post. It'd be good to know about incompatibilities, issues or potential fire-hazards before this goes into the main distribution.

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