[Top][All Lists]

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

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

From: Niklas Klügel
Subject: Re: [Traverso-devel] Re: Traverso-Routing etc /update
Date: Sat, 16 Aug 2008 11:04:43 +0200
User-agent: Thunderbird (X11/20080724)


short update:
- ext in/out is coded
- clam network player is done as well
- traverso-track/master bus processings for clam are in the works.
overall:  20-30%

I am currently working on the clam<->track stuff. the current design is planned to run as follows: rt audio thread of traverso does the usual process-stuff for tracks/clips. the data of the audio buses are then copied over to certain clam processings, then the network-player is executed to do all the mixing/fx-stuff and the output buffers of the clam network are moved over to the master audio-bus that is used by traverso. while this should work with minimal overhead i came to the conclusion that it
might be better to do it the other way around:
run the clam network in the rt audio thread and let the related processings call the process routines of the tracks. this might lead to a significant change in the traverso code but there are also significant gains: with inheriting and customizing some base-classes of clam you could do the following throughout the whole
signal path(s):
- latency compensation
- multithreading (i implemented an automagic dsp-network parallelizer some years ago,
so I could dig into that somewhen in the (far) future).

could we talk this through?

so long...

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.


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]