Hey Mike,

Check out the "chunks" parameter of SndBuf: 
https://ccrma.stanford.edu/~spencer/ckdoc/ugen.html#SndBuf

This was added a little later and was designed to avoid the huge hit of loading the entire file into memory at once by reading the file in fixed-sized chunks, on-demand. You can play with it a bit but something like 2048 or 4096 is probably a good starting point. (Lower than that will likely provide incremental performance gain; you can go as high as you want up until you start getting crackling again.) As long as you dont try to access the whole file immediately (e.g. for normalization or other offline processing) it should do the trick for your use case. There may be other limitations but Im not able to recall them off the top of my head. 

Btw, me.yield doesn't allow for sound to process, for that you would actually want to pass time in between the audio file loads, at least one buffer size's worth of samples. me.yield is chiefly a way to tell the shreduler to run other shreds without a progression of audio time. 

Spencer



On Thu, Jul 2, 2020 at 2:20 PM mike clemow <michaelclemow@gmail.com> wrote:
Hey Michael! It's been a minute!

Thanks so much for that suggestion! I took a closer look at this code and I'm actually not doing Machine.add(); four times in a row, but rather spork ~ thingOne(); four times (although I do Machine.remove() four times to remove the shreds by ID). 

I still think the thing that I forgot to do is to add me.yield(); in between each of these (or at least at the end of the four lines) to keep the running audio smooth. I'm going through and trying it out. 

Since each of these functions that are running concurrently are loading large files into SndBuf instances, I'm hesitant to do the normal Chuckian thing and load it all up first and then let it play on demand using, as you suggest, a start() function or similar. Also, because I'm triggering these "cues" from across a network, I'm trying to trade "immediate and real time" for "reliable and low-memory impact." I've definitely built applications like that with Chuck that ate all the memory before! There's no streaming from disk implemented under the hood, unless I'm mistaken.

Let me see how this works and I'll report back!

Mike


--
Michael Clemow
Artist/Composer/Sound Designer
(he/him)


On Thu, Jul 2, 2020 at 5:07 PM Michael Heuer <heuermh@gmail.com> wrote:
Hello Mike,

Since Machine.add is hitting the file system and parsing and evaluating the ChucK scripts, it might work better to do all of that in one go when not generating sound

Machine.add("thingOne.ck");
Machine.add("thingTwo.ck");
Machine.add("thingThree.ck");
Machine.add("thingFour.ck");

And then later call methods to initialize them serially or in different shreds, something like

thingOne.start();
thingTwo.start();
thingThree.start();
thingFour.start();

spork ~ thingOne.start();
spork ~ thingTwo.start();
spork ~ thingThree.start();
spork ~ thingFour.start();

Hope this helps,

   michael


Begin forwarded message:

From: mike clemow <michaelclemow@gmail.com>
Subject: [chuck-users] Machine.add() and me.yield()
Date: July 2, 2020 at 3:43:51 PM CDT
To: ChucK Users Mailing List <chuck-users@lists.cs.princeton.edu>
Reply-To: ChucK Users Mailing List <chuck-users@lists.cs.princeton.edu>

Greetings Chuckists,

Looking for validation on this before I change many, many lines of code: I'm noticing clicks and pops in running audio when I do something like this:

Machine.add("thingOne.ck");
Machine.add("thingTwo.ck");
Machine.add("thingThree.ck");
Machine.add("thingFour.ck");

and also with Machine.remove(idNum); four times in a row.

Question:

Is this:

Machine.add("thingOne.ck");
Machine.add("thingTwo.ck");
Machine.add("thingThree.ck");
Machine.add("thingFour.ck");
me.yield();

significantly different than this:

Machine.add("thingOne.ck");
me.yield();
Machine.add("thingTwo.ck");
me.yield();
Machine.add("thingThree.ck");
me.yield();
Machine.add("thingFour.ck");
me.yield();

???

The same for sporking shreds four in a row.

Warmly,
Mike

--
Michael Clemow
Artist/Composer/Sound Designer
(he/him)
_______________________________________________
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
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users