Various general questions

Robin Haberkorn

23 Mar 2012 23 Mar '12

11:37 a.m.

Hi! I'm relatively new to ChucK. I knew it for some time but only now I start using it "seriously". I have a couple of questions and hope that you may answer them: 1) Does ChucK have a public source repository? (This question may be off-topic...) I understand that CVS was used but I think I read somewhere that it was replaced with SVN. The Git repo here (http://repo.or.cz/w/chuck-blob.git) hasn't been updated for a long time and thus cannot reflect the recent changes some of you are talking about in the mailing list. Having a public repo somewhere could greatly facilitate the project and I feel that it is a must-have for every modern open source project. As I'm a developer myself, I might get tempted to fix one of the many bugs ChucK unfortunately still has. Without the repo, I cannot check whether it is already fixed in the development branch. Without the repo or any nightly exports, people cannot try out and test new features, give feedback, etc... 2) Is there a real bug tracker somewhere? I found the one in the wiki, but it is somewhat confusing... 3) Is there a way to use multiple sound devices in one ChucK VM? I'm using chuck 1.2.1.3 on Linux-ALSA. It seems I have to specify the dac on the command line (--dacX). This could probably be used to start one VM per soundcard and exchange audio data via netout/netin. I will try this soon. However just out of curiosity, is multiple-dac support in one VM anticipated some time in the future? 4) regarding netout/netin. This may also be useful for integration with other applications like Pure Data. Does anyone have experience with it or details about the protocol if there is any? If not I will have a look at it as soon as I need it and write a Pure Data external if necessary. 5) I read about an Un-Chuck operator (=<). However it appears nowhere in the current docs. Is it still supported, or temporarily disabled? 6) In the "Developer Guide" I read something about OpenGL support. This was the only mention of OpenGL support I came across. I suppose if this really exists, it is a new development feature since v1.2.1.3 does not appear to posses any (undocumented) OpenGL API. Best regards, Robin Haberkorn

Show replies by date

Robert Poor

23 Mar 23 Mar

1:32 p.m.

On Fri, Mar 23, 2012 at 08:37, Robin Haberkorn wrote:

...

1) Does ChucK have a public source repository?

+10 to this question. I REALLY recommend GitHub as ChucK's official repository. It's an awesome facility: you can fork branches for testing new features. It has a really great bug tracker. It uses a simple markup language for documentation. And it's free. Does Ge have authority (or at the the persuasive skills) to make this happen? If not Ge, then whom? - Rob P.S.: I'm happy to help set up a public GitHub repository if that would help.

Robin Haberkorn

2:43 p.m.

On 23/03/12 18:32, Robert Poor wrote:

...

On Fri, Mar 23, 2012 at 08:37, Robin Haberkorn wrote:

...
1) Does ChucK have a public source repository?

+10 to this question. I REALLY recommend GitHub as ChucK's official repository. It's an awesome facility: you can fork branches for testing new features. It has a really great bug tracker. It uses a simple markup language for documentation. And it's free.

I assume the ChucK team already uses some kind of VCS, be it CVS, SVN or whatever. I was just wondering whether it is public!? But yes, I would also recommend GitHub. CVS or SVN imports really aren't that difficult to create. Done it several times. The most time-consuming part would be writing the mapping of CVS/SVN usernames to Git usernames/emails so everyone gets proper credit/blame for past commits on GitHub. And by the way, you would also get an independent ChucK wiki for free. If dependence on the GitHub company is a concern: if GitHub closes down you will have dozens of complete repository clones on users' systems. You can also host a public but non-accessible Git repository at the university and push to GitHub automatically - or only manually or certain branches. There are endless possibilities. And as you pointed out Git itself gives you several advantages in the development process I've learned to appreciate. For instance if you're a core developer, you don't have to make your feature branch public, you can keep it in your local repository, rebase it onto the master branch and finally fast-forward merge it. You can use the "stash" to efficiently handle work-in progress changes, etc. But frankly merging is the only thing that *can* give you a headache in Git from time to time. This is probably workflow-related. (Plain) Git simply does not seem to imply a workflow with multiple stable version branches between which you exchange changesets and track their relationship. Although using "cherry-picking" something like that can probably be built on top of Git. However considering what I saw in the CVS Git-mirror, this will likely not be an issue with ChucK. cheers, Robin

...

Does Ge have authority (or at the the persuasive skills) to make this happen? If not Ge, then whom?

- Rob

P.S.: I'm happy to help set up a public GitHub repository if that would help. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Tomtom

4:30 p.m.

Hi. I totally agree with you about github and the usefulness of public repositories for opensource project. Unfortunately, this discussion pops up every three months or so on this mailing list, and so far nothing has moved in this direction. I guess this is not a priority to the core devs, but it's their work, so the decision is in their hands. Tom On Fri, 23 Mar 2012 19:43:40 +0100, Robin Haberkorn wrote:

...

On 23/03/12 18:32, Robert Poor wrote:

...
On Fri, Mar 23, 2012 at 08:37, Robin Haberkorn wrote:

...
1) Does ChucK have a public source repository?

+10 to this question. I REALLY recommend GitHub as ChucK's official repository. It's an awesome facility: you can fork branches for testing new features. It has a really great bug tracker. It uses a simple markup language for documentation. And it's free.

I assume the ChucK team already uses some kind of VCS, be it CVS, SVN or whatever. I was just wondering whether it is public!?

But yes, I would also recommend GitHub. CVS or SVN imports really aren't that difficult to create. Done it several times. The most time-consuming part would be writing the mapping of CVS/SVN usernames to Git usernames/emails so everyone gets proper credit/blame for past commits on GitHub. And by the way, you would also get an independent ChucK wiki for free. If dependence on the GitHub company is a concern: if GitHub closes down you will have dozens of complete repository clones on users' systems. You can also host a public but non-accessible Git repository at the university and push to GitHub automatically - or only manually or certain branches. There are endless possibilities.

And as you pointed out Git itself gives you several advantages in the development process I've learned to appreciate. For instance if you're a core developer, you don't have to make your feature branch public, you can keep it in your local repository, rebase it onto the master branch and finally fast-forward merge it. You can use the "stash" to efficiently handle work-in progress changes, etc. But frankly merging is the only thing that *can* give you a headache in Git from time to time. This is probably workflow-related. (Plain) Git simply does not seem to imply a workflow with multiple stable version branches between which you exchange changesets and track their relationship. Although using "cherry-picking" something like that can probably be built on top of Git. However considering what I saw in the CVS Git-mirror, this will likely not be an issue with ChucK.

cheers, Robin

...
Does Ge have authority (or at the the persuasive skills) to make this happen? If not Ge, then whom?

- Rob

P.S.: I'm happy to help set up a public GitHub repository if that would help. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Robert Poor

5:29 p.m.

On Fri, Mar 23, 2012 at 13:30, Tomtom wrote:

...

Unfortunately, this discussion pops up every three months or so on this mailing list, and so far nothing has moved in this direction. I guess this is not a priority to the core devs, but it's their work, so the decision is in their hands.

Thus my original question: who is the person who could give the okay making this happen? Does it require anything more than Ge saying "make it so"? If not, this should be easy. - Rob

Spencer Salazar

5:59 p.m.

A few weeks ago I posted this to the less popular chuck-dev list (which is probably why a lot of people missed it): https://lists.cs.princeton.edu/pipermail/chuck-dev/2012-February/000431.html (quote) Hello, We recently (about 1 year ago) migrated the ChucK codebase to an SVN repository as an effort to streamline development, which it absolutely has done (compared to when it was in a stone-age CVS repository). At various times, such as now, we've felt leanings towards Git in the community, and while we are hesitant to play "technology tag", Git appears to be here to stay, and an effective tool for development. So at this point migrating to Git is something we are strongly considering and are likely to go forward with. spencer (+ ChucK team) (end quote) Right now our greatest priority is putting together the next ChucK release, which switching VCS systems will be a temporary but appreciable setback to. But once thats out of the way I think we will be a lot more open to it. spencer On Fri, Mar 23, 2012 at 2:29 PM, Robert Poor wrote:

...

On Fri, Mar 23, 2012 at 13:30, Tomtom wrote:

...
Unfortunately, this discussion pops up every three months or so on this mailing list, and so far nothing has moved in this direction. I guess this is not a priority to the core devs, but it's their work, so the decision is in their hands.

Thus my original question: who is the person who could give the okay making this happen? Does it require anything more than Ge saying "make it so"? If not, this should be easy.

- Rob _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Spencer Salazar

5:54 p.m.

Hey Robin! On Fri, Mar 23, 2012 at 8:37 AM, Robin Haberkorn wrote:

...

Hi!

I'm relatively new to ChucK. I knew it for some time but only now I start using it "seriously". I have a couple of questions and hope that you may answer them:

1) Does ChucK have a public source repository? (This question may be off-topic...)

You can check out the primary development branch using SVN, like so: svn checkout https://chuck-dev.stanford.edu/svn/chuck/trunk/ chuck Development has been moving kind of fast lately, so things might not totally be working/compiling on some platforms (e.g.Windows or Linux). This will likely get cleaned up in the next week or so, now that I have some free time to do so.

...

2) Is there a real bug tracker somewhere? I found the one in the wiki, but it is somewhat confusing...

ChucK has a "private" (to SVN committers only) bug tracker, which isn't that helpful, but which actually is only a recent addition. Having a public bug tracker is on our to-do list.

...

3) Is there a way to use multiple sound devices in one ChucK VM? I'm using chuck 1.2.1.3 on Linux-ALSA. It seems I have to specify the dac on the command line (--dacX). This could probably be used to start one VM per soundcard and exchange audio data via netout/netin. I will try this soon.

This is not currently possible.

...

However just out of curiosity, is multiple-dac support in one VM anticipated some time in the future?

Yes! For Linux we haven't encountered compelling use cases other than removing the need for two different binaries. But for Windows, switching between ASIO and DirectSound within the same binary seems pretty useful, so likely it will be straightforward to extend this capability to ChucK on Linux once the Windows version has it.

...

4) regarding netout/netin. This may also be useful for integration with other applications like Pure Data. Does anyone have experience with it or details about the protocol if there is any? If not I will have a look at it as soon as I need it and write a Pure Data external if necessary.

netin/netout is something of an ignored feature at the moment -- I sense a general interest in having working network audio xmitters, but network communication between ChucK and other audio/programming environments seems to be mostly confined to control-rate information, in which case OSC is sufficient.

...

5) I read about an Un-Chuck operator (=<). However it appears nowhere in the current docs. Is it still supported, or temporarily disabled?

Un-chuck is alive and well -- I believe this would be one of many shortcomings of the current set of documentation. You can use it to remove a UGen from the audio graph, and ensure that that UGen is no longer using up CPU cycles to generate/process samples. SinOsc s => dac; 1::second => now; // sound happens s =< dac; 1::second => now; // no sound!

...

6) In the "Developer Guide" I read something about OpenGL support. This was the only mention of OpenGL support I came across. I suppose if this really exists, it is a new development feature since v1.2.1.3 does not appear to posses any (undocumented) OpenGL API.

OpenGL support has existed in various incarnations, mostly as a result of various student projects, but has never been released officially as part of ChucK. How best to integrate graphics processing into ChucK is an open issue at this point, one in which we (ChucK team) are very interested in, but also don't necessarily know the answer to. spencer

...

Best regards, Robin Haberkorn

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Fernando Lopez-Lezcano

6:04 p.m.

On 03/23/2012 02:54 PM, Spencer Salazar wrote:

...

On Fri, Mar 23, 2012 at 8:37 AM, Robin Haberkorn wrote:

...
3) Is there a way to use multiple sound devices in one ChucK VM? I'm using chuck 1.2.1.3 on Linux-ALSA. It seems I have to specify the dac on the command line (--dacX). This could probably be used to start one VM per soundcard and exchange audio data via netout/netin. I will try this soon.

Quick comment: on Linux you could use Jack as the audio backend. If your soundcards are sample synchronous they can be concatenated into one ALSA virtual device and Jack can use that. Otherwise Jack (at least in version 1.9.x) also provides the alsa_in and alsa_out clients which can connect the main Jack engine to asynchronous soundcards doing resampling to correct for the slight differences in sampling rate.

...

...
4) regarding netout/netin. This may also be useful for integration with other applications like Pure Data. Does anyone have experience with it or details about the protocol if there is any? If not I will have a look at it as soon as I need it and write a Pure Data external if necessary.

On Linux, if the clients are on the same physical machine they can all be connected together without extra latency if Jack is used by all of them. Easy. You can even connect machines through the network using netjack. -- Fernando

Robin Haberkorn

31 Mar 31 Mar

6:59 p.m.

Hi Fernando! On 23/03/12 23:04, Fernando Lopez-Lezcano wrote:

...

On 03/23/2012 02:54 PM, Spencer Salazar wrote:

...
On Fri, Mar 23, 2012 at 8:37 AM, Robin Haberkorn wrote:

...
3) Is there a way to use multiple sound devices in one ChucK VM? I'm using chuck 1.2.1.3 on Linux-ALSA. It seems I have to specify the dac on the command line (--dacX). This could probably be used to start one VM per soundcard and exchange audio data via netout/netin. I will try this soon.

Quick comment: on Linux you could use Jack as the audio backend. If your soundcards are sample synchronous they can be concatenated into one ALSA virtual device and Jack can use that. Otherwise Jack (at least in version 1.9.x) also provides the alsa_in and alsa_out clients which can connect the main Jack engine to asynchronous soundcards doing resampling to correct for the slight differences in sampling rate.

yes, I was forgetting the difficulties in using multiple sound cards, although I should know. Of course I don't have clock-synced sound cards. Clock-syncing appears to be a pro-feature. For the price of two or more sound cards that can do this, I could probably buy one professional sound card that supports a sufficient number of input channels. I don't necessarily need more than two output channels but I could use more than the two input channels my built-in sound card provides. (I'd like to do "noise music" and need to process the input of multiple contact mics, my vinyl record player etc. It all has to be in real-time.) Unfortunately I *really* don't have the money to buy a $500 card but I am willing to sacrifice some audio quality and a little bit of latency, although I'd prefer adding the noise after digitizing :-) I was spending some time getting ChucK to work with JACK and two sound cards. It now works more or less. Unfortunately ChucK by default connects its output/input channels which somehow appears to prevent working with more than two input/output channels (if I enforce more channels using --in/--out - the number of channels displayed for the Jack device using --probe - the correct number of channels are displayed in the JACK connections which are properly set up according to my active JACK patch, there aren't any ChucK error messages but I still don't hear anything sent to any output channel). I had to apply the patch from this post: https://lists.cs.princeton.edu/pipermail/chuck-users/2010-October/005776.htm... disabling the max-number-of-channels check and channel/port autoconnections. It now works for me, all ports are connected by the Jack daemon according to my Jack patch. Frankly, I don't know why this did the trick. Any insights? Also, occasionally there are some clicks on the alsa_out-managed sound card (a cheap lo-fi USB model). Perhaps it would work better if it only had to synchronize between sound cards of the same model? Getting this to work seems like Voodoo science to me. btw. I read that PulseAudio can aggregate sound cards as well, doing resampling in a similar manner as Jack's alsa_in/out clients. Haven't tried it and it would be more difficult to use with ChucK which doesn't have a PulseAudio driver. btw. From time to time in discussions about sound card clock drifting, some people point out that it could be possible to sync some identical sound cards by doing some hardware hacking (use one master sound card's clock for several sound cards). Does anyone have any experience with this? Is it even possible with USB sound cards? I'd be happy to give it a try if I had some instructions.

...

...
...
4) regarding netout/netin. This may also be useful for integration with other applications like Pure Data. Does anyone have experience with it or details about the protocol if there is any? If not I will have a look at it as soon as I need it and write a Pure Data external if necessary.

On Linux, if the clients are on the same physical machine they can all be connected together without extra latency if Jack is used by all of them. Easy. You can even connect machines through the network using netjack.

Yes, JACK appears to be well suited for this task as well. The only downside appears to be is that all input/output channels used by chuck must be addressed by number. cheers, Robin

...

-- Fernando _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Robin Haberkorn

24 Mar 24 Mar

10:46 a.m.

Hello Spencer! On 23/03/12 22:54, Spencer Salazar wrote:

...

Hey Robin!

...

You can check out the primary development branch using SVN, like so:

svn checkout https://chuck-dev.stanford.edu/svn/chuck/trunk/ chuck

Development has been moving kind of fast lately, so things might not totally be working/compiling on some platforms (e.g.Windows or Linux). This will likely get cleaned up in the next week or so, now that I have some free time to do so.

this is just what I was looking for. Thanks! Btw. current SVN compiles fine on my $ uname -a Linux nb005-lx001 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux using -m32 of course but sample programs crash with badalloc exceptions. Looking at the backtrace it seems it tries to allocate an obscene amount of "SAMPLE"s. Haven't looked any further into this; and I don't need it at the moment - just wanted to give it a quick try. btw. ChucK dracula is compiled with -m32 on my machine and I haven't found any bug I could blame on that. After all it should be built as a true 32-bit application. one remark about the build system (ok this is truly off-topic in chuck-users...): * CHUCK_DEBUG should add -O0 and -O flags should be removed from the platform specific makefiles (only the last -O on the gcc command line counts) cheers, Robin

...

...
2) Is there a real bug tracker somewhere? I found the one in the wiki, but it is somewhat confusing...

ChucK has a "private" (to SVN committers only) bug tracker, which isn't that helpful, but which actually is only a recent addition. Having a public bug tracker is on our to-do list.

...
3) Is there a way to use multiple sound devices in one ChucK VM? I'm using chuck 1.2.1.3 on Linux-ALSA. It seems I have to specify the dac on the command line (--dacX). This could probably be used to start one VM per soundcard and exchange audio data via netout/netin. I will try this soon.

This is not currently possible.

...
However just out of curiosity, is multiple-dac support in one VM anticipated some time in the future?

Yes! For Linux we haven't encountered compelling use cases other than removing the need for two different binaries. But for Windows, switching between ASIO and DirectSound within the same binary seems pretty useful, so likely it will be straightforward to extend this capability to ChucK on Linux once the Windows version has it.

...
4) regarding netout/netin. This may also be useful for integration with other applications like Pure Data. Does anyone have experience with it or details about the protocol if there is any? If not I will have a look at it as soon as I need it and write a Pure Data external if necessary.

netin/netout is something of an ignored feature at the moment -- I sense a general interest in having working network audio xmitters, but network communication between ChucK and other audio/programming environments seems to be mostly confined to control-rate information, in which case OSC is sufficient.

...
5) I read about an Un-Chuck operator (=<). However it appears nowhere in the current docs. Is it still supported, or temporarily disabled?

Un-chuck is alive and well -- I believe this would be one of many shortcomings of the current set of documentation. You can use it to remove a UGen from the audio graph, and ensure that that UGen is no longer using up CPU cycles to generate/process samples.

SinOsc s => dac; 1::second => now; // sound happens s =< dac; 1::second => now; // no sound!

...
6) In the "Developer Guide" I read something about OpenGL support. This was the only mention of OpenGL support I came across. I suppose if this really exists, it is a new development feature since v1.2.1.3 does not appear to posses any (undocumented) OpenGL API.

OpenGL support has existed in various incarnations, mostly as a result of various student projects, but has never been released officially as part of ChucK. How best to integrate graphics processing into ChucK is an open issue at this point, one in which we (ChucK team) are very interested in, but also don't necessarily know the answer to.

spencer

...
Best regards, Robin Haberkorn

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

4481

Age (days ago)

4489

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Fernando Lopez-Lezcano
Robert Poor
Robin Haberkorn
Spencer Salazar
Tomtom