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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun May 27 04:15:01 2012
This archive was generated by hypermail 2.1.8 : Sun May 27 2012 - 04:15:01 EEST