I think I finally got sound file playback abstracted to the point where it's actually usable.

1. [monofile id path startframe numframes] or [stereofile ...]:

   • Automatically creates 1 or 2 arrays.
   • Loads the file.
   • Sets up 5 [value] variables:
     • idframes
     • iddur (in ms -- automatically compensates if the disk file sample rate doesn't match the hardware sample rate)
     • idsr -- disk file sample rate
     • idsr001 -- sample rate * 0.001 = samples / ms (useful in many places in Pd)
     • idscale -- file SR / system SR

2. [sf-play~] / [sf-play2~] uses the table(s) defined in [monofile] / [stereofile] and uses the [value] objects to drive a [cyclone/play~] in a sensible way. (E.g., play~ help says that times are given in milliseconds, but that's true only if the file sample rate matches the audio system -- my abstraction automatically multiplies by the sample rate scale variable, so you really can just specify time in milliseconds and not worry about it.)

I guess I might catch some heat for depending on cyclone, but 1/ cyclone is really indispensable and 2/ I've spent enough time on this and I don't want to rebuild a buffer player that's capable of crossfade looping when a fine one already exists.

https://github.com/jamshark70/hjh-abs with a few other miscellaneous little toys.

2021-09-19: Updated to fix a bug with looping.

hjh

Added buffer players with rate modulation: sf-varispeed (mono) and sf-varispeed2 (stereo).

These were HARD.

I'll admit that these abstractions aren't glamorous, but... I found when teaching novices how to load short sound files into memory and play them, that there's an unholy ton of moving parts, so many little things for them to mess up. I think these abstractions go a long way toward simplifying the process. Hope they are useful to someone.

Published in the same github repository.

hjh