On Tue, May 30, 2006 at 05:48:35PM -0400, Dave Robillard wrote:
The function we're talking about pulls this info
directly from the data
file (not eg from a loaded Port object which would have a const type
string). The library doesn't load all the stuff from the file into
memory (in which case the port type would be const), it just queries the
data file every time you ask for something (I won't attempt to enforce
my guess about what a host would want to cache in memory, that's the
hosts' decision).
In that case it would even make more sense to have the allocation
for this string done by the caller.
(Rationale being that an LV2 host can run an LV2
plugin keeping only the
actual DLL in memory (eg consuming far less memory than an equivalent
LADSPA plug), rather than having a bunch of data sitting around that may
not be useful)
The amount of data required for this in LADSPA is really trivial,
unless it's all created dynamically as is done in some plugins
(never understood the purpose of allocating a <type> and then
copying a constant into it - the thing already exists).
Also considering the amount of code required to get at the data,
and that you could encode up to 256 port types into a byte, inside
the .so, I wonder if there is any real gain.
I can understand that a host would not like to have all plugins
loaded all the time just for the purpose of e.g. presenting a list
to the user, but there are less convoluted solutions to that problem.
--
FA
Follie! Follie! Delirio vano e' questo!