[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Niklas Klügel
Subject: Re: [Traverso-devel] Re: Traverso-Routing etc
Date: Thu, 14 Aug 2008 08:48:44 +0200
User-agent: Thunderbird (X11/20080724)

Peter Hoppe schrieb:
Sounds good to me! What I meant was that it may be possible to use an LV2 
plugin as a bridge to CLAM, i.e. that plugin
would do all the interfacing with Traverso. Theoretically it would then be 
possible to connect Traverso and CLAM without
changing a single line of code in Traverso.

This would actually be quite elegant! All that would be required (to make 
Traverso work together with CLAM) would be to

* Write the plugin
* Offer it for download
* Users then would enable CLAM integration by copying the plugin to the place 
where traverso plugins are kept (Could be
done via installer software).

Of course, I do not even know whether my idea is correct - as I said earlier, 
my knowledge of LV2 plugins is quite
limited. It's just that word 'plugin' which triggered my imagination. Maybe, 
Traverso does need to be adjusted to work
with CLAM. But it would be really smart, if such a plugin can do all the 
integration without anybody having to change a
single line of code in Traverso.

Just my -2 c of opinion.


While this would certainly work with audio-signals only there are some problems regarding usability and technical issues: - you cannot route external audio in using this concept when using traverso only and you cannot record
a processed signal into a track/clip again.
- you get a bunch of ambiguities regarding the routing:
a) a plugin chain usually routes audio in a chain from one plugin-instance to the next, routing in parallel between the chain and being able to have a different processing flow in the clam network
   breaks with the "chain-notion".
b) therefore there is no ambiguity-free visual representation of the processing flow- not in the pluginchain nor in the clam-network c) you get even more ambiguity problems when you have "multi-channel" signals such as for control data (ie. which lv2 plugin routes the data out and in?) since every plugin instance in the chain would have to have the same amount of ins and outs, otherwise you'd end up with a network-like routing paradigm in the chain as well! - if you do not run the clam network in the traverso process you end up with mangling with inter-process communication issues; you'd roughly have to write something jack-alike and get some portability issues as well.

so all in all I won't consider this a feasible concept, although it would certainly work.

so long...

well, concerning LV2 only support I'd still go with clam because it supports ladspa and such stuff already (basically
a wrapped up CLAM-Processing and an additional class-loader) and I am sure
LV2 support is about to come anytime soon. More Midi-Support is about to be added as well along with the support of Control-data that can be arbitrary (i.e. multiple note events in a control-stream) and subpatches. Another plus is that alot of scopes for signals (time and frequency domain) and controls-widgets are already available. For editing the routing I'd basically just rip the NetworkEditor apart that comes with the clam-source.

The design itself isnt hackish the implementation might turn out to be hackish though. Currently there exist
four base-classes:
CLAMExtAudioIn (Traverso Audiodevice -> clam network)
CLAMExtAudioOut (clam network -> Traverso Audiodevice)
CLAMTraversoMasterBus (clam network main output -> Traverso renderbus)
CLAMTraversoTrack (Traverso Track -> clam network, homefully the other way around as well for recording internal audio)

Then there will be new Sheet class, the only modification that would be necessary to the original Traverso-source is in Track.* (leaving out additional commands for editing the network so traverso keeps track of the editing).

So long...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]