David Olofson <david@email-addr-hidden> writes:
> On Thursday 08 November 2007, Nedko Arnaudov wrote:
> [...]
>> The point is that some plugins need *realtime safe* memory
>> allocation.
>
> Well, yes; that part is quite obvious.
>
> What I meant was, if all the host provides is a pool of uniformly
> sized chunks that are allocated when the plugin is initialized, there
> doesn't seem to be much point in implementing it on the host side.
> The naïve host side implementatio would add exactly nothing, compared
> to plugins just allocating their own pools during initialization.
There is point when you have several dynparam plugins that all user
dynparam helper library requesting same sized chunks.
> A proper real time manager, with arbitrary chunk sizes, would be more
> motivated, as it adds functionality that plugins can't implement
> internally; namely a shared memory pool.
I'm not against it but I dont see use of it for lv2 zyn plugins /
lv2dynparam / zynjacku. Except for enum value strings that I plan to
make fixed (runtime) max size.
>> I
>> need this functionality for lv2zynadd plugin (like arbitrary voices
>> count allocation)
>
> The "standard" solution is to pre-allocate and pre-initialize voice
> structures for a fixed maximum polyphony.
>
> Obviously, this becomes troublesome with modular synths and the like,
> where the "voice structure" doesn't have a fixed size.
in zynadd, voices are not poliphony voices (they are called notes there)
but voice modules. zynadd is semi modular synth.
> One solution is to allocate the voice pool as a response to "program
> change" events. Of course, this makes the "programe change" operation
> non real time safe, but it usually is anyway, due to samples being
> loaded from disk and stuff. Many systems, both hardware and software,
> are based entirely on the idea that patch loading is part of
> setup/initialization, as that is often the only practical solution.
> It's really only entirely ROM based synths (or "small fixed sample
> set", in the case of software), virtual analog synths and the like
> that *can* implement real time safe "program change" at all.
One of ultimate goals of zynjacku is to make this happen with zyn
plugins. Patch loading involves lv2dynparam communication that is
realtime safe. It make take some time during which synth "parameters"
will be in intermediate state, but this will depend on cpu power and
preallocation size. Things that user has control of.
>> and for lv2dynparam plugin library internal
>> operation too.
>
> It needs to "regroup" internally as a response to certain parameter
> changes?
no idea what you mean by regroup, for each parameter, group or message
there are internal fixed size structures.
>> There were rumors in #lad that such functionality may be useful
>> without lv2dynparam extension.
>
> Well, yes; real time safe dynamic memory management can make life a
> lot easier for some types of plugins, and/or reduce memory
> requirements by having a shared pool. However, I think it needs to be
> more generic than just a pool of fixed size chunks for the "shared
> pool" part to be viable.
Point is whether arbitrary and fixed chunk allocators be in one
extension. I tend to think that they should be separate because
algorythms behind them are quite different and host may choose to
implement only one of them. Also most lock free algorithms are patented
so this can be point of host supporting only one feature set.
> [...]
>> 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. Of course plugin can
>> check this explicitly on instantiate and refuse to use feature, but
>> I'm not sure how vital is such approach.
>
> Haven't really thought about this... Isn't it just a matter of plugins
> and hosts listing *all* extensions? I mean, if you provide or ask for
> this feature A, but not feature B, you have a bug. An automatic
> validation tool would trap this right away - but of course,
> someone/something has to tell the *tool* about these extension
> interdependencies...
The point is how should you define that feature A depends on feature
B. LV2 in its current state, to my knowledge, does not treat this as
bug.
-- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 16:15:05 EET