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

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

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