[Traverso-devel] Re: Traverso-Routing etc /update

[Peter Hoppe]

Many thanks for your update! First, thanks very much for your efforts! 
Personally, I am just at the start of getting
into Traverso, so I can't really say much regards CLAM/Traverso integration. I 
had a little warning light pop up when I
heard "significant change" - something like that may require more close working 
together with the longer standing
Traverso devs. That's why I advise to wait for input from Remon or other long 
standing devs. Otherwise you may run the
risk of much hard work only to hear that it won't be integrated into Traverso. 
As I said before, I'm very new to the
project, that's why I can't share any more than my personal opinions and ideas.

I hope it's ok for you, if I share my personal opinion (concern) - I think that 
changing Traverso simply to accomodate
one software package would be a dead-end road. However, your comments sparked 
an idea for the future. Should traverso
devs talk about some sort of wider ranging API inbuilt into Traverso which can 
expose different Traverso internals (such
as cursor positioning, gain curves, audio clip positions etc.) to external 
applications? I know that LV2 exists, but (as
we have seen) it seems to be insufficient for closer integration such as 
Traverso/CLAM.

Several steps would be necessary for such API:

* Designing an API

* A library "libtraverso_connector" which implements the API. Devs from other 
projects would then bind this library into
their projects thus using this API to interface with Traverso.


I see strong advantages for this approach:

* Aggregation: Traverso can be easily integrated with other projects, thus 
giving it many more capabilities than the
traverso devs could achieve on their own.

* Accessibility: With a clear API it's easier for other devs to make their 
projects work with Traverso. People don't
need to know a lot about Traverso to develop using its features.

* Collaboration: Devs from other projects will give feedback about weaknesses 
in the API/Traverso which can be used to
improve Traverso. This is akin to 'test driven development' [1] where test 
cases are written before the software itself
is developed. We would get more feedback from a 'how to use Traverso' 
perspective. [2]

* Encapsulation: There are clear demarkation lines which protect Traverso's 
integrity. The API would integrate Traverso
with other projects without a single line of code being changed in Traverso.

Making changes in Traverso to directly integrate other projects would spell 
disaster in the long run, as it increases
Traverso's complexity to the point where any work on Traverso is next to 
impossible, especially as other projects would
like to be integrated as well. We would move towards the proverbial "big ball 
of mud" [3]. There should always be some
sort of clearly defined boundary between Traverso and other projects.

There's one disadvantage, in that it costs more time to first develop an API. 
Devs have to discuss and implement an API
first, before integration can happen (which can seem like a waste of time). 
But, once the API is implemented it can be
re-used in countless other projects. Of course - there will always be 
developments to the API, but these will be
generally easier. I think this stage is actually a good stage to think about 
such an API, because Traverso is still
relatively early in its development.

So, the long term benefits far outweigh this initial extra development. I 
generally think that the days of the large and
complex all-purpose applications are gone. Apps need to be able to connect to 
other apps. Complex apps are built by
conglomerating many simple components using different APIs as glue. Actually, 
much in nature works this way: Complex
components built from simple building blocks and connected via specialized 
protocols/components.

That's why I would think that if Traverso should be made to work with CLAM we 
should use this as an opportunity to
develop an an API first. This then would be implemented as a a library. The 
library would then be bound to a CLAM
component thus exposing Traverso to CLAM. The library could then also be 
re-used by other projects - for example midi
editors, synthesizer software, audio encoders/decoders, signaling frameworks 
and so on. So CLAM integration would serve
as a trail blazer for wider development. In that sense, if we simply change 
Traverso (solely) to integrate it with CLAM,
a great opportunity would be lost.

Well, I do hope that my comments don't feel like a cold shower to you. Your 
idea is brilliant and I hope a way can be
found to make the best of it, rather than just achieving some immediate 
short-term goal. Thanks very much for sharing!

What do others think?

P

--------------------

[1]: http://en.wikipedia.org/wiki/Test-driven_development
[2]: This has actually already happened - this thread is such feedback!
[3]: http://en.wikipedia.org/wiki/Big_ball_of_mud
     http://www.laputan.org/mud/mud.html