Re: [Traverso-devel] Traverso audio backend & custom audio app

[Niklas Klügel]

Hey,

well, after playing around with traverso a bit, i must say that the  
interface
is quite fun to use. i really like it, the whole application feels  
snappy.


> I see.
> Had some discussion some time ago about time line, and how  
> important it was.
> From an application point of view, it's just frames (samples, but  
> everyone
> calls it frames).

yeah. but in other audio applications, the samples that are imported  
are tempo-analyzed
and automatically stretched to the main-tempo. this comes especially  
handy when you
have tempo changes within one song. tempo changes is something that  
should not be forgotten
but there is a difficulty in visualizing this. usually there is a  
visible grid in the background
of the tracks indicating bars or 1/4 bars etc. those usually have to  
be stretched or compressed.
in ableton live, tempo changes are indicated by this and an envelope  
over the master channel
which can be edited in realtime. so as soon as you dont work with raw  
sample-frames anymore but
use tempo and beat measures, you are forced to implement a  
comprehensive, flexible visualization
as well as general clip-tempo-annotation and interpolation to support  
the musical timing.

> The way how you display it to the user doesn't matter for the  
> application, so
> it might be very easy to add other timeline formats, specially if it's
> something that is used a lot!
> Is it used commonly in audio editors?

yes, of course.

> > > > but when you are doing more sophisticated editing you are forced
> > > > to rely on f/x envelopes and realtime-scopes only. there is no
> > > > way to get good/relyable visual feedback. and more importantly:
> > > > you get out of processing power very easily.
> > >
> > > I think I followed it up till here, could you please explain this
> > > in more detail ?
> >
> > it is quite simple: if you worked on rendered data as soon as  
> > possible
> > while editing
> > and this data is instantiated as new view,
> > you would get visual feedback like seeing peaks or frequency shifts.
> > if you
> > are cutting stuff up to 1/16 or 1/32 you hear that something might be
> > wrong
> > in your arrangement but you can't see for example which beats or
> > filtersweeps
> > you added are not tight.
>
>
> In other words, you apply effects directly to your samples, and make
> the 'effect' visible?
> That would be lovely, though hard to accomplish (too much cpu power  
> needed) on
> larger samples hehe.

well it doesn't have to be visible in a way that you see for example  
the timing
of a reverb added to an audio-clip. i think rendering the clip with
applied f/x and adding it to the trackview is enough. having both
time and frequency domain for samples visualized is enough.
and as i said, most audio calculations dont have to be realtime.


> I remember having written that somewhere long time ago. Where did  
> you read
> that exactly?

maybe that was an implication from my side ;)

> It's more about simplicity in the user interface, then anything  
> else, except
> for the code :-)
>
> My experience in recording and editing is very little. What did  
> bother me is
> that as soon as you open a multitrack audio recording and editing  
> software
> program, you see lot's of buttons, non-understandable routing  
> things, and
> after an hour or so I gave up, no sound, no nothing, crashes: no fun!
> (That was even before I discovered Ardour lol, but same thing  
> applies imo)

i dont think the traverso interface is particularily easy for  
beginners but i think it is
astounishingly (?) powerful compared to the interfaces i used. i  
really like it.
>

> In respect to not depending on external lib's, that's somewhat  
> true. But if
> it's very usefull, why not ?
> Traverso does depend now on slv2, fftw3, and as a result of those  
> to rasqal
> libs and many more.
> What I try to avoid is using lib's which functionality is allready  
> in Qt 4 for
> example, or with minor effort it can be integrated into Traverso.

well, clam is a _huge_ dependency, especially regarding the dependencies
clam has itself. but maybe this can be solved by moving the  
dependency to
traverso-plugins or something comparable.

http://mtg.upf.edu/clam/
>

> It would be great if Traverso get more developers, and even more,  
> not yet
> another sound editor that's just doing things slightly different,  
> but on
> the 'core level' they are the same ;-)

i agree, there are currently at least 6 sequencers for linux that are  
being actively
developed which all do to a certain degree the same. the worst is  
that they all
try to emulate the old skewl tape-deck style audio-editing from the 50s.



so long...
Niklas


> Greetings,
>
> Remon
>
> P.S.
> It's a bit hard to explain what I have in mind in 1-2 emails,  
> hopefully you
> got the idea.
>
>
> _______________________________________________
> Traverso-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/traverso-devel