Re: [Traverso-devel] some observations

[plutek-infinity]

>From: Remon Sijrier <address@hidden>

>> i've been playing with the latest cvs here, and was intending to
>> migrate an album project to traverso, just to see how far we can push
>> things in terms of productivity -- trying to do real work is a great
>> way to discover stuff about a piece of software. unfortunately, i
>> quickly ran into some stumbling blocks, some of which are fatal for
>> the way i work.
>
>Thanks a lot for working this way with Traverso, it's indeed a valuable way to 
>discover shortcomings of a piece of software.
>
>>
>> here are my findings:
>>
>> *** lack of internal busses
>> *** lack of sends
>> *** lack of inserts
>> *** internal connections not exposed to jack
>>
>> these all relate to my need to run convolution reverb (using
>> jconv). there is currently no way to route tracks to external
>> processes, like jconv, except through the master output bus, and no
>> way to return signals to tracks within traverso except through the
>> hardware i/o. this could be remedied by simply exposing ins/outs to
>> jack not only at the master bus level, but also for each track. that
>> way, we could use an empty track as a bus and/or we could send/return
>> signals arbitrarily to external jack processes.
>>
>> or am i missing something?
>
>We're aware of the need for routing support, it's on the TODO list :-)
>Certain plugins are planned to be included by default, one of my favorites 
>would be jconv integration ;-)

yay!

>> *** lack of track automation
>>
>> we have gain envelopes for clips, but we cannot automate gain or pan
>> at the track level. this means that if i have some clips with gain
>> envelopes in a track and i want to fade over the duration of all the
>> clips, there's no way to do it except to try to adjust all the gain
>> envelopes progressively lower. yes, we do have per-clip global gain,
>> independant of the envelope (which is very nice), but it is still
>> difficult to implement gain changes which span clips or don't correspond to
>> clip boundaries.
>
>True, it's a matter of adding the graphics part of gain/pan envelopes for 
>Track, as it is technically possible allready, which in turn needs some 
>investigation on how and when to show this information to the user.
>
>> *** lack of track gain grouping
>>
>> say we have a group of instruments balanced against each other, and we
>> want to change the level *as a group*. this requires either track
>> grouping or routing through a submix bus, neither of which currently exist.
>
>Nicola: please don't cry ;-)
>
>> *** lack of plugin automation
>> *** can't choose pre/post fader for plugins
>>
>> *** rubberband-box clip selection
>>
>> it is currently very tedious to select large numbers of clips for a group.
>
><< S >> selects all clips.
>After reading some suggestions in the bug tracker I think it might end up like 
>this:
>
>< S > or < left mouse button > : (de)select clip
><< S >> : (de)select all clips in pointed track
>CTRL+ < A > (de)select all clips in Sheet
>[ S ] : rubber band selection.
>
>(Request for comments please on the above proposal)

yes... another possibility which occured to me this morning while
playing in traverso was this:

[ S ] : anything the mouse touches gets added to selection -- kind of
like "painting" your selection! (that's more in keeping with the
"jog-mouse-board" concept and is a bit more flexible than a
rubberband-box)

then maybe CTRL+ [ S ] could be rubberband (or the other way around)

>
>> *** split across all selected clips
>> *** drag ends of all selected clips
>>
>> any plans to implement other functions besides move and delete, for
>> clip groups?
>
>Copy also is there, what about changing the Gain of all clips at once, do you 
>have other things in mind?

gain would be useful. nothing else leaps to mind right now.

>Drag clip ends is a good one I think, split as well.

for dragging, we may need two variations:

1. all ends drag by the same amount, regardless of where they are
2. ends drag only as the cursor meets their timeline position
(i.e. all end-drags are done only if crossed by cursor movement -
although i suppose that can be simulated by a split then delete)

>Can you please add these to the bugtracker ?

sure.

>
>> anyways, the improvements already implemented recently are a huge step
>> forward, so i don't mean to be negative! i just found that, when it
>> came down to doing actual work on a project, i couldn't yet do it in
>> traverso.
>
>Of course not, it's just great you tried it out, and the feedback is hugely 
>appreciated! 
>We're aware of most of your findings, but it's good to be reminded, and to 
>know what people are still missing to make Traverso a real alternative to 
>others.
>Routing is obviously a big one that's missing, and also a problematic one to 
>implement right.
>
>>
>> cheers... and keep up the great work!
>
>Thanks, 
>
>Remon
>


-- 
.pltk.