|
From: | Niklas Klügel |
Subject: | Re: [Traverso-devel] Re: Traverso-Routing etc |
Date: | Thu, 14 Aug 2008 08:48:44 +0200 |
User-agent: | Thunderbird 2.0.0.16 (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. P
Hey!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... Niklas
well, concerning LV2 only support I'd still go with clam because it supports ladspa and such stuff already (basicallya wrapped up CLAM-Processing and an additional class-loader) and I am sureLV2 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 existfour 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... Niklas
[Prev in Thread] | Current Thread | [Next in Thread] |