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 
go to the radio page Live at electro-music.com radio 1 Please visit the chat
poster
 Forum index » DIY Hardware and Software » ChucK programming language
first code from scratch!
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [12 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
Low Note



Joined: Jul 20, 2007
Posts: 146
Location: New Jersey
Audio files: 2

PostPosted: Wed Aug 15, 2007 4:16 pm    Post subject: first code from scratch!
Subject description: simple pan
Reply with quote  Mark this post and the followings unread

Code:
SinOsc a => Gain q => Pan2 s => dac;
-1 => s.pan;
0=> a.gain;
.6 => q.gain;
.005::second => dur t;

// Pan from left to right, then reset full left
while (true) {
if (s.pan() == 1){
    t => now;
    s.pan() -2 => s.pan;}
else {t => now;
    s.pan() + .001 =>s.pan;}
   
// volume taper to eliminate pop
// when pan resets from right to left
if (s.pan() > .8) {
        a.gain() -.003 => a.gain;}
    else {a.gain() + 0 => a.gain;}
if (s.pan() < -.8){
       a.gain() +.003=>a.gain;}
      else {a.gain() + 0 => a.gain;}}


I'm been trying to troubleshoot something in this shred for about a half hour. As the sound gets near the very end of the panning sweep, i hear something that sounds like digital distortion. A little buzzing noise. I'm trying to get rid of that. Also, I can still hear the pop to a little degree as it jumps back over. Any idea how I might be able to get rid of either of these?

Next task is to get it to signal back and forth. I'm going to try another method though for that and see if I can employ and oscilator to do the work. I want to try these If statements for this, though.

I'm starting to have fun!
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


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

PostPosted: Thu Aug 16, 2007 5:10 am    Post subject: Re: first code from scratch!
Subject description: simple pan
Reply with quote  Mark this post and the followings unread

Low Note wrote:

I'm starting to have fun!


Excelent!

I'm getting the impression you'd like to experiment yourself so I won't spoil that fun. Feel free to ask questions if you would get stuck.

_________________
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: Thu Aug 16, 2007 5:19 am    Post subject: Reply with quote  Mark this post and the followings unread

Wow.. this one is cute and smooth algorithm for calculating this..
Hmm.. I'll check more with this digital sound issue..

What if you change .005::second => dur t; ?
Would that change the quality of that digitized sound?

The more "Control Signal Update Frequency", the more smooth it'd sound..
and in this example, when the gain is rising and falling,
there is actually a little artifact from the control rate.
I guess if you can make control rate more
(For example.. the more extreme case: use 1::samp => dur t;

(but you might have to make the value you're adding to pan and gain smaller too!)
It'd be smoothest.

I'll try to find out soon, I'm without a big audio monitor now hahah.

but Audacity's spectrum analyser surely shows that there are audible artifacts
(kinda like FM sound)
when the gain is changing rapidly.

keep fighting!
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
dewdrop_world



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

PostPosted: Thu Aug 16, 2007 2:20 pm    Post subject: Reply with quote  Mark this post and the followings unread

Isn't there a way to have the parameter change interpolate over the duration that gets chucked into now?

Seems kind of inefficient to force the user to keep rolling the control rate faster and faster. (In SuperCollider, a control rate signal that's controlling the input of an audio rate UGen is automatically interpolated over the block size.)

Sorry I don't know... not a ChucK user myself, but I'm definitely an interested observer.
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: Thu Aug 16, 2007 4:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

Yes and no...

In this case it can be done a lot more efficiently, including interpolation but that's because in this case we are dealing with a pan and you can make a pan out of two "Gain"s and Gain's can act as a VCA. in general no; you can't do that for arbitary parameters.

Idealy this would have a future solution but I'm not 100% sure what the solution would be. The idea behind variable controll rates is partially that the programer can optimise by leaving things that don't need high-rez interpolation at a slow rate. Practically this means that high-rez is expensive because ChucK is relatively ineficient. I don't realy mind that, Ge's time is finite and his study is about expressive programing so he spend his time there and not on VM/compiler optimisation. Fair enough, as a choice, I think, but there are definately chalenges there.

Right now I think that if in the future loops with a controll-rate of 1 sample would be cheap it would still be cumbersome to have to write a seperate loop at that rate for every such parameter. Writing the controll structure itself at that rate would be silly or at least very old-fashioned.

Solutions that I could imagine would be for example the ability to chuck the output of a given Ugen (like "Envelope" which acts as a ramp that takes a value, and a duration, then ramps to that value over that period) to a certain parameter of a different ugen (like .pan in this case).

Your sugestion of ramping automatically over the time chucked to now is interesting but perhaps not versatile enough. I may well like to write my loops at a rate of one "beat", yet have single notes do something over a smaler period and loops like that would also get complicated in that scenario.

Maybe we need something like this.

-1 => my_pan.pan;
Interp(1, second) => my_pan.pan;

I just made "Interp" up, it's a new sort of contruction that, in this case, would slide the value my_pan.pan from whatever it holds at that moment (in this case -1) to a give value (in this case 1) over a period of time (here one second).

This would be completely equivalent to using a ramping Ugen but less versatile in general and a lot more compact. There are some questions open still like what would happen if some other process would also start writhing to that parameter, should "Interp" detect this and quit? I dunno.

Simply borrowing what SC does wouldn't be feasable right now as ChucK -to the best of my knowledge- doesn't do block-processing and that I don't think implementing block-processing would be very easy considdering the nature of ChucK's controll structures and that those controll-strucutures may be affected by the Ugens. I'm sure I overlooked several dozen of realy hard questions here already.

It's a interesting problem... :¬)

Low Note, sorry about the diversion into theoretical future versions of ChucK when I realise that the present version can look complicated enough when you're fisrt starting! :¬)

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



Joined: Jul 20, 2007
Posts: 146
Location: New Jersey
Audio files: 2

PostPosted: Thu Aug 16, 2007 5:19 pm    Post subject: Reply with quote  Mark this post and the followings unread

No problem. Very Happy I think I'm getting back into all the numbers and letters.

I've been messing around with the example above some more, playing with various numbers. I thought that it might be some sort of frequency modulating. The other thought I may have had was that I was sending numbers to the gain outside its meaningful range. If each time it swept through, it was delivering one number below -1, it would eventually add up (My suspicion it was this was a result of me typing in a few bad numbers and causing well... pain. Crying or Very sad )

I mentioned my interest in creating a loop that swept back and forth using SinOsc. I've been having problems figuring out how to chuck the output of a SinOsc to a pan value. I only got error messages if I tried to directly chuck the one to the other, so my next attempt was:


Code:
SinOsc p => Gain q => Pan2 a => dac;
SinOsc s => blackhole;
.2 => s.sfreq;
.3 => q.gain;
0 => s.gain;



while (true) {
   .001::second => now;
 s.phase () * 2 => /*float b;

 b - 1.0 => */a.pan;}


The next attempt I tried was to include what I commented out. Still no luck.

How would I chuck values from an oscillator to something other than dac?

btw: the error messages I get when I try to directly chuck the SinOsc to a variable is:

Code:
[Pancircle.ck]:line(2): arguments type(s) do not match:
[Pancircle.ck]:line(2): ... for function 'Pan2.pan(...)' ...
[Pancircle.ck]:line(2): ...(please check the argument types)



Also, Kassen, if you have any other suggestions, throw them at me. I was having fun remixing the Drum beat, but wanted to explore some other areas, so I pulled up the stereo tutorial and this is the result of that 'remixing.' I'm also looking over some old CSound notes to see i can replicate similar effects with this language.

Long Post!
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


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

PostPosted: Thu Aug 16, 2007 6:16 pm    Post subject: Reply with quote  Mark this post and the followings unread

Tip; all Ugens have a .last() function that returns the last value calculated as a float.

example
Code:
;

SinOsc lfo => blackhole;
0.25 => lfo.freq;

while(true)
{
//just print it
<<<lfo.last()>>>;
.1::second => now;
}


This way you can get numbers from Ugens to your code, the other way around is also possible, using "Step" and "Impulse", both are Ugens.

Asuming you can now get your pan to work you can try this next;

Try to use "Step" as a "Sample and Hold" over a waveform from a oscilator, reducing it's sample-rate. Write some code to modulate the speed at which this happens to create a musical effect. Find the nearest IDM fan and play the result to him ;¬).

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



Joined: Jul 20, 2007
Posts: 146
Location: New Jersey
Audio files: 2

PostPosted: Thu Aug 16, 2007 7:25 pm    Post subject: Reply with quote  Mark this post and the followings unread

What a great tip.

I managed to get it to work by sending an oscillator to a separate gain set to zero and then to the blackhole.

Works really well for a Sine wave, but if I use Impulse, in order to get a bouncing back and forth effect, I get that damn popping sound again. I thought perhaps to use a Phasor to ramp down the volume, and some how... err... crashed audicle. I don't know what I did, since I lost what I was doing.

Is ADSR the only built in envelope in Chuck?


Okay - I have actual projects in programs and languages I already know that people are waiting for me to finish, so I'm going to take a long weekend break from all of this until I make some noticable progress on all of that.

Thanks again Kassen, I'll mess around with Step in a few days.
Back to top
View user's profile Send private message Visit poster's website
kijjaz



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

PostPosted: Thu Aug 16, 2007 10:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hmm.. Yes, I also recommend using Envelope UGen for fading up and down..
With that, it'd automatically update every sample,
so ideally, it'd be smooth-sounding..
and the code would be smaller..

I'll come back to program a simple modification of Low Note's example
with Envelopes and Gain soon! ^_^
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
dewdrop_world



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

PostPosted: Fri Aug 17, 2007 9:01 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Kassen,

I didn't mean to suggest that ChucK should do it like SC -- ChucK's great innovation is to get away from the fixed-size block calculation model, so I agree that it would be totally contrary to the spirit of the language to superimpose any kind of block-calculation paradigm on top of an incompatible methodology.

Still, I fear that if the user is responsible for manually interpolating in every case, it could become a usability issue.

At the risk of hijacking the thread, this relates to one of the reasons I haven't done much with ChucK. It's difficult for me to see, as an observer, how to create sensible layers of abstraction in a structure where you must always be intimately involved with every rate of change. One of the things I like best about SC is how easy it is to wrap lower-level entities into higher-level units: sound begins by creating a node on the server using an OSC message, but you can use a Synth object to hide the OSC messaging, which I further wrap in a Voicer object for node management. The voicer is triggered by an Event, which is generated by a Pattern, which (along with its auxiliary resources) is managed by a BP (Bound Process) in my library, which is an instance of a PRocess prototype. The practical impact is that I can address simple commands to BPs to control high-level compositional logic and this trickles down through all the other layers to change what you hear, creating effectively a scripting language for SC to use in performance. Whereas in ChucK, it seems in most of the simpler examples I've seen, that all the layers of abstraction are active in the same execution flow at once.

I suppose I should look more carefully at how to use events in ChucK. Certainly the temptation in ChucK is to mingle the sound-generation logic with compositional logic in the same shred, but that's a coding strategy that has proven not to scale well in virtually every type of programming problem.... so far events are the only thing I've seen in ChucK that can allow you to separate these.

Kassen wrote:
Your sugestion of ramping automatically over the time chucked to now is interesting but perhaps not versatile enough. I may well like to write my loops at a rate of one "beat", yet have single notes do something over a smaler period and loops like that would also get complicated in that scenario.


Yes, that was a bad idea. You should be able to control the ramp time independent of the chuck time. (Or, in the spirit of ChucK's microcontrol, should you perhaps chuck a short time into now, then a longer one to hold the value? Razz Just being cheeky now.)

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: Fri Aug 17, 2007 10:07 am    Post subject: Reply with quote  Mark this post and the followings unread

dewdrop_world wrote:


I didn't mean to suggest that ChucK should do it like SC -- ChucK's great innovation is to get away from the fixed-size block calculation model, so I agree that it would be totally contrary to the spirit of the language to superimpose any kind of block-calculation paradigm on top of an incompatible methodology.


Well, *maybe* we can still get advantage from some form of block processing. This has been considdered but it's hard for reasons that are well beyond my understanding and I don't think anybody knows when or if this would happen. If it does interpolation would likely still be tied to it in some way.

That being said; in my experience block processing in modular systems that allow for feedback can result in very odd and hard to pinpoint block-size-dependant issues.

Quote:
Still, I fear that if the user is responsible for manually interpolating in every case, it could become a usability issue.


Yes, I completely agree. Still; some manual controll will be needed as you can't just start interpolating each and every command and expect it to work predicatbly.

Quote:
At the risk of hijacking the thread, this relates to one of the reasons I haven't done much with ChucK. It's difficult for me to see, as an observer, how to create sensible layers of abstraction in a structure where you must always be intimately involved with every rate of change. One of the things I like best about SC is how easy it is to wrap lower-level entities into higher-level units: sound begins by creating a node on the server using an OSC message, but you can use a Synth object to hide the OSC messaging, which I further wrap in a Voicer object for node management. The voicer is triggered by an Event, which is generated by a Pattern, which (along with its auxiliary resources) is managed by a BP (Bound Process) in my library, which is an instance of a PRocess prototype. The practical impact is that I can address simple commands to BPs to control high-level compositional logic and this trickles down through all the other layers to change what you hear, creating effectively a scripting language for SC to use in performance. Whereas in ChucK, it seems in most of the simpler examples I've seen, that all the layers of abstraction are active in the same execution flow at once.


If I understand what you are after correctly then the one issue is that this wouldn't be a topic for "simpler examples".

I could for example have a "string" class. Six strings might be used by a "Guitar" class which might get asigned to a parameter in a "guitarist" object which in turn could send events to the guitar depending on a "score" object which I might also feed to the "guiarist".

Using classes, functions and events you could build a huge tower of abstractions and there would be no need to deal with the workings of individual strings when composing for a imaginiary guitar ensemble.

Quote:

I suppose I should look more carefully at how to use events in ChucK. Certainly the temptation in ChucK is to mingle the sound-generation logic with compositional logic in the same shred, but that's a coding strategy that has proven not to scale well in virtually every type of programming problem.... so far events are the only thing I've seen in ChucK that can allow you to separate these.


Events are a very good way of doing this but classes are also a option, A class that represents a instrument can also have a whole set of shreds of it's own that all share the class instance's namespace. For advanced usage that would likely involve events anyway but those could be internal to that class and might never be dealt with in the actual compositional process.

I tend to use a mixture of classes, function-calls, events and traditional flow-controlled loops. All of those have their own strengths, as soon as the whole thing starts scaling classes and functions will become more important in the mix. So far for me this is approach is scaling quite well for me. Back before I understood classes and event larger projects tended to become hard to manage over time, that's true.

Quote:

Yes, that was a bad idea. You should be able to control the ramp time independent of the chuck time. (Or, in the spirit of ChucK's microcontrol, should you perhaps chuck a short time into now, then a longer one to hold the value? Razz Just being cheeky now.)


Jokes are only funny if they have some element of truth, I think. A good solution here would involve both ChucK's facilities for micro-management as well as ChucK's tendency towards compact syntax. In my own experience micro-controll done well does not lead to unreadable or unusable ChucK-code, at least not so far. Probably a good solution will also depend on learning from things that have shown to be good or bad solutions in the past (which means we might still borrow :¬p).

And well, if your piece is a hour long, features dozens of instruments but needs minute controll of every element of every note then that's going to lead to a large and complicated score... There is simply no way around that.

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



Joined: Aug 13, 2006
Posts: 108
Location: Palo Alto, CA

PostPosted: Tue Aug 21, 2007 4:29 pm    Post subject: block processing Reply with quote  Mark this post and the followings unread

Hey all! Cool discussion of many interesting topics. Quick note on the block processing - it's definitely being investigated for ChucK, as occasionally discussed on the mailing list. After several design phases, we believe we it is very possible to reap the benefit of block processing without compromising chuck's fundamental timing model. We plan on integrating/trying quite soon. Not this imminent release... but soon!

Keep on ChucKin' (and Collidin')
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [12 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