[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Traverso-devel] Re: Traverso-Routing etc /update
[Traverso-devel] Re: Traverso-Routing etc /update
Sat, 16 Aug 2008 19:57:54 +0100
Thunderbird 184.108.40.206 (X11/20080505)
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
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'  where test
cases are written before the software itself
is developed. We would get more feedback from a 'how to use Traverso'
* 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" . 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
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?
: This has actually already happened - this thread is such feedback!
|[Prev in Thread]
||[Next in Thread]|
- [Traverso-devel] Re: Traverso-Routing etc /update,
Peter Hoppe <=