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

PrevNext  Index
DateFri, 11 Feb 2011 01:22:35 +0100
From Arne Jacobs <[hidden] at gmail dot com>
To[hidden] at lists dot jackaudio dot org
Follow-Uptorbenh Re: [Jack-Devel] Jack "capsule/container" implementation?
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?

Cheers,

Arne
PrevNext  Index

1297383788.18972_0.ltw:2,a <4D54814B.7060103 at gmail dot com>