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

[Niklas Klügel]

Hey,

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...
Niklas

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
>
>
>
>
>   
> > 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...
> > Niklas
> >     
>
>