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