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

[Dan Wilcox]

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: https://en.wikipedia.org/wiki/Audio_Interchange_File_Format <https://en.wikipedia.org/wiki/Audio_Interchange_File_Format>

> On Feb 12, 2020, at 9:31 AM, pd-list-request at lists.iem.at wrote:
> 
> Message: 4
> Date: Wed, 12 Feb 2020 09:31:19 +0100
> From: IOhannes m zmoelnig <zmoelnig at iem.at <mailto:zmoelnig at iem.at>>
> To: pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>
> Subject: Re: [PD] Sample loop - start and end point (WAV files)
> Message-ID: <a72428ac-1ab7-2e7e-d90d-c4f74350286c at iem.at <mailto: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.
> 
> totally.
> 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.
> 
> 
> fgamsdr
> IOhannes

--------
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/905559f7/attachment-0001.html>