[PD] Sample loop - start and end point (WAV files)

Ingo ingo at miamiwave.com
Wed Feb 12 10:13:21 CET 2020

Thanks, Dan!


They must be embedded in the "Marker Chunk" in AIFF and in the "Cue Point
Chunk" in the WAV format.

This gives me a further idea for searching on.


Of course it would be fantastic to have reading this information directly
implemented in the [soundfiler] object!





From: Pd-list [mailto:pd-list-bounces at lists.iem.at] On Behalf Of Dan Wilcox
Sent: Wednesday, February 12, 2020 9:48 AM
To: Pd-List
Subject: Re: [PD] Sample loop - start and end point (WAV files)


I'm laughing myself silly/crying after wading through the details for almost
*one month* of full time work. It's a balance of updating an almost 20 year
old section of Pd *without* breaking what currently works while adding
required features.


If all y'all want updates/changes, you need to find a way to contribute
beyond list discussions.


I am able to focus on this right now as we use libpd for a major project at
work (which also supports infrastructure and guest artist works) and we have
legacy projects using 32+ channel AIFC and CAF files. We need to be able to
playback such files within libpd to support our historical repertoire. If we
had a need for MP3, I probably would have implemented that, but uncompressed
audio is easier to stream form disk as there is minimal conversion needed,
specially with so many channels. Before I even began this work, I proposed a
general architectural refactoring of the code base and have fixed a number
of bugs.


As for sample loop points, those are probably in the instrument / sampler
chunks in the AIFF, WAVE, and CAF file specs. Since I am flush with file
format knowledge at the moment, I will try implementing either a
[soundfiler] meta flag or 3rd outlet. I make no explicit promises.


If you don't know what I'm talking about, you can either read the 30+ year
old official file format spec documentation or the file format overviews on
Wikipedia, for example AIFF:


On Feb 12, 2020, at 9:31 AM, pd-list-request at lists.iem.at
<mailto:pd-list-request at lists.iem.at>  wrote:


Message: 4
Date: Wed, 12 Feb 2020 09:31:19 +0100
From: IOhannes m zmoelnig < <mailto:zmoelnig at iem.at> zmoelnig at iem.at>
To:  <mailto:pd-list at lists.iem.at> pd-list at lists.iem.at
Subject: Re: [PD] Sample loop - start and end point (WAV files)
Message-ID: < <mailto:a72428ac-1ab7-2e7e-d90d-c4f74350286c at iem.at>
a72428ac-1ab7-2e7e-d90d-c4f74350286c at iem.at>
Content-Type: text/plain; charset="utf-8"

On 12.02.20 01:21, Christof Ressi wrote:

To be clear: I agree that Pd probably shouldn't support MP3 or other
compressed audio formats by itself, it should just make it easy to add
such support as plugins.

i've been talking with dan about this, and we kind of came up with the
start of an "architecture" to allow other decoding/encoding backends.

to keep expectations low:
this mainly started to get rid of a lot of boiler-plate code in the
current implentation, and the "architecture" is currently only a struct
(so dan is probably loughing himself silly when i call it
"architecture"), and it only supports uncompressed formats, but that
could  very easily be extended.




Dan Wilcox

@danomatika <http://twitter.com/danomatika> 

danomatika.com <http://danomatika.com> 

robotcowboy.com <http://robotcowboy.com> 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200212/50f9d297/attachment.html>

More information about the Pd-list mailing list