[Jack-Devel] Just a thought: Sometimes...

Hi people!

A saying in maths is "Often it's easier to solve the generalized problem 
than the particular problem instance one is pondering" [paraphrased]. 
This post is just a incoherent(?) rambling on what could be the more 
general problem a tool like jack could solve and how the current use of 
jack is just one particular instance of that problem.

Jack is an awesome tool. It allows flexibility in audio routing (and 
more recently midi routing) between vastly different applications, 
services, and tools. But like Paul, and others, have noted, jack 
development with respect to new features has kind of stagnated. I want 
to chime in with a maybe fresh approach to thinking about what jack does 
and how the development of other useful abstractions (like CV ports, but 
also stuff like semantically grouping ports, etc.) could be facilitated.

Jack was initially developed exclusively for audio routing, albeit with 
some preparations for extending the buffer types. This has then done 
with jack midi. For other kind of data this model has become problematic 
though. There is one centralized code base which tries to be the 
solution for all things linux rt audo related. Often a more 
modular/extensible approach has proved to be more fruitful. A library 
which gives users and developers the opportunity to build their own 
abstractions/standards on top of the core set of features. This is also 
a little nod into the direction of LV2 which has its extension mechanism 
and in general to the UNIX philosophy of building small tools that work 
together in concert. The core tools should be flexible enough that new 
data types can be implemented independently of them. Maybe once they 
have proven to be useful they can be integrated into the core 
distribution or standardized in another way.

So coming back to the original question what is the more general 
problem: Jack really is a particular solution to a more general problem 
than just routing audio and midi: How to define and run a data flow 
graph of nodes of applications/services/tools with real time constraints 
on the transport and the execution of the nodes and how to constrain the 
data going over the edges of this graph in such a way that different 
apps/modules/services understand each other.

Maybe it makes sense to ponder if it is is possible to try and create a 
solution for the more general problem of just creating a generic 
transport and scheduling tool for a dataflow graph of nodes with 
realtime constraints. Maybe even relaxing the real time constraints and 
treating them as yet another specialization of the problem makes sense.

Of course there is always the danger of taking too much of a mouthful 
for the scope of a project. Something completely general with no 
specialization gets nothing useful done at all. So the question really 
becomes: what level of generality and what kind of abstractions are 
useful now and for future purposes which we are not even aware of yet.

Ideally such a tool would be flexible enough that the current jack API 
could be implemented as a special case thus providing backwards 
compatibility while at the same time being ready for the future.

Feel free to flame me :D

Flo

1369487290.14035_0.ltw:2,a <51A0B7BF.802 at gmx dot net>