[sfload] issues/features

Unlike [soundfiler], it does not write files.
It should have an outlet for info, and if we send it an info message, it just outputs the file information without loading it. The info should be "nsamples", "sample rate", "nchannels", "bits" and I'd also like this object to give us as information the loop regions from metadata in audio files...
As for the array name, if you're loading a file with 2 or more channels, you should give a single array name and it would then look for "x-arrayname" tables, where "x" is the channel name and what we do already for Cyclone and ELSE.
It should resize the array by default! Unless we give it messages that tells it otherwise... and these can also be flag arguments instead. So we could have a 'noresize' message/flag.
A 'skip' parameter would also skip samples in the file being loaded (I'm just using the term used in [soundfiler] but we can think of another name).
A 'nframes' parameter could define the number of samples to read from a file. In the case there aren't as many samples as asked by 'nframes', those extra points would be zeroed out. Arrays are resized to this number of samples, but if we ask it not to resize, we let this write and overwrite the first number of samples... but it it reaches the size limit of the array, it gets silently truncated.
We can also think of a 'range' message with start and end points, and also set this in ms instead of samples.
An 'onset' message sets staring point in the array to write to. Whatever amount of audio we ask to load, either a portion or the whole thing, gets added to the array and it resizes, unlike we tell it not to resize.
We can also have a "channel" message, to get a single channel only, if desired
I'm also thinking of a 'mix' message that sums to the content of an array...

porres / pd-else

[sfload] issues/features #2119