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, [email protected] wrote: > > Message: 4 > Date: Wed, 12 Feb 2020 09:31:19 +0100 > From: IOhannes m zmoelnig <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD] Sample loop - start and end point (WAV files) > Message-ID: <[email protected] > <mailto:[email protected]>> > 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/>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
