electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » ChucK programming language
ChucK - unique sound design and livecoding capabilities?
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [15 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
Rinko



Joined: Jun 03, 2008
Posts: 38
Location: UK

PostPosted: Tue Jun 03, 2008 3:27 am    Post subject: ChucK - unique sound design and livecoding capabilities? Reply with quote  Mark this post and the followings unread

hello all

i have recently posted a thread on the nabble supercollider forum http://www.nabble.com/supercollider---unique-sound-design--to17587420.html#a17619563.
the members there were very helpful and suggested look into ChucK as a medium.

i am wondering if anyone can answer a few general questions i have about ChucK please:

-can i use it to create sounds and music that couldn't be made in any other way? i.e. is it a unique tool?
-is it really as flexible as 'create anything you want'? (Julian Rohruber suggested this was an outdated concept and that "every system orients" on the Nabble SC forum but i would still be interested to see what you think)
-what are the benefits of using ChucK to livecode over SC for example?
-what are the drawbacks of using minaudicle? is it less flexible or powerful than using ChucK 'raw' in terminal?
-how do you create your own ugens?

i am particularly interested in synthesizing drums and want a medium which allows me to create livecode unique sounds in algorithmic composition/performance- the type of stuff i can imagine but haven't realised yet.

i have searched the forum and got a good overview of ChucK (as well as answers to my other questions) but would appreciate any respones to these questions in particular.

i have very little coding experience but being able to create unique sounds is vital to me.

thank you for your time.

Last edited by Rinko on Tue Jun 03, 2008 3:53 am; edited 1 time in total
Back to top
View user's profile Send private message
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Tue Jun 03, 2008 3:50 am    Post subject: Reply with quote  Mark this post and the followings unread

For me, basically, ChucK is not that overall-flexible comparing to some other audio programming language like SC, CLM, csound etc..
(and each one still has different strong points or suitability for certain kinds of jobs)

I guess the unique sound you're after might be in the algorithm of the unit generators or calculations available in each languages.
For ChucK, we've got quite basic tools to use,
and some are derived from other available system (for example, STK)

So for me, the uniqueness of ChucK is not that strong comparing to other systems.
I see that there are more important things that is strong in ChucK,
It's the readability and ease of prototyping,
It takes quite a few lines of code to produce quite a complex system
but with a code that is very human-readable.

With this special advantage, comparing to some other languages with tough learning curve,
ChucK is 'fun to learn' especially from the beginning.
And with only some basic knowledge from the tutorial,
you can start experimenting with different ideas easily.
There are less needs to worry, so it can suddenly bring out the creavity from fun of playing with ChucK while learning.

And with this chance to enhance experimentibility & creativity,
I guess you can even create your own 'unique sound' quickly by just practicing basic ChucK features.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Rinko



Joined: Jun 03, 2008
Posts: 38
Location: UK

PostPosted: Tue Jun 03, 2008 4:02 am    Post subject:   Reply with quote  Mark this post and the followings unread

interesting, kijjaz - thank you!

ease of prototyping on ChucK was mentioned to me by the SC users and appeals to me as I'd like to be able to jam with my chosen system as easily/intuitively as possible - guess there has to be a payoff somewhere though.

do you think that ChucK could develop to be more flexible whilst maintaining its ease of readibility, ease of prototyping and less severe learning curve?

any other comments most welcome Very Happy
Back to top
View user's profile Send private message
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Tue Jun 03, 2008 4:30 am    Post subject: Reply with quote  Mark this post and the followings unread

We'll have some more bugfixes and features very soon on the next release ^_^

There are still many things that can make ChucK more flexible,
for example, data types and data storage. -->
for now, we can't make lists just like in some languanges (lisp/scheme)

but actually we can borrow some features ChucK doesn't have
(or won't be having) from other languages but have them work together by some way of communications..
OSC (Open Sound Control), MIDI, ..

Now we can't do much with file reading/writing in ChucK also,
so I'll wait for the next versions to support that.
That will make it cooperate with external tools better.

There is also another thing ChucK still lacks.
The communication between running threads (called shreds in ChucK) is not that flexible.
- - -

If you need the flexibility from another system,
maybe you can try building a running ChucK instant that is the sound synthesis server,
and have other systems send in OSC (or MIDI if you're still with MIDI) to control / create events in ChucK.

That might fills the gap also.
I haven't done much in that,
mosty when I control from outside,
I use MIDI / USB Joystick / Puredata to trigger event / send in MIDI values.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Tue Jun 03, 2008 4:50 am    Post subject: Reply with quote  Mark this post and the followings unread

Additional answers to the questions:

[ using chuck command-line vs. miniAudicle ]
I usually work in miniAudicle for the ease of code-editing and adding/removing/replacing shreds.
Normally I can open many windows of codes together and choose to add anything into the VM as I desire,
that's quite easy to do because it requires only a few clicks to add it in time,
(nice for live performance: easy to create new code, edit, add/remove)

but the command-line system might be of a very nice use this way:
for having it a server for other languages or sricpting languages or application to contact with.

adding ChucK shreds this way might need the ChucK code to be in a .ck saved file
(unless you're running a ChucK shell that you can type in codes
or copy and past codes and run instantly)
so it might not be convenient if you still have to edit or start codes,

It'd be convenient if all you need is all in .ck ready to start and let it run.
- - -

[ creating your own Unit Generators ]
For now, the easiest way to do is to create a class,
and the class create some connections or calculations needed to produce/process inputs.

One way I do a lot of this is by:

class MyGenerator
{
Gain input; // if it should have input(s)
Gain output; // if it should have output(s) ... normally it should
// (except it do some other things e.g. control other things but not generating audio signals)
// Connect things to 'output'

// do some initializations

// or any loop if it has to work with a looping module

// and define some functions for controlling this UGen
}

when created as an instant,
I have to connect only to its .input or connect out from its .output,
that's almost as simple as using basic UGens in ChucK.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Tue Jun 03, 2008 8:17 am    Post subject: Re: ChucK - unique sound design and livecoding capabilities? Reply with quote  Mark this post and the followings unread

Rinko wrote:

i am wondering if anyone can answer a few general questions i have about ChucK please:


I'll give it a go as well, if you& Kijjaz don't mind :¬).


Quote:
-can i use it to create sounds and music that couldn't be made in any other way? i.e. is it a unique tool?


This is both a easy and a hard question. It's easy in that ChucK is Turing-complete; any sound that is computational should be creatable in ChucK (given a unlimited computer and unlimited time.... and I'm not mathematically proving it :¬) ). In other words; there is no tool that could generate a wave file that couldn't be generated by ChucK as well. There is nothing unique about this, Csound, SC and any number of other systems could make the same claim.

ChucK's uniqueness isn't in this; it's in the syntax which is meant to be very readable expressive and relatively easy to get into. There definitely are things that are very convenient in ChucK compared to other systems, particularly sample-accurate timing across concurrent processes.


Quote:
-is it really as flexible as 'create anything you want'? (Julian Rohruber suggested this was an outdated concept and that "every system orients" on the Nabble SC forum but i would still be interested to see what you think)


I agree with Julian. It very much depends on what you want to create and I particularly agree that like any system ChucK can orient you in a certain direction. I don't see this as something bad in the slightest, in fact I experience the way ChucK "orients" me as positively inspiring. ChucK very much changed my perspectives on music and to some degree on sound. I couldn't easily think of a thing you couldn't create at all though.

Quote:
-what are the benefits of using ChucK to livecode over SC for example?


I don't have any SC livecoding experience so I'm not sure I'm qualified to answer this.

Quote:

-what are the drawbacks of using minaudicle? is it less flexible or powerful than using ChucK 'raw' in terminal?


Hardly any. The "raw" terminal will still need a external text editor (unless you are happy with the "shell" but I wouldn't do that). With the Mini you get the convenience of hotkeys, etc. In the terminal it could potentially be easier to integrate your code with Bash or batch programming. For larger long-term projects I use a more mature editor (notepad++) for the more powerful search&replace features, etc and in non-livecoding performance I use the terminal because I don't want to be distracted by seeing the code but aside from that I use the Mini.

Quote:
-how do you create your own ugens?


The brutally straightforward answer is; you write them in C++, link them to the source of ChucK and recompile it.

The more roundabout one; Right now you can't write new Ugens in ChucK itself as such though you can write classes that act like Ugens to a certain extend.

The yet more roundabout one; we need a solution for that and this is on The List.

Quote:
i am particularly interested in synthesizing drums and want a medium which allows me to create livecode unique sounds in algorithmic composition/performance- the type of stuff i can imagine but haven't realised yet.


Both ChucK and SC would be fine for this. While you can be affected by factors like SC's relative maturity or CK's greater cross-platform compatibility I honestly think you're best off picking the one that has the most intuitive syntax to you.

Quote:
thank you for your time.


:¬)

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Tue Jun 03, 2008 10:49 am    Post subject: Reply with quote  Mark this post and the followings unread

Thanks Kassen!
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Frostburn



Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9

PostPosted: Tue Jun 03, 2008 1:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

Rinko wrote:
i am particularly interested in synthesizing drums...

Drums are though to synthesize. I've tried to approach them from many directions with different synthesizing techniques but I haven't come up with anything particularly good nor realistic... The good thing is that it has always been easy to implement the technique in ChucK.
I wish you good luck with this and don't be afraid to ask if you get stuck. Smile

_________________
To boldly go where no man has bothered to go before.
Back to top
View user's profile Send private message
Rinko



Joined: Jun 03, 2008
Posts: 38
Location: UK

PostPosted: Wed Jun 04, 2008 2:30 am    Post subject:   Reply with quote  Mark this post and the followings unread

cheers guys, thank you for your help!

some interesting ideas and useful info here.

kijjaz - interesting thoughts on hookin ChucK up with other programs, perhaps it will be useful/necessary at some stage but to be honest i would prefer to keep my setup as simple as possible - one of the biggest lessons i have learned about myself is that i have more fun and am more productive with a limited setup that i understand well, i am currently in the process of getting rid of my mpc, fx pedals and cheap drum machines and keyboards because i just don't use or enjoy using them


frostburn - thank you for the encouragement as well. i'm not too fussed about 'realistic' drum sounds per se, my personal interest lies in creating something uniquely digital. i'm thinking fm synthesis, granular synthesis, wavetable synthesis etc. but i'm lookin forward to the challenge of making the sounds in my head Cool

i'm gonna take kassen's advice, try both sc and ChucK and see which has the most intuitive syntax.

cheers!!!

Very Happy
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Jun 04, 2008 2:41 am    Post subject: Reply with quote  Mark this post and the followings unread

Rinko wrote:

i'm gonna take kassen's advice, try both sc and ChucK and see which has the most intuitive syntax.


Very wise. There are many smaller and larger differences between SC and CK but I feel that's the one based on which a choice should be made; pick the instrument you enjoy playing most.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Wed Jun 04, 2008 5:53 am    Post subject: Reply with quote  Mark this post and the followings unread

I think the environment's structure is more important than syntax. Syntax reflects structure to an extent, but -- comparing sc2 vs sc3 (for example) reveals only very small syntax differences (sc3 has more "syntactic sugar" but very little has changed in the compiler), yet the synthesis architectures are completely different animals. I would have struggled against sc2's structure, but fortunately switched to sc3 pretty early and found its structure in right in line with my thinking.

In the sc3 vs ChucK decision, the recent thread about how to do polyphony explains in a nutshell one of the main reasons why I prefer supercollider. Kijjaz illustrated well how to play a series of three note chords, but what if the chords are sometimes 3, 4, 5, 6 or 7 notes? From that explanation, it seems to me that in ChucK you would have to launch enough UGens for the maximum number of notes, and silence the ones that you don't need (which is inefficient, when UGens are being processed that are not heard). But in supercollider, it's ridiculously simple -- the SynthDef plays one note, and you just instantiate as many Synth nodes as you need at any given time. When a note is over, its Synth is removed from the audio chain and no longer consumes CPU. And what about notes that start at different times and then overlap (also very common in my work)?

Even if I preferred ChucK's syntax (which is not a big deal to me -- I never exactly hated the C/Java hegemony, but never had a strong attachment to it either), ease and efficiency of spawning Synths is critical to the way I work and think. I choose the tool that lets me do that the best -- syntax is secondary.

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Jun 04, 2008 6:24 am    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:
From that explanation, it seems to me that in ChucK you would have to launch enough UGens for the maximum number of notes, and silence the ones that you don't need (which is inefficient, when UGens are being processed that are not heard).


You could also disconnect them from the chain; disconnected Ugens aren't "ticked" and hence take no CPU. This is a inherent benefit of the "pull through" model that determines the order of calculation of the Ugens.

Quote:
But in supercollider, it's ridiculously simple -- the SynthDef plays one note, and you just instantiate as many Synth nodes as you need at any given time. When a note is over, its Synth is removed from the audio chain and no longer consumes CPU.


Yes, you could do exactly that. The reason why it's typically not done in ChucK right now is that while you can easily free the CPU of no longer used/ unused voices (regardless of whether you recycle voices or spawn a new one for every note) you can't -yet- free the used memory again. Without garbage collection it's at the moment typically a good idea to try to write code that doesn't generate any garbage at all.

Personally I'm not very fond of the typical "MIDI" way of dealing with voices and polyphony because continually flushing the data of used voices leads to a sort of "stateless" instrument, or at least one without a memory of it's state... but you can.

Quote:
And what about notes that start at different times and then overlap (also very common in my work)?


Well? what about them? I don't see the slightest issue there. You could tell a voice it's duration at the start or reference them somehow and tell them to stop playing. The way in which you do that would obviously depend on the structure of your program and/or your composition but once you know those this isn't a hard thing to do at all.

Quote:

Even if I preferred ChucK's syntax (which is not a big deal to me -- I never exactly hated the C/Java hegemony, but never had a strong attachment to it either), ease and efficiency of spawning Synths is critical to the way I work and think. I choose the tool that lets me do that the best -- syntax is secondary.


Spawning a voice in ChucK is as simple as sporking a function or maybe even instantiating a class or sending some message to one location in a array of "voice" objects... I don't think this is particularly different though the underlying issue of garbage collection of memory is indeed a significant difference.

I completely agree (and so does Ge, I think) that we urgently need garbage collection of memory but to me that doesn't weigh more then sample (and lower, if needed) accurate timing across a single abstraction level with a syntax I like. If your needs are different then yes; I can completely see going with SC; for many people SC will obviously make a lot of sense as a choice.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
dewdrop_world



Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4

PostPosted: Wed Jun 04, 2008 9:39 am    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
You could also disconnect them from the chain; disconnected Ugens aren't "ticked" and hence take no CPU. This is a inherent benefit of the "pull through" model that determines the order of calculation of the Ugens.


OK, cool, I didn't realize you could do that. Can you reconnect them on demand? If so, that would be an OK solution for me.

Quote:
Personally I'm not very fond of the typical "MIDI" way of dealing with voices and polyphony because continually flushing the data of used voices leads to a sort of "stateless" instrument, or at least one without a memory of it's state... but you can.


Interesting -- what aspects of the instrument's state do you want to preserve?

In SC, you can have a group of Synth nodes that work together to act like an instrument, where some of them could be active per-note only while others persist. It would be possible to have note-based oscillators but a separate, continuous resonating body attached, for instance.

Quote:
Quote:
And what about notes that start at different times and then overlap (also very common in my work)?


Well? what about them? I don't see the slightest issue there.


The point is not that this is impossible in ChucK -- obviously that would be a silly thing for me to say. My point is just that it's more difficult, and it's something that's important to me so I use the tool that makes it as easy as falling down the stairs.

Quote:
I completely agree (and so does Ge, I think) that we urgently need garbage collection of memory but to me that doesn't weigh more then sample (and lower, if needed) accurate timing across a single abstraction level with a syntax I like. If your needs are different then yes; I can completely see going with SC; for many people SC will obviously make a lot of sense as a choice.


I could make a case that a single abstraction layer can just as easily obfuscate some things even as it clarifies others - the point being that it's a matter of preference more than an inherently better or worse way of representing synthesis.

James

_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net
Back to top
View user's profile Send private message Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Jun 04, 2008 10:26 am    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:

OK, cool, I didn't realize you could do that. Can you reconnect them on demand? If so, that would be an OK solution for me.


Yes, any Ugen that can be referenced at all (ie; it's garbage or the victim of sloppy programming) can be connected to any other Ugen that has a input at any time (and that can be referenced from the same scope).

This is cool for on the fly re-routing or saving CPU or whatever. The ChucK operator as referring to Ugen chains just means "connect", it's not limited to the moment when the Ugens are constructed. You could for example define a whole modular synth worth of Ugens in a single public class, fire that off and spend you time re-wiring them in code if you'd like. That might be a interesting way to perform, actually. Unused Ugens will be there and will take memory but not CPU.

Aside from scope in addressing Ugens and code are really very independent from eachother.

Quote:

Interesting -- what aspects of the instrument's state do you want to preserve?

In SC, you can have a group of Synth nodes that work together to act like an instrument, where some of them could be active per-note only while others persist. It would be possible to have note-based oscillators but a separate, continuous resonating body attached, for instance.


Well, lately I've been very interested in the state of the whole instrument, particularly in how it relates to the interface (and what has lately happened there) and making sure future notes are affected by what happened in the past. I'm not really sure where that Idea will go but it has been nagging me for a while now and throwing all info away at the end of each note seems wasteful to me. We could, of course, extract relevant info from a voice at the moment right before we free it. This would look roughly like the kind of thing you just outlined.

Voice-cycling in the traditional sense is very efficient but I've become more and more interested in relatively simple instruments and focussing on expressiveness instead of having many voices (etc). This was -of course- purely a side note and not really that relevant to the environments of SC and CK.


Quote:

The point is not that this is impossible in ChucK -- obviously that would be a silly thing for me to say. My point is just that it's more difficult, and it's something that's important to me so I use the tool that makes it as easy as falling down the stairs.


I don't think overlapping notes with different start times is harder. Assuming we have to set up a "instrument" anyway and have some way of either sending a "note on" with a "duration" parameter or later send a "note off" anyway then overlapping notes aren0t harder then chords or single notes or whatever.

Of course creating this in a way that generates no garbage means some overhead in code but from there on the musical structure used wouldn't add complexity beyond the complexity of the music itself. For shorter pieces I might simply say "damn the garbage" and do it your way for convenience. I predict that way will become a lot more popular with garbage collection; likely people will start implementing voices as sporked functions and defining Ugens within those, letting the Ugens be collected once the function has served it's task.

Quote:

I could make a case that a single abstraction layer can just as easily obfuscate some things even as it clarifies others - the point being that it's a matter of preference more than an inherently better or worse way of representing synthesis.


Yes, absolutely. IMHO it's the responcibility of the individual programmer to structure his code (and his thoughts!) appropriately if he needs to use both DSP and music level code within the same file at the same level. I feel it's good that you *can*, that doesn't mean you *should* (at least not carelessly) but it can be very pleasant. For example with grains you can easily have structures or instruments that are on the border between musical events and elements of a DSP process and there this can be quite pleasant.

You can write hard to read code in any language, after all, and you'll need to make structural choices anyway. I agree there is no one "better" way but like I said; I like having the option open wherever it makes sense to me.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Frostburn



Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9

PostPosted: Wed Jun 04, 2008 1:43 pm    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
For shorter pieces I might simply say "damn the garbage" and do it your way for convenience. I predict that way will become a lot more popular with garbage collection; likely people will start implementing voices as sporked functions and defining Ugens within those, letting the Ugens be collected once the function has served it's task.


I actually built a few instruments around the concept of sporked voices and unlimited polyphony. Works well when I'm just playing with my MIDI keyboard but the memory fills up and I have to restart once in a while... I think I'll wait for garbage collection, include files and file I/O before I try to make anything grand. Maybe I'll try my hands at making minimalist and expressive pieces for now.

_________________
To boldly go where no man has bothered to go before.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [15 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use