Tom Lieber

The biggest problem with this is that it means the shred which does
the load gets lost in time. It is out of sync because the load time
couldn't be predicted, so you have to do extra stuff to resync it. It
seems better to stay deterministic and just encourage preloading.


I agree that this event would come at a time that wouldn't be deterministic from ChucK's perspective but I'd prefer to have a shred that resumes running as soon as it's useful again over a shred that sends deterministically timed instructions to a soundfont that isn't yet loaded. I imagine we'd only use such a event in the case of instructions that wouldn't make sense to send before having finished loading.

As I understand the situation there would be no need for extra stuff in many cases, we'd just place the sync instructions (of whatever nature) after we made sure the font was loaded instead of before. The exception would be shreds that get their start timing implicidly defined by the moment they are sporked or added. in that case; yes, some extra syncing would be needed but isn't this a case of ease of syncing v.s. ease in preventing audio glitches or missed notes?

I do believe I have at least once seen the situation where reading a few large files into SndBuf's and starting to use them immediately after that seemed to cause issues (to the tune of needing a complete computer reboot). I'm not yet sure about this but if that's true then such things too could perhaps be prevented by having the shred wait until the SndBuf has finished loading. Right now I believe .chunks() is expected to deal with that there but that function doesn't take HD or memory speed into account and hence there is no way of expressing "as fast as possible but no faster" which I would like to be able to express.

I hope that made sense, I'm mainly interested in the link between ChucK's timing and the computer's capabilities here; I'd like to try your work out but my soundcard doesn't support soundfonts.

Yours,
Kas.