Re: The future of audio plugins ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 18 Oct 2016 17:55:13 -0400
Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:

> On Tue, Oct 18, 2016 at 5:50 PM, jonetsu <jonetsu@xxxxxxxxxxxx> wrote:
> 
> > On Tue, 18 Oct 2016 17:28:37 -0400
> > Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> 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.

I see it as protocol.  Whether it ends up using ZeroQ, network
connections, laser beams, whatever, does not matter inside the context
of this discussion. Hence, the size and type of bolts when the vehicle
is not even talked about.

> 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.

This is what I wrote earlier today.  Until there is an open source
project that deems making a parallel and/or until there is willingness
to open the protocol.  After all, many protocols being used daily
started like this.

But other do not, they start immediately in the open.  For instance the
upcoming protocol to configure devices for in-field validation of
updates to US Federal FIPS modules.  There are many factors that will
set the context whereas a protocol will be made privately first or
not.  In the audio world, specifically for the plugins, it might very
well be private to start with.

That people in the open source world would come with such a proposal
first hand... naaaah.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux