Stephen; ChucK could probably use the equivalent of Pd's "realtime" object. I

suggest calling it "nowreally"!

realness does seem to depend on the perspective.... I

can't really parse the first sentence in this paragraph though. :-)

In my defence; we are dealing with several types of "now" and at least a few types of "time". It's my fault but famous philosophers demonstrated that talking about languages is hard in ways that need not be solvable without inventing another language. Fortunately you are a object of type "person" and I gather those are amazingly tolerant for faulty input. ; ¬) Cheers, Kas.

Stephen

Sure, but this is a common thing to deal with in audio languages.

I can imagine! talking about "talking" is inherently hard. Pd

calls it "logical time" and "real time", which I think is the correct terminology.

Sounds quite sensible to me.

So as for the code I posted in the forum, with a way of determining 'real' now I could have done,

// one million sqrts 0 => float answer; for (1=>int i; i<=1000000; i++) { answer+sqrt(i) => answer; if ((realnow - now) > 3::ms) 3::ms => now; }

Btw, is this actually what you were asking or am I way off?

No, that seems about right, in fact I'd say "realnow => now" ought to do, even. That just leaves the question of where we'd get a "realnow". If we'd get a "realnow" as a proper language abstraction that would deal with a lot though I'd say "realnow" for the HD may not be the same as for the CPU. To put it in other words; ChucK lets us deal with a VM which is very pleasant as the VM is much simpler then a actual computer but the limits of the host computer may be relevant for what we'd like to tell the VM. Yours, kas.

Stephen

I like "realnow => now" very much. That's a great syntax for it. ;-)

I'm sure some kind of pun could be used here, but it's not coming to me... "nowreally" is the best I could come up with.

I like it too, but if anything ever did this needs Ge and he has a a affinity for and a talent in that field. Barring better ideas and terms I'm behind this. Yours, Kas.

On Thu, Oct 9, 2008 at 8:55 PM, Tom Lieber wrote:

With code like:

while(notdone) { dowork(); pause_dur => now; }

tweaking pause_dur until the computationally heavy code runs without skipping is the same as benchmarking it to figure out how long it takes to execute, and it's safe.

I don't think system calls, even ones like reading files, should take a shred out of the shreduler until they finish, though I admit that's personal preference. Deterministic parallel code like ChucK's is hard to come by.

But code like this:

me =< now; // step outside time doallwork(); me => now; // step back

just can't happen.

Allowing shreds to step outside time would solve all the problems brought up in the thread, but it would weaken some of the data consistency guarantees ChucK's cooperative multishredding gives you. Even if ChucK could interleave execution of your Neo shred with that of those still enslaved by the virtual machines, Neo would have to be frequently interrupted in the middle of whatever he was doing to prevent audio underflows. And since he doesn't know when he'll be interrupted, his data won't necessarily be consistent.

Hm, are you talking about introducing "real" parallelism? (i.e., pthreads) I didn't really mean to imply that in anything I wrote, at least. I agree that doing it properly would be difficult and error prone. Probably the "out of time" shred would need to be forced not to access any common objects, at the very least, and communicate by other means than global variables. (this would be equivalent to OSC, as you mention at the bottom.)

If it were a local variable in a for-loop, fine; but what if it were a variable global to the file, or a static variable in a class used by other shreds? ChucK code is written with the assumption that if doesn't let time pass, no data can change beneath its feet.

My recommendation: use multiple ChucKs with message-passing (OSC, whatever). I hear Prof. Cook does it, and he seems like an all right guy.

---

By the way, I'm sorry, but I still can't figure out what this would be expected to do:

realnow => now;

The problem that was brought up on the forum was how to do a bunch of intensive computation before starting the audio synthesis running, without causing problems. I think I took the liberty of generalizing the question into how can we do a lot of computation _anywhere_ in a chuck program without stalling the other shreds and causing havoc with the dac. My suggestion was to advance time throughout the lengthy computation, to make sure every other shred can get a chance to do its stuff. Kassen noticed that we have no way of knowing at what point during the lengthy computation we should advance time, without making a guess as to how long the computation will take. The 'realnow' suggestion is to make it possible to tell what time it is in real time. In logical time, a bunch of computation takes no time at all, but of course in the real world time is passing. So looking at the difference between realnow and now would tell you how much time you've used doing computations. In principle at the immediate beginning of a function, realnow and now are equal. After a few instructions, realnow has advanced, but now is still the same. So chucking realnow to now makes logical time advance to the state of real time. In other words, if a function takes 3 ms to complete, you could make sure not to interrupt other shreds by, while (...) { longfunction(); realnow => now; } This would ensure that logical time advances during the computation, while not forcing you to guess the actual time that longfunction() takes to execute. Note that none of this means changing anything in the shreduler. And yes, using multiple chucks with OSC is something else I suggested on the forum. You could even use another more optimized language to do the tough computations and pass back the results. OSC is great because it makes it easy to introduce inter-process procedure calls. Steve

On Thu, Oct 9, 2008 at 10:09 PM, Tom Lieber wrote:

...

In other words, if a function takes 3 ms to complete, you could make sure not to interrupt other shreds by,

while (...) { longfunction(); realnow => now; }

This would ensure that logical time advances during the computation, while not forcing you to guess the actual time that longfunction() takes to execute.

Note that none of this means changing anything in the shreduler.

That wouldn't help at all, though. ChucK has to execute longfunction() to completion (holding up every other shred during that time) before it gets to "realnow => now;".

Sorry, I meant to imply that longfunction() is a short part of a longer, iterative computation. In other words, all meant to say is, "move time along in the middle of your long computation". Steve

On Thu, Oct 9, 2008 at 11:15 PM, Tom Lieber wrote:

On Thu, Oct 9, 2008 at 10:49 PM, Stephen Sinclair wrote:

...

On Thu, Oct 9, 2008 at 10:09 PM, Tom Lieber wrote:

...

...

In other words, if a function takes 3 ms to complete, you could make sure not to interrupt other shreds by,

while (...) { longfunction(); realnow => now; }

This would ensure that logical time advances during the computation, while not forcing you to guess the actual time that longfunction() takes to execute.

Note that none of this means changing anything in the shreduler.

That wouldn't help at all, though. ChucK has to execute longfunction() to completion (holding up every other shred during that time) before it gets to "realnow => now;".

Sorry, I meant to imply that longfunction() is a short part of a longer, iterative computation. In other words, all meant to say is, "move time along in the middle of your long computation".

Okay, that makes more sense. Still... that only helps with implementations of longfunction() that take much less than a sample on average to complete. If it's about a sample, you may as well replace it with 1::samp => now;. If it's more than a sample, it will cause underruns anyway.

That's true for the audio buffer size, not 1 sample. Usually the time to calculate an audio buffer is less than the time than to play an audio buffer, which is what allows it to synthesize sound in real time. There is always a bit of time left over after calculating the audio buffer to run a bit of chuck VM code. (In fact the ChucK VM is run after every sample, but it just means that "extra time" is interleaved into the buffer calculations.) That's why my initial example on the forum just uses 3::ms. It's generally more efficient to advance a few ::ms rather than 1 sample at a time. Kassen was suggesting that it would be better to know the actual time it takes for the code to run, instead of using a constant duration like that. Steve

On Fri, Oct 10, 2008 at 7:16 AM, Kassen wrote:

There is a conflict between how ChucK will never let go of "now" and how we'd ideally prefer audio not to break up. When something has to give (like when we tell ChucK we instantly want to know ten million square roots) it's the audio that gives.

The way every UGen does this is to precompute.

I suppose that what I'm looking for is a way to yield to the Ugen graph,( which is the strongest link between ChucK's time and the stuff on my clock), give it the CPU to calculate what it needs to calculate (which may well be nothing right now), then give me the CPU back.

Yielding to the UGen graph is exactly the same as yielding to the other shreds. The UGens are in lock-step with the shreds for the purposes of strong timing. -- Tom Lieber http://AllTom.com/

On Thu, Oct 9, 2008 at 6:31 PM, Stephen Sinclair wrote:

The problem that was brought up on the forum was how to do a bunch of intensive computation before starting the audio synthesis running, without causing problems. I think I took the liberty of generalizing the question into how can we do a lot of computation _anywhere_ in a chuck program without stalling the other shreds and causing havoc with the dac.

Hi, I was the original poster in that forum thread, and I'd just like to chime in with my thoughts. At first I was merely wondering about what will happen with heavy processing loads; I had no specific timing scenario in my mind, but I did suggest the "compute all before audio begins" method, but that certainly isn't all that interests me. Everyone's responses so far have shed some much needed light on the situation, thanks. I REALLY like the idea behind this code: me =< now; // step outside time doallwork(); me => now; // step back but I guess using OSC would be a similar method, wouldn't it. However, (and maybe my chuck newbness will start to show in this question) what if I was working on an algorithm that required the previous audio sample's value before the next audio sample could be calculated, and those calculations were extremely computationally intensive? The physical constraints of the computer simply wouldn't be able to keep audio flowing at audio rates, but would chuck be able to output the sound to an audiofile? If I chuck both this mythological algorithm file and the rec.ck (from the examples) to the same VM, will the audio file output slowly fill with the correct sequence of audio samples (my gut tells me yes)? Hmm, now to go build a Beowulf cluster to OSC a bunch of code to... Thanks again for the wonderful ideas/perspectives/thouhts. -Eric Hedekar