On 2015-02-14 20:01, J. Liles wrote:
> On Sat, Feb 14, 2015 at 2:58 AM, <[email protected]> wrote:
> 
>> On Fri, Feb 13, 2015 at 10:19:56AM -0500, plutek infinity wrote:
> 
>>> 2. crossfades between overlapping regions are entirely manual? and
>>> there's no ability to make or adjust a fade-out entirely within the
>>> portion of an earlier region which is overlapped by a later region,
>>> right?
>> 
>> I've found that dragging fades doesn't always work the way I'd expect,
>> but it can be worked around by editing the history file. The format of the
>> history file is very simple and is one of non-timeline's best design features
>> IMO.
> 
> Yes, cross fades are manual, but they're easy enough to set by
> pointing the mouse and hitting F3 or F4.
> 
> As to overlap... yeah, if you have overlapping regions you may find
> it hard to point the mouse at the right one... Nobody said you had to
> have overlapping regions on the same track though (some NLE's don't
> allow overlaps at all, so all cross fades involve track juggling)...
> Or that you couldn't move things around, set the fades and move them
> back...
> 
> As to dragging--fades don't have handles in the GUI so I'm not sure
> what ya'll mean by that.

haha... "fake-drag"  ;)   holding down F3/F4 and moving the mouse seems like 
dragging the fade-point, once keyboard auto-repeat kicks in. when doing this on 
the fade-out of the first of two overlapping regions, the fade adjustment flips 
to the fade-out of the second region as soon as you hit the front edge of that 
region. to be expected, now that it's clear how this all works. i'll just spend 
some more time with it all, to see how quick/effective it is in edit-intensive 
sessions...
 
>>> 3. there's no ability to switch the waveform display to show logarithmic
>>> waveforms?... it's difficult to deal with low-level signals, it seems.
>> 
>> I usually deal with this by normalising low level signals. If you're
>> working with floating point files there's no problem with clipping as
>> long as the overall signal is below 0dBFS when it reaches the DAC.
>> 
> Agreed, normalization is the correct technique to use here. Not a problem.

>> The alternative is to edit the file with an external program (I use
>> mhwaveedit).

here's my common use-case: i'm trying to non-destructively (so, no mhwaveedit) 
edit material which is mostly at a healthy level, but edits are usually 
happening at points where low-level details (most commonly breaths taken by 
wind players) determine the edit points. without logarithmic wave display, i 
have to pretty much "fly blind" to edit around those sorts of details. sure, 
listening is key, but visual feedback is often helpful and makes things go more 
efficiently. i'm interested in your typical usage; does this sort of thing not 
figure in your usage of NON?

>>> 4. it is possible to drag the right edge of a region beyond the end of
>>> the existing audio. then, i can't find a way to snap the region end back
>>> to the original audio length. also, curiously, when the region is longer
>>> than the existing audio, i see repeats of the waveform, but increasingly
>>> squished horizontally with each repeat to the right. also, these repeats
>>> show at some zoom levels, but not at others, and nothing plays beyond
>>> the original audio. is this all intentional? 

>> I haven't seen this, but I do find the GUI sometimes gets into a strange
>> state. Ctrl-L to redraw usually fixes it.
> 
> If you find a display bug, please report it in the issue tracker.

ok... i was just checking to see that it wasn't intended behaviour.

> Non-looped regions should not be displaying any waveform beyond the end of 
> the clip.
> The reason regions can be longer than the clip they refer to is to allow 
> looping.

cool... makes sense. still, might a way to snap the region end back to the 
referenced file length be useful?
 
>>> 5. is there a way to change the zoom focus to something other than the
>>> play cursor?
> 
> Like what?

like where the mouse is, so one can zoom and look at or edit something without 
having to disturb the play cursor position. again, this may just be a matter of 
needing some time to get quick with a different way of working, but it seems a 
bit cumbersome to have to lose a play position just to deal with something else.

...appreciating this discussion about different working styles, and how they 
can be served (or not)!  :)

cheers!
.pltk.

cheers!
.pltk.
[sent from my stone tablet]

Reply via email to