On Sat, 2012-05-26 at 16:22 -0400, Paul Davis wrote: [...] > now, we can sit here and listen to you and dave mudslinging about the > sanity of this or that. you can, if you want, insist that everyone who > designed AU and RTAS and VST also don't understand audio programming. > maybe you're even right about that (though it seems less likely). but > that doesn't actually solve anything or move anything forward.
I mud-sling only about *behaviour* which is actively harmful to the adoption of open audio technology. I am indeed publicly critical of such behaviour, and proudly so. Unhelpful fallacious FUDdey nonsense will be exposed for what it is. The actual technical points, however, I largely agree with, and would be more than happy to incorporate said functionality into this malleable spec that was specifically designed to be able to improve this way (not that I or anyone actually has to in order for it to happen). This has been known and idly discussed and experimented with for years, nothing new, it just has never proved that important (if nobody needs it, now, it is not important, period). This buffer size stuff is *not* an error. It is simply work that is not done yet. That is all. I, as it happens, do personally need it now. Specifically, I just need a maximum buffer size (to allocate auxiliary buffers). Knowing there is more involved, however, I asked this list for input on what other restrictions are necessary. Input I am still actively looking for. So I can do it. Like, really actually do it. Myself. Right now. For example, is there any reasonable case where a plugin needs to specify an (arbitrary? minimum?) block size, or can the host's value provided at instantiation time (possibly required to be a power of 2) always be accommodated? If an arbitrary/minimum size must be specified, statically (highly preferable) or dynamically? Thanks, -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
