[Top][All Lists]

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

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

From: Remon Sijrier
Subject: Re: [Traverso-devel] Re: Traverso-Routing etc /update
Date: Tue, 19 Aug 2008 21:44:35 +0200
User-agent: KMail/1.9.9


Just to throw another library into the mix, naspro might be something to look 
at as well, though it might not make any sense from your pov.

I'll read your mails when my brain is somewhat more clear, and reply more in 
depth then.

Oh, another thing, Fons A. created some sort of rt multithreaded framework for 
his Aeolus iirc, which might be a very good candidate to look at as well.



> 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
> _______________________________________________
> Traverso-devel mailing list
> address@hidden

reply via email to

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