If you are interested, with the sample_id system, the pdmtl abstractions have a basic 4 cue point system i.e. start,end, loop in, loop out . Once you load a wav with the sample_id system you can load it many times without the actual sample(frame) data being reloaded. Since you can save the cuepoints, you can "reload" the same file with a different set of the 4 cues.
For example, you can have a loop.wav file, that can be loaded as 16 "samples" each one having their different 4 cue points. Even thought in PD, you have 16 "copies" of the same sample, the actual audio data is only loaded once.
Tom
Cool, thanks for the info. I am sure there are a dozen free C implementations of this, it's just a matter of getting that into a Pd object. Any volunteers? :D.hcOn Sep 18, 2007, at 6:42 AM, hard off wrote:the workaround i have at the moment is that audacity lets you export cue points as a .txt file.
As long as you don't add any labels to your cue points, then that text file contains a list of cue point times which you can read directly into an array in pd.
in audacity, do the following:
Project -> New Label Track
select your cue points (Add Label at Selection)
File -> Export Labels
however, a pd object to read the cue points from .wav or .aiff files would be very useful. from what i have been reading, all the cue points are stored as a single line of data in the header of the file.
here's a cue point reader as a supercollider patch:
http://www.create.ucsb.edu/pipermail/sc-users/2006-November/029666.html
----------------------------------------------------------------------------Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list