On 09/01/2009 10:44 AM, Paul Davis wrote:
This is interesting info but imo the question is whether it is necessary
to completely emulate the AL system in order to enable AL like live
performance or is it more a case of taking their ui model and
integrating it with our existing apps to provide a similar experience
that AL users can easily grok? One of the things that AL users are
attached to is the ability to quickly get up and running. I think we
have a lot of that ground covered already but from a n00b pov it's a
daunting task to get started with a pure jack'ed setup using multiple
apps each designed for a specific purpose. Mostly because they have
been taught a unified approach from using the dominant monolithic
products like AL, Pro Tools, Logic etc.
I feel that cleanly integrating a sampler interface with existing apps
will provide a competitive Linux based solution.
However this raises the question of is the jack system flexible enough
to allow one app to control multiple apps asyncronously. Should a
controller app be pure midi/osc based and bypass jack completely so that
all integrated apps are just receiving trigger commands and dealing with
playback through jack independantly? This would still allow for jack
transport control and sync when required.
I guess the time stretching functionality of AL is built on the
synthesis engine but does it have a trade off for cpu cycles? In my
experience AL is incredibly stable. It would be interesting to know how
many people use the time stretching functionality in AL and if they
apply it across the board or just to sample based loops.
Is there another way to enable the time stretching on the fly?
BTW, Rui I will try to find some time to get an overview of qtractor
codebase as some of the work I intend to do for hydrogen may also apply
there since both apps are using qt4.
Boost Hardware Ltd
Linux-audio-user mailing list