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

[Remon]

> Good Morning!

Ah, just to late for one too, well, good afternoon then :-)

> > As I see it the layer concept you mention is conceptually different
> > from what is an "AudioClip" in traverso, right?
>
> i think so, yes. basically because AudioClips would be depending on the
> content of other AudioClips. but that might be something that can be
> added without too much of a hassle.
> i haven't been able to play around with traverso, since i cannot
> build the development version (lots of undefined
> references to rasqal_* from slv2_query*). and the .bin file is linked
> against
> libc 2.4.

Oops, nothing I can do about that I think (except linking libc statically as 
well lol)
I've had little problems with KDevelop, things kinda work again I think, so 
finally the LV2_SUPPORT define can be uploaded, so you can add/remove LV2 
support at compile time :-)
(Ah, lv2 lib is also in Nic's repo, still it might be usefull to disable lv2 
by default, it's not released yet)

> > Though AudioClips can be stacked upon eachother, and the rendering
> > order, and curve preservation are things that work currently in
> > Traverso, slicing and re-aranging clips based on their place in the
> > hierarchical layer..... thats a different story :-) (If I get what
> > you're trying to make clear of course)
>
> i think the problem traverso has (as i can see it from the screenshots
> and by looking around the code) is that it has no connotation
> of beatmeasures and tempo which is essential as soon as you
> work on ie. beats.

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).
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?


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

> having multitrack-recording out of the box instantly is very good. but
> while i would
> use such a feature, i think, it would not be the main feature in the
> application i have
> in mind. i am more concerned about editing and arranging sample data
> in the way
> a computer allows me to do in pseudo-realtime (as soon as the
> audioclip can be rendered).
> i planned to have a dependency on clam for example lateron, i think
> that would
> break with traverso's policy of keeping everything simple and have no
> great dependencies.

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

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)

The simplicity is in the user interface, keep it clear, no tons of buttons, 
menu's, no information you don't need all the time.

But _behind_ that interface, there are numerous functions, most of them 
accessible by the keyboard/mouse combination (and lovely menu's too if you 
have too)!
Now, the lovely thing is, if you don't _need_ powerfull interface interaction, 
traverso doesn't try to force that on you!
But _if_ you need it, it's right there, and it's as powerfull as your 
imagination!

To summarize, users who just need to import an audio file, cut here and there, 
apply the fade in/out's and render, it will be easy to do so.
If you need tens or even a hundred tracks, it's as simple.
Want to do very precise editing actions, with 3 hands? No problem too!
(E.g.: Moving a clip is done by holding the D key [ D ] for short, the 
movement itself is done by the mouse. During that hold action, you can assign 
any key you want, including mouse buttons and scroll wheel to 'advanced' 
actions for the 'drag clip' action. Now, _that_ would be up to your 
imagination to what that would be! From simple "jump to next snap position 
too.... )


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.

> as you can see i am quite undecided yet :)

No problem!

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 ;-)

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.