I'd also be up for an equivalent format, maybe RF64 which looks like a 64-bit WAV: https://en.wikipedia.org/wiki/RF64 <https://en.wikipedia.org/wiki/RF64> I'm not sure yet what could be consisted the "standard" for this. Maybe we should look at what files are used by Max, Ableton, etc.
Our main requirements are capacity for long length / large file sizes and multi-channel. The new version of our project could then convert CAF files to something else, as long as it's equivalent. We have numerous pieces which use 24-bit 8 channel files over 20 minutes in length, so we definitely need the large file support. > On Apr 19, 2019, at 11:04 PM, Dan Wilcox <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> >>> 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 >>> [email protected] <mailto:[email protected]> >>> 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/> > > > -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
