Re: [Audacity-devel] Reassigned spectrograms

[Steve t. F. <ste...@gm...>]

On 18 August 2015 at 22:17, Paul Licameli <pau...@gm...> wrote:
>
>
> On Tue, Aug 18, 2015 at 1:50 PM, Steve the Fiddle <ste...@gm...>
> wrote:
>>
>> On 18 August 2015 at 16:50, James Crook <cr...@in...> wrote:
>> > On 18/08/2015 15:45, Steve the Fiddle wrote:
>> >
>> >
>> >> If there is a draft proposal, including a draft for the GUI, before a
>> >> new feature is introduced, then many of these issues could be ironed
>> >> out before committing to code and the documentation crew could be
>> >> working on draft documentation while the feature is being developed.
>> >
>> > Yes, but we also have to be responsive to 'please try this branch'.
>> > Otherwise there is a very strong incentive to just merge the branch into
>> > master and be done.
>>
>> "Try this branch" is something that I like to do, time permitting, but
>> becomes difficult when there are so many changes happening in the main
>> repository.
>>
>> >
>> >>
>> >> A problem that you may not be aware of is that we can't document these
>> >> features until you have finished experimenting with different GUI
>> >> layouts. Could you give some indication of when that might be? We
>> >> should try to avoid making last minute changes immediately before
>> >> release if we can possibly help it.
>> >>
>> >> Steve
>> >
>> >
>> >
>> >
>> >
>> >
>> > Steve, we currently have
>> >
>> > ----
>> > Waveform
>> > Spectrogram
>> > View Settings
>> > ----
>> >
>> > How about instead:
>> >
>> > ---
>> > Waveform
>> > Spectrogram
>> > ---
>> > Waveform Preferences
>> > Spectrogram Preferences
>> > ---
>>
>> I think this hits on the main problem.
>> Are these globally acting preferences, or per-track options?
>>
>> Do we need to have every setting available as a per-track option?
>> How do per-track options interact with globally set default preferences?
>>
>> Making every possible setting a per-track option seems like overkill
>> to me, and I think will discourage experimentation because many user
>> will take one look and immediately give up.
>>
>
> I like making all of these settings more accessible than in the Preferences
> dialog.
>
> Steve objected to letting this dialog affect global Preferences.  Gale does
> not agree with the objection.
>
> That objection is not my reason for making them affect per-track settings,
> but if this objection carries, then they can affect only those settings.
>
> Some things, however, that I have not liked in previous versions are that
> changing the vertical scale limits of one track in Spectrogram or
> Spectrogram log(f) view always affects all other tracks, and that it was not
> easy to change the bottom of the dB scale for waveform views

When zoomed in on a waveform horizontally, we can change which part of
the waveform is displayed by scrolling left / right.

How about applying the same principal and provide vertical scrolling
(when applicable to any track  view), possibly adding a vertical
scroll bar on the right hand end of the track?

Steve


> (who thinks to
> click Interface preferences for that?), and if you did, it affected all
> tracks in that view, and also affected meters and sound-activated
> recordings.  These settings at least need to be more independent.
>
> And I reiterate, choice of spectrogam scale and spectrogram algorithm and
> enabling of spectral selection are three choices that should be decoupled.
> But the existing choices in the drop down (and in Tracks preferences for
> default) encoded combinations of these choices, and then only some of the
> possibilities.
>
> PRL
>
>> Steve
>>
>> >
>> > How about if apply button was gone and instead apply was applied after
>> > every
>> > preference change (when in this dialog)?  It is a little less efficient
>> > on
>> > menu space, but it does (a) make clearer that we are working with
>> > preferences for particular views and (b) makes it easier to experiment
>> > directly with changes.
>> >
>> > If you don't like this, or do but don't think it does enough, please
>> > give a
>> > counter proposal.  We want reassignment one way or another. There are
>> > clearly more settings for Spectrogram than we want to show directly in
>> > the
>> > top menu, so a counter-proposal does need to solve that.
>> >
>> > --James.
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>