Aurélien Bondis wrote:

...

for part 1) I don't really know.

Yes, it is a problem. Or an advantage, per your point of view regarding Free Software.

...

2) don't know about it's future, but I just discovered it and found it really easy to use (for my needs), tried PD before but was too complicated for meeting. So I wish chuck to live long :)

I would like to see for ChucK an embedded library similar to libpd

https://github.com/libpd

I can only speculate that such already exists and is the audio engine behind Smule iOS apps

http://www.smule.com/

Or perhaps the Smule technology is more similar to that of MoMu: A Mobile Music Toolkit

http://momu.stanford.edu/toolkit/

In any case, Ge's colleagues and students are doing cool stuff. :)

I would also want to integrate Audiobus for iOS; still waiting for access to the SDK though.

http://audiobus.tumblr.com/

...

3) I use chuck on a Raspberry Pi. It works well but I'm not sure about realtime or anything. I was not able to make jack work with the RPi so I just use ALSA for now, so maybe more latency then possible. Archlinux for ARM has chuck ready to use for ARM procs. Also, I use python to make the bridge between GPIOs and send OSC events to my chuck running on localhost, had no issues. My whole thing uses 34MB of RAM and about 40-50% CPU, not realtime but responsive enough for my needs.

That is one of the best things I've heard. Does the Raspberry Pi support USB class audio in/out? I do use a USB sound card with it, a Behringer 302USB, it even powers

On Wed, 05 Dec 2012, Michael Heuer wrote: the sound card, which also powers the phantom power needed for my mic. I get a good clear recordings, but for now I can't figure out why the output has so much noise (sounds like it's picking some interferences or clock or ...?). But the drivers are here yes, but maybe not for all the cards :) A.

michael

...

On Wed, 05 Dec 2012, Rob Fielding wrote:

...

I am using ChucK on an x86 based Windows8 large multitouch screen; as nothing more than a way to create a multi-voice OSC synth that I can describe to users how to install (at minimal cost) and get setup (with little expertise on their part). But Windows store apps (ARM, sandboxed - like on iOS), forces generally conspire to have you try to embed everything into a monolithic process. So:

1) The GPL licensing (SuperCollider as well as ChucK) seems to be an issue for anyone trying to host ChucK embedded into a controller process. Is this an actual problem, given that we are generally just linking in unmodified build of the sources?

2) What is going on with the future of ChucK? After tinkering around with the options for making an OSC synth to match my controller: 1) visual spaghetti code (Pd), 2) An ugly language in wide use (SuperCollider) 3) Hard (CSound) 4) Nice but not well known (ChucK).

3) Performance. I saw Ge Wang say that performance isn't a priority for ChucK, but have no idea what the practical implications are. Will there be (and do there need to be) target specific optimizations to take advantage of SIMD, and other ways of meeting performance goals, especially in the more constrained ARM environments?

I haven't tried to do an ARM build of ChucK and get it installed onto Surface, but I read that you can't in general freely communicate between processes on localhost for store apps anyway (ie: OSC over UDP localhost); so that leads back to the problem hosting ChucK as an embedded library.

-- http://www.youtube.com/rrr00bb http://rfieldin.appspot.com http://rrr00bb.blogspot.com

---

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

This licence thing is a very tuff subject, indeed! I wish the world were easier!! ----- A bit of OT ----- I must say your point of view of Supercollider is completed mistaken. Its not cause most of the code you find is ugly, that the language is ugly. Actually from all the languages you were able to link in your email, SuperCollider is probably the one that lets you do the most beautiful code, its all about how capable you're. good luck On 5 December 2012 22:24, Kassen wrote:

On Wed, Dec 05, 2012 at 02:51:58PM -0500, Rob Fielding wrote:

...

1) The GPL licensing (SuperCollider as well as ChucK) seems to be an issue for anyone trying to host ChucK embedded into a controller process. Is this an actual problem, given that we are generally just linking in unmodified build of the sources?

IANAL, this is not legal advice, I don't represent the ChucK team on this matter.

As long as your controller process has a compatible license and you also share the code all should be fine. If not there may be a problem but I think that only starts to matter when you would distribute the combined work. Between GPL-ed programs you can freely borrow/port. That is very convenient for those projects.

If that is not practical for you I think you can legally have your closed source program communicate with ChucK, redistribute ChucK with your program and add the ChucK source to that.

What you can not do is take GPL software and use it as a part of your closed project, then sell or otherwise redistribute the result without the source. If that is what you want/need something like PD which has a far more liberal license might be what you are after. Personally I like the GPL, I think it encourages a kind of sharing that benefits all. Evidently many other people, like some groups developing stuff for mobile devices enjoy borrowing PD's source which PD's BSD licence allows.

You should probably consider what your needs are with regard to distribution, how closely coupled the synthesis engine and the controlling process need to be and where you stand on this kind of sharing here. If in doubt after a closer reading of the GPL you might want to consult a lawyer. I'd avoid a legal fight, both because those are no fun and because ChucK comes from Princeton and Stanford.

I hope that clarified things a bit and that I didn't misrepresent something. I also hope you will make a Free/Open instrument, I think sharing is fun, but that is up to you and might not be practical in your situation.

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

...

This licence thing is a very tuff subject, indeed! I wish the world were easier!!

I think it actually makes it as easy as it will get. Licences give you extra options. Sure; options under certain conditions, but they are options that would not otherwise be there.

indeed.

...

----- A*bit of OT*-----*

Yeah, sorry for talking about SC here.

...

I must say your point of view of Supercollider is completed*mistaken. Its not cause most of the code you find is ugly, that the language is ugly. Actually from all the languages you were able to link in your email, SuperCollider is probably the one that lets you do the most beautiful code, its all about how capable you're.

Sorry, you lost me for a moment. Did I say that? SC took a bit of a "kitchen-sink" approach to syntax; giving many options for many things. That -I am sure- is really cool if you'd like to write "poetry" in it,

yeah my goal is always to write beautiful poems. and am sure if you're a coder that is able to write readable code, supercollider will allow you more than one way to do that. bad for beginners, great for coders. I remember when i started chuck everything simply work - i was very impressed - everything was super accurate, was the oposite of my beginning with supercollider where i barely new if i was dealing with BEATS / MINUTES / SECS. But after a few weeks ( ok, not a few, some weeks ) i got my head around it, and now i know how to do accurate and not accurate clocking :P

I also gather it can be confusing if you are a novice and would like to find the common ground between 5 examples by

yeah that sucks big time, the documentation weren't very friendly until few versions ago. Supercollider learning curve is definitely bigger ( way bigger ) than chuck, in the other hand there's way more documentation to be read and way more code to be used.

different authors. It does take a lot more from functional programming which I agree often leads to beautiful code. Then again I find a certain beauty in ChucK's tendency to be straightforward and sometimes a bit blunt too.

I really love chuck, and i think the way it makes possible to create and re-chain channel strips is a must! super sexy! loads of claps for chuck! The only problem for me was when i started creating my classes and dealing with events i started having some limitations which lead me to come back to supercollider, where classes, inheritance and other syntax things gives my extremely OO ideas a better housing. Also the extensions in SC ( Quarks ) make it very easy to share code, maybe we should look on making something for chuck. Something like "brew for chuck" ? Am sure a quick solution can be written using node.js + GIT

You can get ugly or beautiful in any language. I swear I even saw readable Perl once ;-)

Don't get me wrong, am with you ( completely with you ) And I think chuck is super sexy and i would love to keep chucking. I would love to help on improving the syntax and OO, and all that jazz. But unfortunately i had to prioritise my idea over digging chuck source code. Hopefully at some point i'll be able to convert my SC classes to chuck ( : peace

The class system is primitive and known to be so, that's true. I'm not sure I understand what issue events have for you though I suspect the shreduler could be optimised.

me neither, i don't remember exactly which problem i had with classes, but i do remember at some point i was "work-arounding" not in a comfortable way

...

Also the extensions in SC ( Quarks ) make it very easy to share code, maybe we should look on making something for chuck.* Something like "brew for chuck" ? Am sure a quick solution can be written using node.js + GIT *

Aside from lacking wide-spread adoption, do you see issues with the current idea of ChuGins and Git?

i missed that, and it looks awesome. actually using GIT is fantastic, quarks on SC still using SVN and that isn't very handy.

...

Don't get me wrong, am with you ( completely with you ) And I think chuck is super sexy and i would love to keep chucking. I would love to help on improving the syntax and OO, and all that jazz. But unfortunately i had to prioritise my idea over digging chuck source code. Hopefully at some point i'll be able to convert my SC classes to chuck ( : peace

I hope so too :-)

( :

Take care, Kas.

you too! cya

There's a few GIT GUIs around: http://git-scm.com/downloads/guis And whoever uses linux is able to user the terminal, so its fine ( : On 21 February 2013 21:03, Kassen wrote:

On Thu, Feb 21, 2013 at 01:01:44AM +0000, henrique matias wrote:

...

me neither, i don't remember exactly which problem i had with

classes, but

...

i do remember at some point i was "work-arounding" not in a comfortable way*

When you next run into it; document the issue and send it here, please. As anyone is DSP knows; feedback is effective ;-)

...

i missed that, and it looks awesome. actually using GIT is fantastic, quarks on SC still using SVN and that isn't very handy. *

Yeah, I think it's a good idea. It should make working together and improving each other's work a lot more convenient. GIT, when it works, can be quite a social tool. It's also nice how GIT is powerful but still simple to use for common basic purposes. Not sure whether it has a convenient solution for people who don't like terminals. I imagine that in a while we'll simply include some pre-compiled useful ChuGins with the binary download. If you are building from source you are probably using the terminal already anyway.

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