Author |
Message |
brutusx
Joined: Apr 12, 2011 Posts: 8 Location: Canada
|
Posted: Tue Aug 30, 2011 5:43 am Post subject:
Running Time = now? Subject description: now, time, running time, and how they relate |
|
|
Hi,
One thing that's confusing is that it seems like the documentation suggest that time (now variable) in Chuck can be stopped or at least controlled. But the following example code console printout suggests that time keeps being added to now regardless of whether or not a shred is running. Also, the documentation says that now being advanced can stop a shred from running. But now seems to ALWAYS advance. Very confusing stuff... Wish they would spend more time explaining time. Here's the code that can show how now advances no matter what (just run it twice and you'll see what I mean):
// compute value that represents "5 seconds from now"
now + 5::second => time later;
// while we are not at later yet...
while( now < later )
{
// print out value of now
<<<now>>>;
// advance time by 1 second
1::second => now;
} |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Tue Aug 30, 2011 6:24 am Post subject:
|
|
|
Hi!
Unless you are actively adding time to the clock, time stands still (from the ChucK program's point of view).
If you remove this from your program:
...you will get an endless loop that runs while the clock isn't advancing and sound stops. This isn't recommended actually since it puts a heavy load on your computer - in earlier versions of ChucK it could crash the OS (as I found out the hard way myself).
Another way to describe the statement "1::second => now" is "add one second to the clock". _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
brutusx
Joined: Apr 12, 2011 Posts: 8 Location: Canada
|
Posted: Tue Aug 30, 2011 8:18 am Post subject:
Hmmm... I don't understand why the console shows otherwise.. |
|
|
Here's a printout of the console. Notice that there is a time difference between the end of the final now value after the shred exits, and the value of the first now of the second shred. Shouldn't it be identical if time was not advanced between shreds? Instead, this looks like now = current time (in samples) to me...
[chuck](VM): sporking incoming shred: 1 (Untitled)...
103168.000000 :(time)
147268.000000 :(time)
191368.000000 :(time)
235468.000000 :(time)
279568.000000 :(time)
[chuck](VM): sporking incoming shred: 1 (Untitled)...
453120.000000 :(time)
497220.000000 :(time)
541320.000000 :(time)
585420.000000 :(time)
629520.000000 :(time)
Shouldn't the second shred have started with 279568 instead of 453120 if now had stopped after the first shred quit?
Instead, now seems to continue to accumulate 44100 samples a second *regardless* of whether or not there is a shred running.
Please explain why I'm wrong, and why now moves forward without a shred running.
B. |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Tue Aug 30, 2011 9:30 am Post subject:
|
|
|
OK, there are several different ways you can run chuck. I am assuming you're using "chuck --loop" in one terminal, and then chuck + file.ck in another.
When you first start chuck, the clock starts at zero and then starts to advance in sync with your audio interface. From the chuck runtime's point of view, the clock will simply tick along.
When you start the first shred, the value of now will be the time that passed since you first started the chuck runtime. When you start the second shred the value of now will be the time that passed since you started the chuck runtime.
Printing now with <<<now>>> outputs the time in milliseconds. Notice how the time when you start the first shred isnt zero, but rather a bit more than 10 seconds. That's probably how long it took you between starting up chuck and adding the first shred.
So now doesn't stop just because shreds are killed. Your observation that now seems to continue to accumulate 44100 samples a second *regardless* of whether or not there is a shred running is correct.
To restart the clock you need to restart all of chuck. If you want to be able to refer to the moment you started a shred in relation to what the clock is now, you can store now at the top of the program:
Code: | now => time whenShredWasStarted;
|
_________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Tue Aug 30, 2011 9:34 am Post subject:
|
|
|
Just a comment about being able to stop the clock: there isn't a command like "stop the clock". Rather what is referred to is the fact that while you are executing code that doesn't wait for the clock using a "xxx => now;" statement, time effectively stands still, and you are able to wait whatever miniscule amount of time you wish without timing being distorted in the program. _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Tue Aug 30, 2011 9:37 am Post subject:
|
|
|
BTW if you are using miniAudicle, ignore the first sentence about terminals two posts up. What I've writted still applies, except you start the chuck runtime (or VM) using some button or menu option and then add shreds. If you restart the runtime (or VM), the clock should reset. _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
brutusx
Joined: Apr 12, 2011 Posts: 8 Location: Canada
|
Posted: Tue Aug 30, 2011 9:45 am Post subject:
Still don't understand Subject description: time, now |
|
|
(If I've posted multiple times I apologize. It didn't seem to post my reply twice now...)
I still don't understand how you can advance time without sending something to now. Like, between the two shreds now advanced without now being manipulated in anyway. Why? |
|
Back to top
|
|
|
brutusx
Joined: Apr 12, 2011 Posts: 8 Location: Canada
|
Posted: Tue Aug 30, 2011 9:47 am Post subject:
Hmmm... Subject description: now |
|
|
I'm using miniAudicle.
Why is the Virtual Machine advancing now without any intervention from the code that is supposed to be the only way to advance now? |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Tue Aug 30, 2011 11:14 am Post subject:
Re: Hmmm... Subject description: now |
|
|
brutusx wrote: | I'm using miniAudicle.
Why is the Virtual Machine advancing now without any intervention from the code that is supposed to be the only way to advance now? |
Dunno... because the guys who designed the language wanted it that way? Maybe the VM would crash otherwise?
Could you describe what kind of hurdle this puts in your way?
The only way to advance time within a shred is to wait on now. Outside the world of shreds time needs to advance regardless if there are one, ten or zero shreds running. _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
brutusx
Joined: Apr 12, 2011 Posts: 8 Location: Canada
|
Posted: Tue Aug 30, 2011 11:24 am Post subject:
Uh. okay... Subject description: chuck time now |
|
|
Oh,
I didn't realize that now runs like current time outside of a shred. I was under the impression that something needs to be chucked to now no matter what, or it doesn't advance. That's what the manual says.
I'm just trying to understand the language, and now seems like the linchpin. So when I try an example in miniAudicle, and now doesn't behave the way it's described.... well, that confuses the hell out of me.
But I think I understand. In miniAudicle, now runs like current time no matter what. I wish that little tid bit was included in the manual. Unless I missed it...
B. |
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005 Posts: 4145 Location: Sweden
Audio files: 371
G2 patch files: 100
|
Posted: Tue Aug 30, 2011 11:30 am Post subject:
|
|
|
Hmm, I don't use miniAudicle regularly myself, but my understanding is that you can turn the VM on and off. You can do the same thing from the command line - it's just that I don't use that feature very much.
Actually I understand now why people keep talking about adding and removing shreds - I've always wondered why.
Anyway, the concept of clock versus shred is the same in ChucK generally, miniAudicle or no. The clock starts when ChucK VM starts (which may coincide with you starting miniAudicle or your first shred). Every shred that gets added will get the global clock value from "now", which may be greater than zero if the VM has been running for some time. Every shred uses the same clock.
One benefit of having a global clock is that you can synchronize shred. Say you want you printout to happen simultaneously for all shreds that you add. If you add this to the top of your program:
Code: | 1 ::second - (now % second) => now; |
You will see that the shreds get synchronized. For a more musical application, imagine you're running sequencers that you want to be synchronized. _________________ Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
Back to top
|
|
|
|