[LAU] The future of audio plugins ?

Jeremy Carter jeremy at jeremycarter.ca
Tue Oct 18 21:58:06 UTC 2016


Paul, a bit of optimism can go a long way. We could make stuff like this,
and the ones who don't want to agree on the standard can be left behind.

On Tue, Oct 18, 2016 at 5:55 PM, Paul Davis <paul at linuxaudiosystems.com>
wrote:

>
>
> On Tue, Oct 18, 2016 at 5:50 PM, jonetsu <jonetsu at teksavvy.com> wrote:
>
>> On Tue, 18 Oct 2016 17:28:37 -0400
>> Paul Davis <paul at linuxaudiosystems.com> wrote:
>>
>> > let me offer you a hint.
>>
>> Good !
>>
>> > what the plugins need to share are not messages but computer
>> > (analysis) data.
>>
>> So much for the hint.
>>
>> > normally (though not universally), when entities run inside a single
>> > process and need to share information, they do so by sharing access to
>> > memory.
>>
>> This is writing to say nothing.
>
>
> I'm not saying nothing. I'm trying to tell you that if you want a set of
> plugins that behave as an integrated whole, sharing data about the tracks
> they are processing and potentially using data from other tracks to adjust
> their own behaviour, then you need them to share *memory*, not exchange
> messages.
>
> There's effectively no chance that different plugin manufacturers will
> ever agree to a single standard for such a thing, so there's unlikely to be
> any "protocol" or "specification" for this. It is something that a single
> plugin company could do on their own, to notable effect.
>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20161018/1190be6d/attachment.html>


More information about the Linux-audio-user mailing list