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 danomatika@gmail.com 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 <msp@ucsd.edu mailto:msp@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@gmail.com mailto:danomatika@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@lists.iem.at mailto:Pd-dev@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/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/