Throwing something else out there: looking at d_soundfiler.c, it looks like it wouldn’t be that hard to add a second outlet that could send out the number of channels and samplerate of the loaded file. As far as I can tell, the number of channels is already read, so it involves reading the samplerate. This would allow for the calculation of the correct playback speed for samples irregardless of source & playback samplerates.
WAVE:
The samplerate is the 4 bytes after the number of channels in the WAVE fmt chunk. Ref: http://www.lightlink.com/tjweber/StripWav/Canon.html http://www.lightlink.com/tjweber/StripWav/Canon.html
AIFF:
The samplerate is the last field in the COMM (Common) chunk.
typedef struct {
ID ckID; long ckSize; short numChannels; unsigned long numSampleFrames; short sampleSize; extended sampleRate;
} CommonChunk;
Ref: http://www-mmsp.ece.mcgill.ca/documents/audioformats/aiff/Docs/AIFF-1.3.pdf http://www-mmsp.ece.mcgill.ca/documents/audioformats/aiff/Docs/AIFF-1.3.pdf
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
that'd be a dream come true :)
2016-04-03 3:23 GMT-03:00 Dan Wilcox danomatika@gmail.com:
Throwing something else out there: looking at d_soundfiler.c, it looks like it wouldn’t be that hard to add a second outlet that could send out the number of channels and samplerate of the loaded file. As far as I can tell, the number of channels is already read, so it involves reading the samplerate. This would allow for the calculation of the correct playback speed for samples irregardless of source & playback samplerates.
WAVE:
The samplerate is the 4 bytes after the number of channels in the WAVE fmt chunk. Ref: http://www.lightlink.com/tjweber/StripWav/Canon.html
AIFF:
The samplerate is the last field in the COMM (Common) chunk.
typedef struct {
ID ckID; long ckSize; short numChannels; unsigned long numSampleFrames; short sampleSize; extended sampleRate;} CommonChunk;
Ref: http://www-mmsp.ece.mcgill.ca/documents/audioformats/aiff/Docs/AIFF-1.3.pdf
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Shouldn't that be a separate object? Like [soundinfo] or something? I'm thinking of cases where the user may want to query an attribute in order to decide how to load a file, or even whether they want to load it at all. Plus a one-to-one ratio between method and output is way easier to learn, understand, and use. Also-- I don't see anything in pd docs about methods which cause a single outlet to send multiple messages in zero logical time. It may seem like an obvious design pattern to pair that with [route], but Pd users have shown they can come up all kinds of creative ways to interpret an interface. They could use an accumulator and mod to count outputs if they want, and that makes it hard to add more messages later.
-Jonathan
On Sunday, April 3, 2016 10:02 AM, Alexandre Torres Porres porres@gmail.com wrote:
that'd be a dream come true :) 2016-04-03 3:23 GMT-03:00 Dan Wilcox danomatika@gmail.com:
Throwing something else out there: looking at d_soundfiler.c, it looks like it wouldn’t be that hard to add a second outlet that could send out the number of channels and samplerate of the loaded file. As far as I can tell, the number of channels is already read, so it involves reading the samplerate. This would allow for the calculation of the correct playback speed for samples irregardless of source & playback samplerates. WAVE: The samplerate is the 4 bytes after the number of channels in the WAVE fmt chunk. Ref: http://www.lightlink.com/tjweber/StripWav/Canon.html
AIFF: The samplerate is the last field in the COMM (Common) chunk. typedef struct { ID ckID; long ckSize; short numChannels; unsigned long numSampleFrames; short sampleSize; extended sampleRate; } CommonChunk; Ref: http://www-mmsp.ece.mcgill.ca/documents/audioformats/aiff/Docs/AIFF-1.3.pdf -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Sure, but that’s perhaps a second discussion.
In this case, [soundfiler] already has the pattern of “load a file into an array and send out the number of samples”.
I figure it would be easy to extend that into “load a file into an array and send out the number of samples as well as the sampelrate & number of channels”.
I agree an overall [soundfileinfo] to read the header info would be nice to have built in to vanilla but:
* there is an external which does this (in zexy I believe?) * I’m working in little steps & at the very least coudl *really use* the samplerate when loading tables :)
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Apr 3, 2016, at 2:10 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Shouldn't that be a separate object? Like [soundinfo] or something?
-
Alexandre Torres Porres -
Dan Wilcox -
Jonathan Wilkes