Re: [Jack-Devel] Jack "capsule/container" implementation?

On Fri, Feb 11, 2011 at 01:22:35AM +0100, Arne Jacobs wrote:
> On 10.02.2011 13:00, torbenh wrote:
> > On Wed, Feb 09, 2011 at 09:39:59PM -0500, jordan wrote:
> >> Hey Arne,
> >>
> >>> The library I had in mind would appear to the JACK server as a single
> >>> client, there would be no means to look inside it. Any JACK control
> >>> application (wether it be QJackCtl, patchage or any other) would only
> >>> see that client and would neither be able to change connections inside
> >>> that client nor to add or remove any of the "child" clients within that
> >>> client.
> >>
> >> Side-rooms defiently appear this way, their "child" clients cannot be
> >> viewed, nor modified by using patchage. the same goes for ingen.
> >>
> >> in both cases they appear as "simple" clients in your connections window.
> > 
> > ladish is still using jack.
> > no jack implementation scales to 100s of inprocess clients.
> > 
> > most of the code of jack deals with the interprocess cooperation.
> > all this code is not needed in a modular engine, because its all
> > residing inside the same process.
> > 
> >>
> >> ...
> >>
> >> Obviously your goal is more like What Paul is explaining about Ardour3 though.
> > 
> > yes. the problem space is pretty different from jacks problem.
> > i am not as pessimistic as paul, that jacks api wouldnt handle the
> > problem space, but the implementation would need to be radically
> > different.
> > 
> > in a modular engine you need to be able to deal with hundreds of
> > modules. it wouldnt scale to create a thread for any of these.
> > and the buffers need to be managed in a smarter way. 
> > 
> > because it must be implemented differently, i dont really see much value
> > in reusing jacks api for this. (main reason is that jacks api is C, and
> > i would implement a modular engine in c++)
> > 
> > 
> 
> Thanks for these thoughts...
> 
> Ok, the JACK APi might not be ideal for such a use case, but my main
> point is that it could make it much easier to reuse existing code. In
> theory you could take any (simple enough) JACK client and just make it a
> module of your app. Or you could take any module of the app (if it is
> not tied too deep to other things in the app) and make it a JACK client.
> 
> The question is just how many apps would use such a wrapper library?

given that most apps use LADSPA or LV2 for this very purpose, i dont
think this api would be very popular ;)


-- 
torben Hohn

1297424002.28865_0.ltw:2,a <20110211113255.GJ5550 at siel dot b>