[PD-dev] CAF file support?

Dan Wilcox danomatika at gmail.com
Fri Apr 19 23:04:05 CEST 2019


This is something that I could potential do at work and tackling that list could probably be part of it. I was thinking of making a generic interface so that file types could be split into separate .c files like the audio & midi backends. This would make adding a new format much easier and improve maintenance as well.

This is something that probably would happen more in late summer-fall time, although I could imagine doing smaller aspects of it beforehand for 0.50. I could justify using this time for the overall project, to some degree. :)

> On Apr 19, 2019, at 6:35 PM, Miller Puckette <msp at ucsd.edu> wrote:
> 
> I'm of two minds about this - I think it would be excellent to start offering
> 64-bit file lengths, but I wonder if this is going to be a widely-used format
> or not (personally I've never heard of it :)
> 
> Also - I have three dolist items for soundfiler/read/writesf~ :
> 
> fix thread-unsafe way readsf~ searches along the file path (need to make a
> local copy of the path so that the sub-thread isn't asking the canvas to
> do the search via open_via_path)
> 
> allow reading and writing ASCII text files (way way overdue!)
> 
> fix writesf~ to make running updates to the chunk size as the file grows,
> so that if the file never gets 'closed' it still gets a reasonable size
> 
> None of this is the least bit fun or interesting I'm afraid...
> 
> cheers
> Miller
> 
> 
> On Thu, Apr 18, 2019 at 10:36:21PM -0300, Alexandre Torres Porres wrote:
>> Em qui, 18 de abr de 2019 ??s 14:22, Dan Wilcox <danomatika at gmail.com <mailto:danomatika at gmail.com>>
>> escreveu:
>> 
>>> ???Why not???? would come from other maintainers who do not necessarily want
>>> to be stuck with yet more code. I???m pretty sure I can structure this in a
>>> way to fit in with the object already works, but I???d rather not try if
>>> there is no interest in recovering the code.
>>> 
>> 
>> Sure, I see. I hope then you can get it working in a way that doesn't raise
>> any concern to Miller. I'll stress again that it can be useful at least for
>> the loop and sound effects library from *Soundtrack Pro* and *Logic Studio*
>> .
>> 
>> 
>>> it may not be too difficult to dump the extra info but that???s a separate
>>> issue.
>>> 
>> 
>> yeah, I had opened this one
>> <https://github.com/pure-data/pure-data/issues/586 <https://github.com/pure-data/pure-data/issues/586>>
>> 
>> cheers
> 
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>> https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev>
--------
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-dev/attachments/20190419/36148fb8/attachment-0001.html>


More information about the Pd-dev mailing list