[chuck-users] SoundFonts in ChucK

[Tom Lieber]

On Sat, Oct 4, 2008 at 10:10 PM, Kassen <signal.automatique at gmail.com> wrote:
> 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.

The crashes are bad, but I think just as bad would be the odd
situations one might get themselves into when trying to use something
that slips out of time like that. For example:

  SndBuf snd => dac;
  ...
  fun void player() {
    while(true) {
      0 => snd.pos;
      snd.samples()::samp / snd.rate() => now;
      snd.rate() * 1.1 => snd.rate;
    }
  }
  ...
  spork ~ player();
  ...
  "large_sound.wav" => snd.read;

Swapping the last two lines would make the code run the same as you'd
expect today. With them as they are, what would happen? Would the
symptoms be obvious enough that it could be debugged?

At least files are already thought of as one-at-a-time resources.

Simpler:

  SndBuf snd => dac;
  "large_sound.wav" => snd.read;
  <<< snd.samples() >>>;

This would become something like:

  SndBuf snd => dac;
  "large_sound.wav" => snd.read;
  snd.loaded() => now;
  <<< snd.samples() >>>;

-- 
Tom Lieber
http://AllTom.com/