8 Nov
2007
8 Nov
'07
9:22 a.m.
Krzysztof Foltman <wdev(a)foltman.com> writes:
Cool :)
I dont think such leveling can be defined. For example custom and generic
GUIs are at same level. Maybe there could be feature (extension)
sets. They may need to be defined in ttl file too.
Nedko Arnaudov wrote:
Exactly, it is host business to devide and apply such policies.
The point is that some plugins need *realtime
safe* memory allocation. I
need this functionality for lv2zynadd plugin (like arbitrary voices
count allocation) and for lv2dynparam plugin library internal operation
too.
I think it might be useful, to provide a "legal" workaround for "no
malloc and free during audio processing" rule. Also, because memory
services are provided by host, some hosts could "profile" dynamic memory
usage per plugin in a way similar to how Buzz measured CPU usage per
plugin. In Buzz community, end users were "policing" CPU usage and
underflow bugs - and it worked. Some hosts could use the same approach
for runtime allocations.
It would also facilitate sharing memory pools between plugins. On the
other hand, it might sometimes make sense to have separate pools per
plugin, to improve cache locality. Without hard data about performance
impact of shared pools it's hard to decide one way or the other. But if my opinion counts, please provide a LGPL-ed
reference
implementation (based on TLSF or anything else that works :) ) and test
suite as well :) So that host authors can simply use them to avoid bugs
and duplicated effort.
Well, I write GPLed code (not LGPL) but I may use LGPL library in
Zynjacku. I don't see much duplication effort on integrating same
existing memory allocator in different hosts. If it is suitable :S
However, I'm new here, so my opinion is probably
not very important
(well, some people may know my FSM series of Buzz machines - like
Infector or WahMan, but that was quite long ago).
I personally count ppl opinions based on what they say, not how "new"
are they. :)
This has lead
to this proposal. But if
there are no positive opinions for this extension I'll integrate it into
lv2dynparam extension.
In my opinion, both are independently useful and don't have much in
common - they shouldn't be merged. That reminds
me that LV2 may need a way to specify optional features
that interdepend. I.e. features (extensions) A and B are both optional
but if A is provided B is required.
I think the standard could introduce some "compliance levels", which are
based on sets of features supported.
Like, for example:
Level 1 host - just plain LV2 is supported
Level 2 host - must support dynparams, MIDI port and realtime safe
allocation features (that's how we can push for implementation of both
dynparams and safe alloc without merging the extensions!)
Level 3 host - like level 2 host, but must use a (hypothetical)
value-to-string and string-to-value conversion services in a plugin
where possible (ie. a plugin may provide a function to create a textual
representation of a float parameter value)
Level 4 host - must support some GUI extension (GTK+ GUI or some other,
not yet defined - like something out-of-process in a fashion similar to
DSSI) There should as well be some test suite to check if
the host's and
plugin's behaviour is valid. This way, we could avoid some problems
early VST2 had - like early NI plugins breaking on variable length
buffers (IIRC), or buggy processAdding/processReplacing implementations.
Unfortunately, I doubt test suite will happen at all. I think it will be
more like, plugin A version "n" is known to work well in host B, vesrion
"m". Also testing imposes kind of certification, i.e. work that IMHO
should be done by packager. see below...
It "kind of" works in other areas. Adopting
this kind of model might aid
end users in determining compatibility between their host and plugins,
and help programmers to prioritize their work.
I beleive this would would be needed only for plugins/host not packaged
for given Linux distribution (OS). This probably means third-party
commercial software. For binary packages, it is packager reponsibility
to ensure compatibility or document incompatibilities in packages.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>