[PD-dev] soundfiler second outlet?

[Jonathan Wilkes]

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 at gmail.com> wrote:
 

 that'd be a dream come true :)
2016-04-03 3:23 GMT-03:00 Dan Wilcox <danomatika at 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 at lists.iem.at
http://lists.puredata.info/listinfo/pd-dev




_______________________________________________
Pd-dev mailing list
Pd-dev at lists.iem.at
http://lists.puredata.info/listinfo/pd-dev


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20160403/8328fbfd/attachment.html>