Hi Atte, On Thu, Mar 5, 2015 at 2:36 AM, Atte wrote:

On 03/04/2015 06:59 PM, Perry Cook wrote:

...

Atte,

A handy list of Shred functions (From our new Book, Appendix A :-):

And where do I find this info online?

Theyre probably in a changelog somewhere, but also I am working on a new documentation system (generated from ChucK source) which automatically picks up new features like this. There is a prerelease version here: https://ccrma.stanford.edu/~spencer/ckdoc/

...

The ones you want are running() or done()

Hmmm. Thought I could do

return(Shred.fromId(myID).running())

but that gives null pointer exception. Makes sense, the shred with the id is not running, so I get a null reference, and trying to call running() on that... Better is

return(Shred.fromId(myID)!=null)

However something strange happens in combination with Machine.remove(myID) that doesn't happen when I switch to Shred.fromId(myID).exit(). The scenario is quite complex, so for now a quick difference of the two ways to remove a shred would be nice...

Hmm, it would be nice if there was no difference. But there is a difference, internally, and it appears that is leaking out of the abstraction so to speak. So basically .exit() appears to terminate the shred immediately whereas Machine.remove() waits until all shreds have finished executing for this sample, i.e. all shreds are waiting => now. At least that is what I am interpreting from the source code. spencer -- Atte http://atte.dk http://a773.dk _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users -- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University spencer@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/

Thanks Rich! Sounds straightforward, I will add that to the generator. spencer On Fri, Mar 6, 2015 at 7:27 AM, Rich Caloggero wrote:

https://ccrma.stanford.edu/~spencer/ckdoc/io.html#IO

Screen reader users find it amencely helpful on pages which list the various properties and methods of a particular object for each method / property definition be wrapped in a heading tag. This will become even more useful / necessary when descriptions are added.

For instance: ... - h2: IO

- h3: static member variables

- h4: int MODE_ASYNC

- h4: int MODE_SYNC *...*

Thanx for all your work on this. -- Rich

*From:* Spencer Salazar *Sent:* Friday, March 06, 2015 3:48 AM *To:* ChucK Users Mailing List *Subject:* Re: [chuck-users] is shred running? (Atte)

Hi Atte,

On Thu, Mar 5, 2015 at 2:36 AM, Atte wrote:

...

On 03/04/2015 06:59 PM, Perry Cook wrote:

...

Atte,

A handy list of Shred functions (From our new Book, Appendix A :-):

And where do I find this info online?

Theyre probably in a changelog somewhere, but also I am working on a new documentation system (generated from ChucK source) which automatically picks up new features like this. There is a prerelease version here: https://ccrma.stanford.edu/~spencer/ckdoc/

...

...

The ones you want are running() or done()

Hmmm. Thought I could do

return(Shred.fromId(myID).running())

but that gives null pointer exception. Makes sense, the shred with the id is not running, so I get a null reference, and trying to call running() on that... Better is

return(Shred.fromId(myID)!=null)

However something strange happens in combination with Machine.remove(myID) that doesn't happen when I switch to Shred.fromId(myID).exit(). The scenario is quite complex, so for now a quick difference of the two ways to remove a shred would be nice...

Hmm, it would be nice if there was no difference. But there is a difference, internally, and it appears that is leaking out of the abstraction so to speak. So basically .exit() appears to terminate the shred immediately whereas Machine.remove() waits until all shreds have finished executing for this sample, i.e. all shreds are waiting => now. At least that is what I am interpreting from the source code.

spencer

-- Atte

http://atte.dk http://a773.dk _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University

spencer@ccrma.stanford.edu +1 831.277.4654 <%2B1%20831.277.4654> https://ccrma.stanford.edu/~spencer/

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

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

-- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University spencer@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/

Hmm, let me clarify: semantically the difference between the two is "undefined." The extent to which that difference (if any) affects actual ChucK code can be considered a bug. Though its partially a bug in the language specification, which makes it harder to fix, compared to a bug in the implementation. I was more speaking to Atte's question about what might account for the differing results he was seeing with those two methods. It just so happens that Machine.remove is implemented such that it works almost exactly chuck - [shredid]. Whether or not this is desirable (or useful, etc.) can be debated, along the lines you have mentioned below. spencer On Fri, Mar 6, 2015 at 1:07 PM, Kassen wrote:

Spencer wrote;

...

Hmm, it would be nice if there was no difference. But there is a difference, internally, and it appears that is leaking out of the abstraction so to speak. So basically .exit() appears to terminate the shred immediately whereas Machine.remove() waits until all shreds have finished executing for this sample, i.e. all shreds are waiting => now. At least that is what I am interpreting from the source code.

Ok... but if we run Machine.remove() from shred A then I think we can be

absolutely sure shreds B, C and D will be waiting for something (potentially shred A yielding), because we have no real concurrency and we can also be sure the ugen graph is not being pulled by the dac at this moment for the same reason.

I can see this mattering in the case of "%chuck - [my_shred]" which could be executed while the VM is doing any of the things it can do. In that case we'll likely want to wait for a moment to avoid stuff like half of a operation being left on the stack, but in the case of commands coming from shreds I think we can be sure other shreds are not in the middle of something.

I'm not sure how that would have to deal with the need to be able to kill shreds stuck in a infinite non-time-advancing loop from the console though.

Maybe I am missing something and there is a reason to have the termination of shred B from shred A postponed until A yields in some cases?

Yours, Kas.

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

-- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University spencer@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/

On 03/09/2015 01:57 PM, Atte wrote:

I hope nothing gets changed with .exit(), since that seems the be the one that works the best :-)

I've been having huge problems with the suggested way of figuring out if a shred is running. I've cut down the scenario as much as possible, three files, supply your own beat: --- lib_sporker.ck --- public class Sporker{ public static int add(string filename){ Machine.add(filename) => int id; return id; } public static void remove(int id){ Machine.remove(id); //Shred.fromId(id).exit(); } public static int is_running(int id){ return(Shred.fromId(id) != null); //return Shred.fromId(id).running(); //return !Shred.fromId(id).done(); } } Sporker dummy; 100::week => now; --- --- sporker.ck --- Sporker.add("beat") => int id; <<<id>>>; <<>>; <<>>; 1000::ms => now; Sporker.remove(id); <<>>; --- --- beat.ck --- SndBuf s => dac; s.read("plastic_jam.wav"); 1 => s.loop; 1::week => now; --- The problem seems to be that as soon as the Shred.fromId(some_id) has been called, Machine.remove(some_id) might kill the thread, but the SndBuf keeps playing... Any ideas? Note that this is a reduced part of something larger. So the structure although it might seem odd in this small example has to be this way (I'm pretty sure), for instance the Sporker has to be a singleton since it is used for sporking and bookkeeping from various other places in the system. -- Atte http://atte.dk http://a773.dk

Atte: I don't know if this is directly relevant to your overall goal, but for my many hours of real-time performance work, I found the following construct to be 100% bullet proof. The idea is that you assign the Shred to a variable, e.g. _phoneme_handle, when you spork the shred. When you want to stop the shred, you don't directly kill it -- instead, you set the variable to something else (e.g. null). Within the shred's main processing loop, you compare the value of _phoneme_handle against "me", and stop processing if they differ. This approach cleanly avoids any race conditions associated with starting and stopping shreds: // called when the note first starts. fun Vox note_started() { spork ~ _phoneme_proc() @=> _phoneme_handle; // start babbling _vox => AudioIO.output_bus(); return this; } // called when note has finished. fun Vox note_ended() { null @=> _phoneme_handle; // stop babbling _vox =< AudioIO.output_bus(); return this; } // shred that modifies phonemes fun void _phoneme_proc() { while (me == _phoneme_handle) { // ... do stuff until _phoneme_handle changes } // here when the shred is absolutely about to exit } On Sun, 15 Mar 2015 at 01:58 Atte wrote:

On 03/15/2015 09:43 AM, Atte wrote:

...

On 03/09/2015 01:57 PM, Atte wrote: I've cut down the scenario as much as possible, three files,

Might be obvious, but run with

$ chuck lib_sporker.ck sporker.ck

Cheers -- Atte

http://atte.dk http://a773.dk _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

I find it highly in-elegant that the sporkee must care about stuff like

Atte: this True, but if you start thinking about all the potential edge, you may conclude that the sporkee needs to be involved. If you want a longer description of why I structured the code this way, it was inspired by my experience in Java: http://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrim... HTH. - Rob On Sun, 15 Mar 2015 at 07:33 Atte wrote:

On 03/15/2015 02:24 PM, Robert Poor wrote:

...

Within the shred's main processing loop, you compare the value of _phoneme_handle against "me", and stop processing if they differ.

Nice idea, thanks!

However, I find it highly in-elegant that the sporkee must care about stuff like this. I'd really prefer for an outside sporker to be able to pull the plug, with each process is as generic as possible. Like how the operating system of my computer handles the switching of all processes, without the different programs having to listen for a "now it's time to terminate" signal.

That aside. it sounds like an idea worth pursuing if anything else fails...

Thanks again for the input! -- Atte

http://atte.dk http://a773.dk _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users