append record

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

append record

David Bailes-3
The rules appear to be:

Mono:
If any tracks are selected, append to the first, else append to the first track

Stereo:
If any tracks are selected, append to the first two tracks (whether they be mono, left, or right) that are selected, else append to the first two tracks (again, whether they be mono, left, or right).

So, for example if a project contains a mono track followed by a stereo track, and both tracks are either selected or not selected, then a stereo append record adds audio to the mono track and the left hand track of the stereo track.

Or if in a project two mono tracks are selected, then regardless of how far apart they are, a stereo append will add audio to these tracks.

Given that people will inevitably be append recording by accident when 2.2.0 comes out, the above results don't seem that desirable,

David.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
Only a problem (surely?) for people who are deliberately using stereo
and mono tracks in the same project.

Most users will be all mono or all stereo.
Those users who deliberately have stereo and mono in the same project  
presumably know enough to understand what is happening when they record.

These users who mix stereo and mono are also opting to do multi-track,
so they may in any case be using shift-record.


--James.




On 7/6/2017 9:50 AM, David Bailes wrote:

> The rules appear to be:
>
> Mono:
> If any tracks are selected, append to the first, else append to the first
> track
>
> Stereo:
> If any tracks are selected, append to the first two tracks (whether they be
> mono, left, or right) that are selected, else append to the first two
> tracks (again, whether they be mono, left, or right).
>
> So, for example if a project contains a mono track followed by a stereo
> track, and both tracks are either selected or not selected, then a stereo
> append record adds audio to the mono track and the left hand track of the
> stereo track.
>
> Or if in a project two mono tracks are selected, then regardless of how far
> apart they are, a stereo append will add audio to these tracks.
>
> Given that people will inevitably be append recording by accident when
> 2.2.0 comes out, the above results don't seem that desirable,
>
> David.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

David Bailes-3
On Thu, Jul 6, 2017 at 10:16 AM, James Crook <[hidden email]> wrote:
Only a problem (surely?) for people who are deliberately using stereo and mono tracks in the same project.

Most users will be all mono or all stereo.

I would have thought that stereo music, and mono speech would be quite common.

User append records in mono by accident, and adds to the left hand channel of the music track.
 
Those users who deliberately have stereo and mono in the same project  presumably know enough to understand what is happening when they record.

These users who mix stereo and mono are also opting to do multi-track, so they may in any case be using shift-record.

But after the change of default recording mode in 2.2.0, people will inevitably append record by accident.

David.
 


--James.





On 7/6/2017 9:50 AM, David Bailes wrote:
The rules appear to be:

Mono:
If any tracks are selected, append to the first, else append to the first
track

Stereo:
If any tracks are selected, append to the first two tracks (whether they be
mono, left, or right) that are selected, else append to the first two
tracks (again, whether they be mono, left, or right).

So, for example if a project contains a mono track followed by a stereo
track, and both tracks are either selected or not selected, then a stereo
append record adds audio to the mono track and the left hand track of the
stereo track.

Or if in a project two mono tracks are selected, then regardless of how far
apart they are, a stereo append will add audio to these tracks.

Given that people will inevitably be append recording by accident when
2.2.0 comes out, the above results don't seem that desirable,

David.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Stevethefiddle
In reply to this post by James Crook
On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
> Only a problem (surely?) for people who are deliberately using stereo and
> mono tracks in the same project.
>
> Most users will be all mono or all stereo.

I don't think that's a safe assumption. The user may have imported a
file(s), which could be mono or stereo. Recording is stereo by
default.

> Those users who deliberately have stereo and mono in the same project
> presumably know enough to understand what is happening when they record.
>
> These users who mix stereo and mono are also opting to do multi-track, so
> they may in any case be using shift-record.

It's certainly not a safe assumption that users wanting to multi-track
will understand what they are doing. Everyone that does multi-track
recording has to start somewhere, and it's quite likely that they will
start their multi-track career with Audacity (because Audacity is
"simple").

The behaviour is surprising, but is not a regression as append record
does the same in Audacity 2.1.3.

I agree with David that the current behaviour looks a bit weird, and
is exacerbated by the fact that most existing users will be caught out
by the reversal in 2.2.0 of Record and Append Record, but I don't
think it's clear what the most desirable behaviour would be. I can't
think  of any common cases where one would want to record one of two
channels into the left side of a stereo track.

If recording 3 tracks simultaneously (either with a multi-channel
sound card, or via Jack channel routing), then it probably would make
sense to record channel 1 into the mono track and channels 2 and 3
into the left/right channels of the stereo track respectively, but
that is not a common use case.

It may perhaps be helpful if we disallow recording into only the first
channel of a stereo track (?) though it is still not clear what we
should do if a user attempts to do so (either intentionally or
unintentionally). Some options are:

* Throw an error
* Pop-up a warning that informs and allows the user to continue or cancel,
* Record only into the first track,
* Record only into the first stereo track,
* Do as we do now,
* Record into both tracks with silence in the right channel of the stereo track,
* Record into both tracks with a mono mix in the first and stereo L/R
into the stereo track
* Something else.

When recording 4 or more channels simultaneously, the behaviour looks
totally reasonable imo. Example, when recording 4 channels, the input
channels record into the first 4 selected channels - if two stereo
tracks are selected, they record as:
In 1 -> Track 1 L
In 2 -> Track 1 R
In 3 -> Track 2 L
In 4 -> Track 2 R
In the absence of a "channel mapping" feature, I think this
multi-channel behaviour is 'correct'.

Given the 'correct' multi-channel behaviour, I'm inclined towards
either, not changing anything and accept that it can look a bit weird,
or, pop up a warning with a "don't show again" option that informs the
user what is happening.

Steve

>
>
> --James.
>
>
>
>
>
> On 7/6/2017 9:50 AM, David Bailes wrote:
>>
>> The rules appear to be:
>>
>> Mono:
>> If any tracks are selected, append to the first, else append to the first
>> track
>>
>> Stereo:
>> If any tracks are selected, append to the first two tracks (whether they
>> be
>> mono, left, or right) that are selected, else append to the first two
>> tracks (again, whether they be mono, left, or right).
>>
>> So, for example if a project contains a mono track followed by a stereo
>> track, and both tracks are either selected or not selected, then a stereo
>> append record adds audio to the mono track and the left hand track of the
>> stereo track.
>>
>> Or if in a project two mono tracks are selected, then regardless of how
>> far
>> apart they are, a stereo append will add audio to these tracks.
>>
>> Given that people will inevitably be append recording by accident when
>> 2.2.0 comes out, the above results don't seem that desirable,
>>
>> David.
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook

On 7/6/2017 11:18 AM, Steve the Fiddle wrote:

> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>> Only a problem (surely?) for people who are deliberately using stereo and
>> mono tracks in the same project.
>>
>> Most users will be all mono or all stereo.
> I don't think that's a safe assumption. The user may have imported a
> file(s), which could be mono or stereo. Recording is stereo by
> default.
>
>> Those users who deliberately have stereo and mono in the same project
>> presumably know enough to understand what is happening when they record.
>>
>> These users who mix stereo and mono are also opting to do multi-track, so
>> they may in any case be using shift-record.
> It's certainly not a safe assumption that users wanting to multi-track
> will understand what they are doing. Everyone that does multi-track
> recording has to start somewhere, and it's quite likely that they will
> start their multi-track career with Audacity (because Audacity is
> "simple").
>
> The behaviour is surprising, but is not a regression as append record
> does the same in Audacity 2.1.3.
>
> I agree with David that the current behaviour looks a bit weird, and
> is exacerbated by the fact that most existing users will be caught out
> by the reversal in 2.2.0 of Record and Append Record, but I don't
> think it's clear what the most desirable behaviour would be. I can't
> think  of any common cases where one would want to record one of two
> channels into the left side of a stereo track.
>
> If recording 3 tracks simultaneously (either with a multi-channel
> sound card, or via Jack channel routing), then it probably would make
> sense to record channel 1 into the mono track and channels 2 and 3
> into the left/right channels of the stereo track respectively, but
> that is not a common use case.
>
> It may perhaps be helpful if we disallow recording into only the first
> channel of a stereo track (?) though it is still not clear what we
> should do if a user attempts to do so (either intentionally or
> unintentionally). Some options are:
>
> * Throw an error
> * Pop-up a warning that informs and allows the user to continue or cancel,
> * Record only into the first track,
> * Record only into the first stereo track,
> * Do as we do now,
> * Record into both tracks with silence in the right channel of the stereo track,
> * Record into both tracks with a mono mix in the first and stereo L/R
> into the stereo track
> * Something else.
'Something else' could be to unselect (skip) a selected stereo track, if
recording would record mono into stereo.  Users who really do want to do
that can split the stereo into mono first (and join back up later).

I think it's not going to happen that often.

So, for example, if there is a mono track (A), then a stereo track
(B+C), then a mono track (D), and the user selects all, and then records
'in stereo', they record into A and D.

> When recording 4 or more channels simultaneously, the behaviour looks
> totally reasonable imo. Example, when recording 4 channels, the input
> channels record into the first 4 selected channels - if two stereo
> tracks are selected, they record as:
> In 1 -> Track 1 L
> In 2 -> Track 1 R
> In 3 -> Track 2 L
> In 4 -> Track 2 R
> In the absence of a "channel mapping" feature, I think this
> multi-channel behaviour is 'correct'.
>
> Given the 'correct' multi-channel behaviour, I'm inclined towards
> either, not changing anything and accept that it can look a bit weird,
> or, pop up a warning with a "don't show again" option that informs the
> user what is happening.

The proposed 'something else' would not disrupt that.


>
> Steve
>
>>
>> --James.
>>
>>
>>
>>
>>
>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>> The rules appear to be:
>>>
>>> Mono:
>>> If any tracks are selected, append to the first, else append to the first
>>> track
>>>
>>> Stereo:
>>> If any tracks are selected, append to the first two tracks (whether they
>>> be
>>> mono, left, or right) that are selected, else append to the first two
>>> tracks (again, whether they be mono, left, or right).
>>>
>>> So, for example if a project contains a mono track followed by a stereo
>>> track, and both tracks are either selected or not selected, then a stereo
>>> append record adds audio to the mono track and the left hand track of the
>>> stereo track.
>>>
>>> Or if in a project two mono tracks are selected, then regardless of how
>>> far
>>> apart they are, a stereo append will add audio to these tracks.
>>>
>>> Given that people will inevitably be append recording by accident when
>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>
>>> David.
>>>
>>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Stevethefiddle
On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:

>
> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>
>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>
>>> Only a problem (surely?) for people who are deliberately using stereo and
>>> mono tracks in the same project.
>>>
>>> Most users will be all mono or all stereo.
>>
>> I don't think that's a safe assumption. The user may have imported a
>> file(s), which could be mono or stereo. Recording is stereo by
>> default.
>>
>>> Those users who deliberately have stereo and mono in the same project
>>> presumably know enough to understand what is happening when they record.
>>>
>>> These users who mix stereo and mono are also opting to do multi-track, so
>>> they may in any case be using shift-record.
>>
>> It's certainly not a safe assumption that users wanting to multi-track
>> will understand what they are doing. Everyone that does multi-track
>> recording has to start somewhere, and it's quite likely that they will
>> start their multi-track career with Audacity (because Audacity is
>> "simple").
>>
>> The behaviour is surprising, but is not a regression as append record
>> does the same in Audacity 2.1.3.
>>
>> I agree with David that the current behaviour looks a bit weird, and
>> is exacerbated by the fact that most existing users will be caught out
>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>> think it's clear what the most desirable behaviour would be. I can't
>> think  of any common cases where one would want to record one of two
>> channels into the left side of a stereo track.
>>
>> If recording 3 tracks simultaneously (either with a multi-channel
>> sound card, or via Jack channel routing), then it probably would make
>> sense to record channel 1 into the mono track and channels 2 and 3
>> into the left/right channels of the stereo track respectively, but
>> that is not a common use case.
>>
>> It may perhaps be helpful if we disallow recording into only the first
>> channel of a stereo track (?) though it is still not clear what we
>> should do if a user attempts to do so (either intentionally or
>> unintentionally). Some options are:
>>
>> * Throw an error
>> * Pop-up a warning that informs and allows the user to continue or cancel,
>> * Record only into the first track,
>> * Record only into the first stereo track,
>> * Do as we do now,
>> * Record into both tracks with silence in the right channel of the stereo
>> track,
>> * Record into both tracks with a mono mix in the first and stereo L/R
>> into the stereo track
>> * Something else.
>
> 'Something else' could be to unselect (skip) a selected stereo track, if
> recording would record mono into stereo.  Users who really do want to do
> that can split the stereo into mono first (and join back up later).

So you are proposing a "rule":
"skip stereo track if only one channel will be recorded into it"
Is that right?

In which case, what happens in David's original example of recording 2
channels with one mono and one stereo track selected? Does it skip the
mono track and record into the stereo track, or record into the mono,
skip the stereo and create another mono, or something else?

What happens if (fringe case), recording 4 tracks, one mono, one
stereo then another mono?
What happens if (fringe case), recording 4 tracks, one stereo, one
mono, one stereo, 4 mono?

The good thing about the current behaviour is that the rule is very
simple in all cases - "use the first N channels", (where "N" is the
number of channels being recorded).

The down side is that it looks a bit weird in the specific case that
David cited.

Steve

>
> I think it's not going to happen that often.
>
> So, for example, if there is a mono track (A), then a stereo track (B+C),
> then a mono track (D), and the user selects all, and then records 'in
> stereo', they record into A and D.
>
>> When recording 4 or more channels simultaneously, the behaviour looks
>> totally reasonable imo. Example, when recording 4 channels, the input
>> channels record into the first 4 selected channels - if two stereo
>> tracks are selected, they record as:
>> In 1 -> Track 1 L
>> In 2 -> Track 1 R
>> In 3 -> Track 2 L
>> In 4 -> Track 2 R
>> In the absence of a "channel mapping" feature, I think this
>> multi-channel behaviour is 'correct'.
>>
>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>> either, not changing anything and accept that it can look a bit weird,
>> or, pop up a warning with a "don't show again" option that informs the
>> user what is happening.
>
>
> The proposed 'something else' would not disrupt that.
>
>
>
>>
>> Steve
>>
>>>
>>> --James.
>>>
>>>
>>>
>>>
>>>
>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>
>>>> The rules appear to be:
>>>>
>>>> Mono:
>>>> If any tracks are selected, append to the first, else append to the
>>>> first
>>>> track
>>>>
>>>> Stereo:
>>>> If any tracks are selected, append to the first two tracks (whether they
>>>> be
>>>> mono, left, or right) that are selected, else append to the first two
>>>> tracks (again, whether they be mono, left, or right).
>>>>
>>>> So, for example if a project contains a mono track followed by a stereo
>>>> track, and both tracks are either selected or not selected, then a
>>>> stereo
>>>> append record adds audio to the mono track and the left hand track of
>>>> the
>>>> stereo track.
>>>>
>>>> Or if in a project two mono tracks are selected, then regardless of how
>>>> far
>>>> apart they are, a stereo append will add audio to these tracks.
>>>>
>>>> Given that people will inevitably be append recording by accident when
>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>
>>>> David.
>>>>
>>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
On 7/6/2017 12:30 PM, Steve the Fiddle wrote:

> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>> Only a problem (surely?) for people who are deliberately using stereo and
>>>> mono tracks in the same project.
>>>>
>>>> Most users will be all mono or all stereo.
>>> I don't think that's a safe assumption. The user may have imported a
>>> file(s), which could be mono or stereo. Recording is stereo by
>>> default.
>>>
>>>> Those users who deliberately have stereo and mono in the same project
>>>> presumably know enough to understand what is happening when they record.
>>>>
>>>> These users who mix stereo and mono are also opting to do multi-track, so
>>>> they may in any case be using shift-record.
>>> It's certainly not a safe assumption that users wanting to multi-track
>>> will understand what they are doing. Everyone that does multi-track
>>> recording has to start somewhere, and it's quite likely that they will
>>> start their multi-track career with Audacity (because Audacity is
>>> "simple").
>>>
>>> The behaviour is surprising, but is not a regression as append record
>>> does the same in Audacity 2.1.3.
>>>
>>> I agree with David that the current behaviour looks a bit weird, and
>>> is exacerbated by the fact that most existing users will be caught out
>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>> think it's clear what the most desirable behaviour would be. I can't
>>> think  of any common cases where one would want to record one of two
>>> channels into the left side of a stereo track.
>>>
>>> If recording 3 tracks simultaneously (either with a multi-channel
>>> sound card, or via Jack channel routing), then it probably would make
>>> sense to record channel 1 into the mono track and channels 2 and 3
>>> into the left/right channels of the stereo track respectively, but
>>> that is not a common use case.
>>>
>>> It may perhaps be helpful if we disallow recording into only the first
>>> channel of a stereo track (?) though it is still not clear what we
>>> should do if a user attempts to do so (either intentionally or
>>> unintentionally). Some options are:
>>>
>>> * Throw an error
>>> * Pop-up a warning that informs and allows the user to continue or cancel,
>>> * Record only into the first track,
>>> * Record only into the first stereo track,
>>> * Do as we do now,
>>> * Record into both tracks with silence in the right channel of the stereo
>>> track,
>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>> into the stereo track
>>> * Something else.
>> 'Something else' could be to unselect (skip) a selected stereo track, if
>> recording would record mono into stereo.  Users who really do want to do
>> that can split the stereo into mono first (and join back up later).
> So you are proposing a "rule":
> "skip stereo track if only one channel will be recorded into it"
> Is that right?
Yes.  I've implemented it locally, but have not pushed it.


> In which case, what happens in David's original example of recording 2
> channels with one mono and one stereo track selected? Does it skip the
> mono track and record into the stereo track, or record into the mono,
> skip the stereo and create another mono, or something else?
It's like selecting a mono track with stereo recording enabled. Only the
mono track gets recorded into.
If they want the stereo track recorded into, they need to select it
alone, or have it first in the track list.


> What happens if (fringe case), recording 4 tracks, one mono, one
> stereo then another mono?
Works fine.  All four channels get recorded.

> What happens if (fringe case), recording 4 tracks, one stereo, one
> mono, one stereo, 4 mono?
(assuming all selected) Stereo gets recorded, then one mono, next stereo
not recorded to, first of the 4 mono gets recorded to.

> The good thing about the current behaviour is that the rule is very
> simple in all cases - "use the first N channels", (where "N" is the
> number of channels being recorded).
The same rule is used here, provided it does not lead to a
mono-in-stereo-track recording.

> The down side is that it looks a bit weird in the specific case that
> David cited.

Not just weird, but not useful.  It isn't helpful to have a stereo track
with one channel with more content than the other.


Note:
Attempting to record mono into a stereo track adds a new mono track, as
if no tracks had been selected.



>
> Steve
>
>> I think it's not going to happen that often.
>>
>> So, for example, if there is a mono track (A), then a stereo track (B+C),
>> then a mono track (D), and the user selects all, and then records 'in
>> stereo', they record into A and D.
>>
>>> When recording 4 or more channels simultaneously, the behaviour looks
>>> totally reasonable imo. Example, when recording 4 channels, the input
>>> channels record into the first 4 selected channels - if two stereo
>>> tracks are selected, they record as:
>>> In 1 -> Track 1 L
>>> In 2 -> Track 1 R
>>> In 3 -> Track 2 L
>>> In 4 -> Track 2 R
>>> In the absence of a "channel mapping" feature, I think this
>>> multi-channel behaviour is 'correct'.
>>>
>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>> either, not changing anything and accept that it can look a bit weird,
>>> or, pop up a warning with a "don't show again" option that informs the
>>> user what is happening.
>>
>> The proposed 'something else' would not disrupt that.
>>
>>
>>
>>> Steve
>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>> The rules appear to be:
>>>>>
>>>>> Mono:
>>>>> If any tracks are selected, append to the first, else append to the
>>>>> first
>>>>> track
>>>>>
>>>>> Stereo:
>>>>> If any tracks are selected, append to the first two tracks (whether they
>>>>> be
>>>>> mono, left, or right) that are selected, else append to the first two
>>>>> tracks (again, whether they be mono, left, or right).
>>>>>
>>>>> So, for example if a project contains a mono track followed by a stereo
>>>>> track, and both tracks are either selected or not selected, then a
>>>>> stereo
>>>>> append record adds audio to the mono track and the left hand track of
>>>>> the
>>>>> stereo track.
>>>>>
>>>>> Or if in a project two mono tracks are selected, then regardless of how
>>>>> far
>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>
>>>>> Given that people will inevitably be append recording by accident when
>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>
>>>>> David.
>>>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
Changing t1 < t0 to t1 <= t0 also makes a split line where we start an
append record.
So I have done that too (in my local branch).

                // less than or equal, not just less than, to ensure a
clip boundary.
                // when append recording.
                if (t1 <= t0) {

--James.

On 7/6/2017 12:50 PM, James Crook wrote:

> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>> Only a problem (surely?) for people who are deliberately using
>>>>> stereo and
>>>>> mono tracks in the same project.
>>>>>
>>>>> Most users will be all mono or all stereo.
>>>> I don't think that's a safe assumption. The user may have imported a
>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>> default.
>>>>
>>>>> Those users who deliberately have stereo and mono in the same project
>>>>> presumably know enough to understand what is happening when they
>>>>> record.
>>>>>
>>>>> These users who mix stereo and mono are also opting to do
>>>>> multi-track, so
>>>>> they may in any case be using shift-record.
>>>> It's certainly not a safe assumption that users wanting to multi-track
>>>> will understand what they are doing. Everyone that does multi-track
>>>> recording has to start somewhere, and it's quite likely that they will
>>>> start their multi-track career with Audacity (because Audacity is
>>>> "simple").
>>>>
>>>> The behaviour is surprising, but is not a regression as append record
>>>> does the same in Audacity 2.1.3.
>>>>
>>>> I agree with David that the current behaviour looks a bit weird, and
>>>> is exacerbated by the fact that most existing users will be caught out
>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>> think it's clear what the most desirable behaviour would be. I can't
>>>> think  of any common cases where one would want to record one of two
>>>> channels into the left side of a stereo track.
>>>>
>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>> sound card, or via Jack channel routing), then it probably would make
>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>> into the left/right channels of the stereo track respectively, but
>>>> that is not a common use case.
>>>>
>>>> It may perhaps be helpful if we disallow recording into only the first
>>>> channel of a stereo track (?) though it is still not clear what we
>>>> should do if a user attempts to do so (either intentionally or
>>>> unintentionally). Some options are:
>>>>
>>>> * Throw an error
>>>> * Pop-up a warning that informs and allows the user to continue or
>>>> cancel,
>>>> * Record only into the first track,
>>>> * Record only into the first stereo track,
>>>> * Do as we do now,
>>>> * Record into both tracks with silence in the right channel of the
>>>> stereo
>>>> track,
>>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>>> into the stereo track
>>>> * Something else.
>>> 'Something else' could be to unselect (skip) a selected stereo
>>> track, if
>>> recording would record mono into stereo.  Users who really do want
>>> to do
>>> that can split the stereo into mono first (and join back up later).
>> So you are proposing a "rule":
>> "skip stereo track if only one channel will be recorded into it"
>> Is that right?
> Yes.  I've implemented it locally, but have not pushed it.
>
>
>> In which case, what happens in David's original example of recording 2
>> channels with one mono and one stereo track selected? Does it skip the
>> mono track and record into the stereo track, or record into the mono,
>> skip the stereo and create another mono, or something else?
> It's like selecting a mono track with stereo recording enabled. Only
> the mono track gets recorded into.
> If they want the stereo track recorded into, they need to select it
> alone, or have it first in the track list.
>
>
>> What happens if (fringe case), recording 4 tracks, one mono, one
>> stereo then another mono?
> Works fine.  All four channels get recorded.
>
>> What happens if (fringe case), recording 4 tracks, one stereo, one
>> mono, one stereo, 4 mono?
> (assuming all selected) Stereo gets recorded, then one mono, next
> stereo not recorded to, first of the 4 mono gets recorded to.
>
>> The good thing about the current behaviour is that the rule is very
>> simple in all cases - "use the first N channels", (where "N" is the
>> number of channels being recorded).
> The same rule is used here, provided it does not lead to a
> mono-in-stereo-track recording.
>
>> The down side is that it looks a bit weird in the specific case that
>> David cited.
>
> Not just weird, but not useful.  It isn't helpful to have a stereo
> track with one channel with more content than the other.
>
>
> Note:
> Attempting to record mono into a stereo track adds a new mono track,
> as if no tracks had been selected.
>
>
>
>>
>> Steve
>>
>>> I think it's not going to happen that often.
>>>
>>> So, for example, if there is a mono track (A), then a stereo track
>>> (B+C),
>>> then a mono track (D), and the user selects all, and then records 'in
>>> stereo', they record into A and D.
>>>
>>>> When recording 4 or more channels simultaneously, the behaviour looks
>>>> totally reasonable imo. Example, when recording 4 channels, the input
>>>> channels record into the first 4 selected channels - if two stereo
>>>> tracks are selected, they record as:
>>>> In 1 -> Track 1 L
>>>> In 2 -> Track 1 R
>>>> In 3 -> Track 2 L
>>>> In 4 -> Track 2 R
>>>> In the absence of a "channel mapping" feature, I think this
>>>> multi-channel behaviour is 'correct'.
>>>>
>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>> either, not changing anything and accept that it can look a bit weird,
>>>> or, pop up a warning with a "don't show again" option that informs the
>>>> user what is happening.
>>>
>>> The proposed 'something else' would not disrupt that.
>>>
>>>
>>>
>>>> Steve
>>>>
>>>>> --James.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>> The rules appear to be:
>>>>>>
>>>>>> Mono:
>>>>>> If any tracks are selected, append to the first, else append to the
>>>>>> first
>>>>>> track
>>>>>>
>>>>>> Stereo:
>>>>>> If any tracks are selected, append to the first two tracks
>>>>>> (whether they
>>>>>> be
>>>>>> mono, left, or right) that are selected, else append to the first
>>>>>> two
>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>
>>>>>> So, for example if a project contains a mono track followed by a
>>>>>> stereo
>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>> stereo
>>>>>> append record adds audio to the mono track and the left hand
>>>>>> track of
>>>>>> the
>>>>>> stereo track.
>>>>>>
>>>>>> Or if in a project two mono tracks are selected, then regardless
>>>>>> of how
>>>>>> far
>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>
>>>>>> Given that people will inevitably be append recording by accident
>>>>>> when
>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>
>>>>>> David.
>>>>>>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Stevethefiddle
In reply to this post by James Crook
On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:

> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>
>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>
>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>
>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>
>>>>> Only a problem (surely?) for people who are deliberately using stereo
>>>>> and
>>>>> mono tracks in the same project.
>>>>>
>>>>> Most users will be all mono or all stereo.
>>>>
>>>> I don't think that's a safe assumption. The user may have imported a
>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>> default.
>>>>
>>>>> Those users who deliberately have stereo and mono in the same project
>>>>> presumably know enough to understand what is happening when they
>>>>> record.
>>>>>
>>>>> These users who mix stereo and mono are also opting to do multi-track,
>>>>> so
>>>>> they may in any case be using shift-record.
>>>>
>>>> It's certainly not a safe assumption that users wanting to multi-track
>>>> will understand what they are doing. Everyone that does multi-track
>>>> recording has to start somewhere, and it's quite likely that they will
>>>> start their multi-track career with Audacity (because Audacity is
>>>> "simple").
>>>>
>>>> The behaviour is surprising, but is not a regression as append record
>>>> does the same in Audacity 2.1.3.
>>>>
>>>> I agree with David that the current behaviour looks a bit weird, and
>>>> is exacerbated by the fact that most existing users will be caught out
>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>> think it's clear what the most desirable behaviour would be. I can't
>>>> think  of any common cases where one would want to record one of two
>>>> channels into the left side of a stereo track.
>>>>
>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>> sound card, or via Jack channel routing), then it probably would make
>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>> into the left/right channels of the stereo track respectively, but
>>>> that is not a common use case.
>>>>
>>>> It may perhaps be helpful if we disallow recording into only the first
>>>> channel of a stereo track (?) though it is still not clear what we
>>>> should do if a user attempts to do so (either intentionally or
>>>> unintentionally). Some options are:
>>>>
>>>> * Throw an error
>>>> * Pop-up a warning that informs and allows the user to continue or
>>>> cancel,
>>>> * Record only into the first track,
>>>> * Record only into the first stereo track,
>>>> * Do as we do now,
>>>> * Record into both tracks with silence in the right channel of the
>>>> stereo
>>>> track,
>>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>>> into the stereo track
>>>> * Something else.
>>>
>>> 'Something else' could be to unselect (skip) a selected stereo track, if
>>> recording would record mono into stereo.  Users who really do want to do
>>> that can split the stereo into mono first (and join back up later).
>>
>> So you are proposing a "rule":
>> "skip stereo track if only one channel will be recorded into it"
>> Is that right?
>
> Yes.  I've implemented it locally, but have not pushed it.
>
>
>> In which case, what happens in David's original example of recording 2
>> channels with one mono and one stereo track selected? Does it skip the
>> mono track and record into the stereo track, or record into the mono,
>> skip the stereo and create another mono, or something else?
>
> It's like selecting a mono track with stereo recording enabled. Only the
> mono track gets recorded into.
> If they want the stereo track recorded into, they need to select it alone,
> or have it first in the track list.
>
>
>> What happens if (fringe case), recording 4 tracks, one mono, one
>> stereo then another mono?
>
> Works fine.  All four channels get recorded.
>
>> What happens if (fringe case), recording 4 tracks, one stereo, one
>> mono, one stereo, 4 mono?
>
> (assuming all selected) Stereo gets recorded, then one mono, next stereo not
> recorded to, first of the 4 mono gets recorded to.

That looks as weird as David's original case, though less likely to happen.

Here's a nasty hidden trap for the unwary:

Recording stereo with:
Track 1 mono
Track 2 stereo
Track 3 stereo
Track 4 stereo (off screen)
Track 5 stereo (off screen)
Track 6 stereo (off screen)
Track 7 mono (off screen)
Track 8 stereo (off screen)
Track 9 mono (off screen)
Track 10 mono (off screen)
Track 11 stereo (off screen)
Track 12 mono (off screen)

On starting append record, the window scroll down to the bottom track,
so you can't see what is happening because both tracks that are being
recorded into are off-screen (not useful).

Scroll up to the top and you can see that the first track is being
recorded into.

If you are really on the ball and looking like a hawk, you may notice
that track 7 is also being recorded into.
If track 1 was selected, will track 7 still be recorded into if
recording was set to 2 channel stereo?

>
>> The good thing about the current behaviour is that the rule is very
>> simple in all cases - "use the first N channels", (where "N" is the
>> number of channels being recorded).
>
> The same rule is used here, provided it does not lead to a
> mono-in-stereo-track recording.
>
>> The down side is that it looks a bit weird in the specific case that
>> David cited.
>
>
> Not just weird, but not useful.  It isn't helpful to have a stereo track
> with one channel with more content than the other.

It's not common, but I've had several theatrical projects with
different audio clips in each channel, where I needed a sound effect
stage left or stage right. Yes I could have rendered silence in the
other channel, but I didn't need to because we have always allowed
different audio clips in each channel. Also, it can be handy to leave
"white space" so that it's easier to insert mono clips into the space.
Flexible ways of working is one of Audacity's greatest strength in the
technically challenging art of theatrical "sound design".

I don't recall ever needing to 'record' into one mono and half a
stereo track, and I agree that is not very useful, but it does avoid
hidden traps such as the example above.

>
>
> Note:
> Attempting to record mono into a stereo track adds a new mono track, as if
> no tracks had been selected.

In your not-yet-committed version I presume. So that is an exception
to the rule, whereas the current rule is always consistent.

Steve

>
>
>
>
>>
>> Steve
>>
>>> I think it's not going to happen that often.
>>>
>>> So, for example, if there is a mono track (A), then a stereo track (B+C),
>>> then a mono track (D), and the user selects all, and then records 'in
>>> stereo', they record into A and D.
>>>
>>>> When recording 4 or more channels simultaneously, the behaviour looks
>>>> totally reasonable imo. Example, when recording 4 channels, the input
>>>> channels record into the first 4 selected channels - if two stereo
>>>> tracks are selected, they record as:
>>>> In 1 -> Track 1 L
>>>> In 2 -> Track 1 R
>>>> In 3 -> Track 2 L
>>>> In 4 -> Track 2 R
>>>> In the absence of a "channel mapping" feature, I think this
>>>> multi-channel behaviour is 'correct'.
>>>>
>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>> either, not changing anything and accept that it can look a bit weird,
>>>> or, pop up a warning with a "don't show again" option that informs the
>>>> user what is happening.
>>>
>>>
>>> The proposed 'something else' would not disrupt that.
>>>
>>>
>>>
>>>> Steve
>>>>
>>>>> --James.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>
>>>>>> The rules appear to be:
>>>>>>
>>>>>> Mono:
>>>>>> If any tracks are selected, append to the first, else append to the
>>>>>> first
>>>>>> track
>>>>>>
>>>>>> Stereo:
>>>>>> If any tracks are selected, append to the first two tracks (whether
>>>>>> they
>>>>>> be
>>>>>> mono, left, or right) that are selected, else append to the first two
>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>
>>>>>> So, for example if a project contains a mono track followed by a
>>>>>> stereo
>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>> stereo
>>>>>> append record adds audio to the mono track and the left hand track of
>>>>>> the
>>>>>> stereo track.
>>>>>>
>>>>>> Or if in a project two mono tracks are selected, then regardless of
>>>>>> how
>>>>>> far
>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>
>>>>>> Given that people will inevitably be append recording by accident when
>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>
>>>>>> David.
>>>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
On 7/6/2017 1:40 PM, Steve the Fiddle wrote:

> On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:
>> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>> Only a problem (surely?) for people who are deliberately using stereo
>>>>>> and
>>>>>> mono tracks in the same project.
>>>>>>
>>>>>> Most users will be all mono or all stereo.
>>>>> I don't think that's a safe assumption. The user may have imported a
>>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>>> default.
>>>>>
>>>>>> Those users who deliberately have stereo and mono in the same project
>>>>>> presumably know enough to understand what is happening when they
>>>>>> record.
>>>>>>
>>>>>> These users who mix stereo and mono are also opting to do multi-track,
>>>>>> so
>>>>>> they may in any case be using shift-record.
>>>>> It's certainly not a safe assumption that users wanting to multi-track
>>>>> will understand what they are doing. Everyone that does multi-track
>>>>> recording has to start somewhere, and it's quite likely that they will
>>>>> start their multi-track career with Audacity (because Audacity is
>>>>> "simple").
>>>>>
>>>>> The behaviour is surprising, but is not a regression as append record
>>>>> does the same in Audacity 2.1.3.
>>>>>
>>>>> I agree with David that the current behaviour looks a bit weird, and
>>>>> is exacerbated by the fact that most existing users will be caught out
>>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>>> think it's clear what the most desirable behaviour would be. I can't
>>>>> think  of any common cases where one would want to record one of two
>>>>> channels into the left side of a stereo track.
>>>>>
>>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>>> sound card, or via Jack channel routing), then it probably would make
>>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>>> into the left/right channels of the stereo track respectively, but
>>>>> that is not a common use case.
>>>>>
>>>>> It may perhaps be helpful if we disallow recording into only the first
>>>>> channel of a stereo track (?) though it is still not clear what we
>>>>> should do if a user attempts to do so (either intentionally or
>>>>> unintentionally). Some options are:
>>>>>
>>>>> * Throw an error
>>>>> * Pop-up a warning that informs and allows the user to continue or
>>>>> cancel,
>>>>> * Record only into the first track,
>>>>> * Record only into the first stereo track,
>>>>> * Do as we do now,
>>>>> * Record into both tracks with silence in the right channel of the
>>>>> stereo
>>>>> track,
>>>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>>>> into the stereo track
>>>>> * Something else.
>>>> 'Something else' could be to unselect (skip) a selected stereo track, if
>>>> recording would record mono into stereo.  Users who really do want to do
>>>> that can split the stereo into mono first (and join back up later).
>>> So you are proposing a "rule":
>>> "skip stereo track if only one channel will be recorded into it"
>>> Is that right?
>> Yes.  I've implemented it locally, but have not pushed it.
>>
>>
>>> In which case, what happens in David's original example of recording 2
>>> channels with one mono and one stereo track selected? Does it skip the
>>> mono track and record into the stereo track, or record into the mono,
>>> skip the stereo and create another mono, or something else?
>> It's like selecting a mono track with stereo recording enabled. Only the
>> mono track gets recorded into.
>> If they want the stereo track recorded into, they need to select it alone,
>> or have it first in the track list.
>>
>>
>>> What happens if (fringe case), recording 4 tracks, one mono, one
>>> stereo then another mono?
>> Works fine.  All four channels get recorded.
>>
>>> What happens if (fringe case), recording 4 tracks, one stereo, one
>>> mono, one stereo, 4 mono?
>> (assuming all selected) Stereo gets recorded, then one mono, next stereo not
>> recorded to, first of the 4 mono gets recorded to.
> That looks as weird as David's original case, though less likely to happen.
>
> Here's a nasty hidden trap for the unwary:
>
> Recording stereo with:
> Track 1 mono
> Track 2 stereo
> Track 3 stereo
> Track 4 stereo (off screen)
> Track 5 stereo (off screen)
> Track 6 stereo (off screen)
> Track 7 mono (off screen)
> Track 8 stereo (off screen)
> Track 9 mono (off screen)
> Track 10 mono (off screen)
> Track 11 stereo (off screen)
> Track 12 mono (off screen)
>
> On starting append record, the window scroll down to the bottom track,
> so you can't see what is happening because both tracks that are being
> recorded into are off-screen (not useful).
>
> Scroll up to the top and you can see that the first track is being
> recorded into.
>
> If you are really on the ball and looking like a hawk, you may notice
> that track 7 is also being recorded into.
> If track 1 was selected, will track 7 still be recorded into if
> recording was set to 2 channel stereo?
With my code, no.  Only track 1 gets recorded into.

I am sure this exact situation with 7 stereo tracks and 3 interspersed
mono tracks will arise frequently (not).


So can we cut to the chase Steve?  What do you want to do?  Leave as is,
use my fix or revert the 'record append'?  Or do you have another
concrete proposal in mind?



>
>>> The good thing about the current behaviour is that the rule is very
>>> simple in all cases - "use the first N channels", (where "N" is the
>>> number of channels being recorded).
>> The same rule is used here, provided it does not lead to a
>> mono-in-stereo-track recording.
>>
>>> The down side is that it looks a bit weird in the specific case that
>>> David cited.
>>
>> Not just weird, but not useful.  It isn't helpful to have a stereo track
>> with one channel with more content than the other.
> It's not common, but I've had several theatrical projects with
> different audio clips in each channel, where I needed a sound effect
> stage left or stage right. Yes I could have rendered silence in the
> other channel, but I didn't need to because we have always allowed
> different audio clips in each channel. Also, it can be handy to leave
> "white space" so that it's easier to insert mono clips into the space.
> Flexible ways of working is one of Audacity's greatest strength in the
> technically challenging art of theatrical "sound design".
>
> I don't recall ever needing to 'record' into one mono and half a
> stereo track, and I agree that is not very useful, but it does avoid
> hidden traps such as the example above.
>
>>
>> Note:
>> Attempting to record mono into a stereo track adds a new mono track, as if
>> no tracks had been selected.
> In your not-yet-committed version I presume. So that is an exception
> to the rule, whereas the current rule is always consistent.
>
> Steve
>
>>
>>
>>
>>> Steve
>>>
>>>> I think it's not going to happen that often.
>>>>
>>>> So, for example, if there is a mono track (A), then a stereo track (B+C),
>>>> then a mono track (D), and the user selects all, and then records 'in
>>>> stereo', they record into A and D.
>>>>
>>>>> When recording 4 or more channels simultaneously, the behaviour looks
>>>>> totally reasonable imo. Example, when recording 4 channels, the input
>>>>> channels record into the first 4 selected channels - if two stereo
>>>>> tracks are selected, they record as:
>>>>> In 1 -> Track 1 L
>>>>> In 2 -> Track 1 R
>>>>> In 3 -> Track 2 L
>>>>> In 4 -> Track 2 R
>>>>> In the absence of a "channel mapping" feature, I think this
>>>>> multi-channel behaviour is 'correct'.
>>>>>
>>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>>> either, not changing anything and accept that it can look a bit weird,
>>>>> or, pop up a warning with a "don't show again" option that informs the
>>>>> user what is happening.
>>>>
>>>> The proposed 'something else' would not disrupt that.
>>>>
>>>>
>>>>
>>>>> Steve
>>>>>
>>>>>> --James.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>> The rules appear to be:
>>>>>>>
>>>>>>> Mono:
>>>>>>> If any tracks are selected, append to the first, else append to the
>>>>>>> first
>>>>>>> track
>>>>>>>
>>>>>>> Stereo:
>>>>>>> If any tracks are selected, append to the first two tracks (whether
>>>>>>> they
>>>>>>> be
>>>>>>> mono, left, or right) that are selected, else append to the first two
>>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>>
>>>>>>> So, for example if a project contains a mono track followed by a
>>>>>>> stereo
>>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>>> stereo
>>>>>>> append record adds audio to the mono track and the left hand track of
>>>>>>> the
>>>>>>> stereo track.
>>>>>>>
>>>>>>> Or if in a project two mono tracks are selected, then regardless of
>>>>>>> how
>>>>>>> far
>>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>>
>>>>>>> Given that people will inevitably be append recording by accident when
>>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>>
>>>>>>> David.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Stevethefiddle
On 6 July 2017 at 14:19, James Crook <[hidden email]> wrote:

> On 7/6/2017 1:40 PM, Steve the Fiddle wrote:
>>
>> On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:
>>>
>>> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>>>
>>>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>>>
>>>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>>>
>>>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> Only a problem (surely?) for people who are deliberately using stereo
>>>>>>> and
>>>>>>> mono tracks in the same project.
>>>>>>>
>>>>>>> Most users will be all mono or all stereo.
>>>>>>
>>>>>> I don't think that's a safe assumption. The user may have imported a
>>>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>>>> default.
>>>>>>
>>>>>>> Those users who deliberately have stereo and mono in the same project
>>>>>>> presumably know enough to understand what is happening when they
>>>>>>> record.
>>>>>>>
>>>>>>> These users who mix stereo and mono are also opting to do
>>>>>>> multi-track,
>>>>>>> so
>>>>>>> they may in any case be using shift-record.
>>>>>>
>>>>>> It's certainly not a safe assumption that users wanting to multi-track
>>>>>> will understand what they are doing. Everyone that does multi-track
>>>>>> recording has to start somewhere, and it's quite likely that they will
>>>>>> start their multi-track career with Audacity (because Audacity is
>>>>>> "simple").
>>>>>>
>>>>>> The behaviour is surprising, but is not a regression as append record
>>>>>> does the same in Audacity 2.1.3.
>>>>>>
>>>>>> I agree with David that the current behaviour looks a bit weird, and
>>>>>> is exacerbated by the fact that most existing users will be caught out
>>>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>>>> think it's clear what the most desirable behaviour would be. I can't
>>>>>> think  of any common cases where one would want to record one of two
>>>>>> channels into the left side of a stereo track.
>>>>>>
>>>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>>>> sound card, or via Jack channel routing), then it probably would make
>>>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>>>> into the left/right channels of the stereo track respectively, but
>>>>>> that is not a common use case.
>>>>>>
>>>>>> It may perhaps be helpful if we disallow recording into only the first
>>>>>> channel of a stereo track (?) though it is still not clear what we
>>>>>> should do if a user attempts to do so (either intentionally or
>>>>>> unintentionally). Some options are:
>>>>>>
>>>>>> * Throw an error
>>>>>> * Pop-up a warning that informs and allows the user to continue or
>>>>>> cancel,
>>>>>> * Record only into the first track,
>>>>>> * Record only into the first stereo track,
>>>>>> * Do as we do now,
>>>>>> * Record into both tracks with silence in the right channel of the
>>>>>> stereo
>>>>>> track,
>>>>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>>>>> into the stereo track
>>>>>> * Something else.
>>>>>
>>>>> 'Something else' could be to unselect (skip) a selected stereo track,
>>>>> if
>>>>> recording would record mono into stereo.  Users who really do want to
>>>>> do
>>>>> that can split the stereo into mono first (and join back up later).
>>>>
>>>> So you are proposing a "rule":
>>>> "skip stereo track if only one channel will be recorded into it"
>>>> Is that right?
>>>
>>> Yes.  I've implemented it locally, but have not pushed it.
>>>
>>>
>>>> In which case, what happens in David's original example of recording 2
>>>> channels with one mono and one stereo track selected? Does it skip the
>>>> mono track and record into the stereo track, or record into the mono,
>>>> skip the stereo and create another mono, or something else?
>>>
>>> It's like selecting a mono track with stereo recording enabled. Only the
>>> mono track gets recorded into.
>>> If they want the stereo track recorded into, they need to select it
>>> alone,
>>> or have it first in the track list.
>>>
>>>
>>>> What happens if (fringe case), recording 4 tracks, one mono, one
>>>> stereo then another mono?
>>>
>>> Works fine.  All four channels get recorded.
>>>
>>>> What happens if (fringe case), recording 4 tracks, one stereo, one
>>>> mono, one stereo, 4 mono?
>>>
>>> (assuming all selected) Stereo gets recorded, then one mono, next stereo
>>> not
>>> recorded to, first of the 4 mono gets recorded to.
>>
>> That looks as weird as David's original case, though less likely to
>> happen.
>>
>> Here's a nasty hidden trap for the unwary:
>>
>> Recording stereo with:
>> Track 1 mono
>> Track 2 stereo
>> Track 3 stereo
>> Track 4 stereo (off screen)
>> Track 5 stereo (off screen)
>> Track 6 stereo (off screen)
>> Track 7 mono (off screen)
>> Track 8 stereo (off screen)
>> Track 9 mono (off screen)
>> Track 10 mono (off screen)
>> Track 11 stereo (off screen)
>> Track 12 mono (off screen)
>>
>> On starting append record, the window scroll down to the bottom track,
>> so you can't see what is happening because both tracks that are being
>> recorded into are off-screen (not useful).
>>
>> Scroll up to the top and you can see that the first track is being
>> recorded into.
>>
>> If you are really on the ball and looking like a hawk, you may notice
>> that track 7 is also being recorded into.
>> If track 1 was selected, will track 7 still be recorded into if
>> recording was set to 2 channel stereo?
>
> With my code, no.  Only track 1 gets recorded into.

Good. We are in full agreement wrt the simple cases.

>
> I am sure this exact situation with 7 stereo tracks and 3 interspersed mono
> tracks will arise frequently (not).

:grin: No. of course this exact situation will be extremely rare, but
as David indicated, projects with a mix of mono and stereo tracks are
quite common. Large multi-track projects are probably also a lot more
common than suggested by user feedback (which is not surprisingly
dominated by our least able users).

Yes we need to do the least surprising thing and avoid weirdness for
simple projects, but also for more complex use cases.

We all agree that the current behaviour is not ideal in cases where
only the left channel of a stereo pair will be recorded, but I don't
think we yet have a really good solution.

What I don't like about the proposal you put forward James is that it
appears to do different things in different cases:
* Stereo recording into mono track => drops the right channel.
* Mono recording into stereo track => creates a new track with the
right number of channels.
* Stereo recording when more than one mono track => Splits the
recording across the first two mono tracks.

I agree that the proposed behaviour is fairly obvious if you know the
rule, but I'm not sure that the rule is necessarily obvious from the
observed behaviour. I do think that we need to help users with this as
I expect that very many our existing (millions of) users will be
initially caught out by the Record <=> Append Record swap.

>
>
> So can we cut to the chase Steve?  What do you want to do?  Leave as is, use
> my fix or revert the 'record append'?  Or do you have another concrete
> proposal in mind?

My current thinking is to retain the current behaviour and add a
"don't show again" style warning when actioning Append Record with the
wrong number of channels selected. Something along the lines of:

"Append Record:
No audio tracks selected.
"OK" will record x channels into track(s) y"
[OK]  [Cancel]

where "x" is the number of channels being recorded and "y" is the
track number(s) that will be recorded into.
If too many or not enough tracks are selected for the number of
channels being recorded, the first line of the message would change
accordingly.


The message should indicate (as the above does) that the warning is
occurring because the user has not selected the required number of
channels to record into. If the correct number of channels is
selected, regardless of mono/stereo, then the recording should go
ahead without warning (avoids bugging users that know what they are
doing).


Steve

>>
>>>> The good thing about the current behaviour is that the rule is very
>>>> simple in all cases - "use the first N channels", (where "N" is the
>>>> number of channels being recorded).
>>>
>>> The same rule is used here, provided it does not lead to a
>>> mono-in-stereo-track recording.
>>>
>>>> The down side is that it looks a bit weird in the specific case that
>>>> David cited.
>>>
>>>
>>> Not just weird, but not useful.  It isn't helpful to have a stereo track
>>> with one channel with more content than the other.
>>
>> It's not common, but I've had several theatrical projects with
>> different audio clips in each channel, where I needed a sound effect
>> stage left or stage right. Yes I could have rendered silence in the
>> other channel, but I didn't need to because we have always allowed
>> different audio clips in each channel. Also, it can be handy to leave
>> "white space" so that it's easier to insert mono clips into the space.
>> Flexible ways of working is one of Audacity's greatest strength in the
>> technically challenging art of theatrical "sound design".
>>
>> I don't recall ever needing to 'record' into one mono and half a
>> stereo track, and I agree that is not very useful, but it does avoid
>> hidden traps such as the example above.
>>
>>>
>>> Note:
>>> Attempting to record mono into a stereo track adds a new mono track, as
>>> if
>>> no tracks had been selected.
>>
>> In your not-yet-committed version I presume. So that is an exception
>> to the rule, whereas the current rule is always consistent.
>>
>> Steve
>>
>>>
>>>
>>>
>>>> Steve
>>>>
>>>>> I think it's not going to happen that often.
>>>>>
>>>>> So, for example, if there is a mono track (A), then a stereo track
>>>>> (B+C),
>>>>> then a mono track (D), and the user selects all, and then records 'in
>>>>> stereo', they record into A and D.
>>>>>
>>>>>> When recording 4 or more channels simultaneously, the behaviour looks
>>>>>> totally reasonable imo. Example, when recording 4 channels, the input
>>>>>> channels record into the first 4 selected channels - if two stereo
>>>>>> tracks are selected, they record as:
>>>>>> In 1 -> Track 1 L
>>>>>> In 2 -> Track 1 R
>>>>>> In 3 -> Track 2 L
>>>>>> In 4 -> Track 2 R
>>>>>> In the absence of a "channel mapping" feature, I think this
>>>>>> multi-channel behaviour is 'correct'.
>>>>>>
>>>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>>>> either, not changing anything and accept that it can look a bit weird,
>>>>>> or, pop up a warning with a "don't show again" option that informs the
>>>>>> user what is happening.
>>>>>
>>>>>
>>>>> The proposed 'something else' would not disrupt that.
>>>>>
>>>>>
>>>>>
>>>>>> Steve
>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>>>
>>>>>>>> The rules appear to be:
>>>>>>>>
>>>>>>>> Mono:
>>>>>>>> If any tracks are selected, append to the first, else append to the
>>>>>>>> first
>>>>>>>> track
>>>>>>>>
>>>>>>>> Stereo:
>>>>>>>> If any tracks are selected, append to the first two tracks (whether
>>>>>>>> they
>>>>>>>> be
>>>>>>>> mono, left, or right) that are selected, else append to the first
>>>>>>>> two
>>>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>>>
>>>>>>>> So, for example if a project contains a mono track followed by a
>>>>>>>> stereo
>>>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>>>> stereo
>>>>>>>> append record adds audio to the mono track and the left hand track
>>>>>>>> of
>>>>>>>> the
>>>>>>>> stereo track.
>>>>>>>>
>>>>>>>> Or if in a project two mono tracks are selected, then regardless of
>>>>>>>> how
>>>>>>>> far
>>>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>>>
>>>>>>>> Given that people will inevitably be append recording by accident
>>>>>>>> when
>>>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>>>
>>>>>>>> David.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Robert Hänggi
In reply to this post by James Crook
James, your fix for the split is good even if the behaviour stays the same.

It makes it possible to move the clip afterwards if it hasn't been
recorded into the right track.

How about a visual indication of which tracks would be affected in
case of append-record, i.e. which are actually armed for recording?

In other words, the first selected track could e.g. have a little
orange box somewhere With "CH1" in it.
If it is stereo, it would take "CH2" as well.
It could also be in the wave form itself, after the actual end of the
selected tracks.
Another possibility is a post-recording message box in case of fringe
cases that allows a last remapping.

Channel 1 --> [(Combo box with tracks at channel-level)]
Channel 2 --> ...

Not something for 2.2.0 of course.

Robert

On 06/07/2017, James Crook <[hidden email]> wrote:

> On 7/6/2017 1:40 PM, Steve the Fiddle wrote:
>> On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:
>>> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>>> Only a problem (surely?) for people who are deliberately using
>>>>>>> stereo
>>>>>>> and
>>>>>>> mono tracks in the same project.
>>>>>>>
>>>>>>> Most users will be all mono or all stereo.
>>>>>> I don't think that's a safe assumption. The user may have imported a
>>>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>>>> default.
>>>>>>
>>>>>>> Those users who deliberately have stereo and mono in the same
>>>>>>> project
>>>>>>> presumably know enough to understand what is happening when they
>>>>>>> record.
>>>>>>>
>>>>>>> These users who mix stereo and mono are also opting to do
>>>>>>> multi-track,
>>>>>>> so
>>>>>>> they may in any case be using shift-record.
>>>>>> It's certainly not a safe assumption that users wanting to
>>>>>> multi-track
>>>>>> will understand what they are doing. Everyone that does multi-track
>>>>>> recording has to start somewhere, and it's quite likely that they
>>>>>> will
>>>>>> start their multi-track career with Audacity (because Audacity is
>>>>>> "simple").
>>>>>>
>>>>>> The behaviour is surprising, but is not a regression as append record
>>>>>> does the same in Audacity 2.1.3.
>>>>>>
>>>>>> I agree with David that the current behaviour looks a bit weird, and
>>>>>> is exacerbated by the fact that most existing users will be caught
>>>>>> out
>>>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>>>> think it's clear what the most desirable behaviour would be. I can't
>>>>>> think  of any common cases where one would want to record one of two
>>>>>> channels into the left side of a stereo track.
>>>>>>
>>>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>>>> sound card, or via Jack channel routing), then it probably would make
>>>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>>>> into the left/right channels of the stereo track respectively, but
>>>>>> that is not a common use case.
>>>>>>
>>>>>> It may perhaps be helpful if we disallow recording into only the
>>>>>> first
>>>>>> channel of a stereo track (?) though it is still not clear what we
>>>>>> should do if a user attempts to do so (either intentionally or
>>>>>> unintentionally). Some options are:
>>>>>>
>>>>>> * Throw an error
>>>>>> * Pop-up a warning that informs and allows the user to continue or
>>>>>> cancel,
>>>>>> * Record only into the first track,
>>>>>> * Record only into the first stereo track,
>>>>>> * Do as we do now,
>>>>>> * Record into both tracks with silence in the right channel of the
>>>>>> stereo
>>>>>> track,
>>>>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>>>>> into the stereo track
>>>>>> * Something else.
>>>>> 'Something else' could be to unselect (skip) a selected stereo track,
>>>>> if
>>>>> recording would record mono into stereo.  Users who really do want to
>>>>> do
>>>>> that can split the stereo into mono first (and join back up later).
>>>> So you are proposing a "rule":
>>>> "skip stereo track if only one channel will be recorded into it"
>>>> Is that right?
>>> Yes.  I've implemented it locally, but have not pushed it.
>>>
>>>
>>>> In which case, what happens in David's original example of recording 2
>>>> channels with one mono and one stereo track selected? Does it skip the
>>>> mono track and record into the stereo track, or record into the mono,
>>>> skip the stereo and create another mono, or something else?
>>> It's like selecting a mono track with stereo recording enabled. Only the
>>> mono track gets recorded into.
>>> If they want the stereo track recorded into, they need to select it
>>> alone,
>>> or have it first in the track list.
>>>
>>>
>>>> What happens if (fringe case), recording 4 tracks, one mono, one
>>>> stereo then another mono?
>>> Works fine.  All four channels get recorded.
>>>
>>>> What happens if (fringe case), recording 4 tracks, one stereo, one
>>>> mono, one stereo, 4 mono?
>>> (assuming all selected) Stereo gets recorded, then one mono, next stereo
>>> not
>>> recorded to, first of the 4 mono gets recorded to.
>> That looks as weird as David's original case, though less likely to
>> happen.
>>
>> Here's a nasty hidden trap for the unwary:
>>
>> Recording stereo with:
>> Track 1 mono
>> Track 2 stereo
>> Track 3 stereo
>> Track 4 stereo (off screen)
>> Track 5 stereo (off screen)
>> Track 6 stereo (off screen)
>> Track 7 mono (off screen)
>> Track 8 stereo (off screen)
>> Track 9 mono (off screen)
>> Track 10 mono (off screen)
>> Track 11 stereo (off screen)
>> Track 12 mono (off screen)
>>
>> On starting append record, the window scroll down to the bottom track,
>> so you can't see what is happening because both tracks that are being
>> recorded into are off-screen (not useful).
>>
>> Scroll up to the top and you can see that the first track is being
>> recorded into.
>>
>> If you are really on the ball and looking like a hawk, you may notice
>> that track 7 is also being recorded into.
>> If track 1 was selected, will track 7 still be recorded into if
>> recording was set to 2 channel stereo?
> With my code, no.  Only track 1 gets recorded into.
>
> I am sure this exact situation with 7 stereo tracks and 3 interspersed
> mono tracks will arise frequently (not).
>
>
> So can we cut to the chase Steve?  What do you want to do?  Leave as is,
> use my fix or revert the 'record append'?  Or do you have another
> concrete proposal in mind?
>
>
>
>>
>>>> The good thing about the current behaviour is that the rule is very
>>>> simple in all cases - "use the first N channels", (where "N" is the
>>>> number of channels being recorded).
>>> The same rule is used here, provided it does not lead to a
>>> mono-in-stereo-track recording.
>>>
>>>> The down side is that it looks a bit weird in the specific case that
>>>> David cited.
>>>
>>> Not just weird, but not useful.  It isn't helpful to have a stereo track
>>> with one channel with more content than the other.
>> It's not common, but I've had several theatrical projects with
>> different audio clips in each channel, where I needed a sound effect
>> stage left or stage right. Yes I could have rendered silence in the
>> other channel, but I didn't need to because we have always allowed
>> different audio clips in each channel. Also, it can be handy to leave
>> "white space" so that it's easier to insert mono clips into the space.
>> Flexible ways of working is one of Audacity's greatest strength in the
>> technically challenging art of theatrical "sound design".
>>
>> I don't recall ever needing to 'record' into one mono and half a
>> stereo track, and I agree that is not very useful, but it does avoid
>> hidden traps such as the example above.
>>
>>>
>>> Note:
>>> Attempting to record mono into a stereo track adds a new mono track, as
>>> if
>>> no tracks had been selected.
>> In your not-yet-committed version I presume. So that is an exception
>> to the rule, whereas the current rule is always consistent.
>>
>> Steve
>>
>>>
>>>
>>>
>>>> Steve
>>>>
>>>>> I think it's not going to happen that often.
>>>>>
>>>>> So, for example, if there is a mono track (A), then a stereo track
>>>>> (B+C),
>>>>> then a mono track (D), and the user selects all, and then records 'in
>>>>> stereo', they record into A and D.
>>>>>
>>>>>> When recording 4 or more channels simultaneously, the behaviour looks
>>>>>> totally reasonable imo. Example, when recording 4 channels, the input
>>>>>> channels record into the first 4 selected channels - if two stereo
>>>>>> tracks are selected, they record as:
>>>>>> In 1 -> Track 1 L
>>>>>> In 2 -> Track 1 R
>>>>>> In 3 -> Track 2 L
>>>>>> In 4 -> Track 2 R
>>>>>> In the absence of a "channel mapping" feature, I think this
>>>>>> multi-channel behaviour is 'correct'.
>>>>>>
>>>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>>>> either, not changing anything and accept that it can look a bit
>>>>>> weird,
>>>>>> or, pop up a warning with a "don't show again" option that informs
>>>>>> the
>>>>>> user what is happening.
>>>>>
>>>>> The proposed 'something else' would not disrupt that.
>>>>>
>>>>>
>>>>>
>>>>>> Steve
>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>>> The rules appear to be:
>>>>>>>>
>>>>>>>> Mono:
>>>>>>>> If any tracks are selected, append to the first, else append to the
>>>>>>>> first
>>>>>>>> track
>>>>>>>>
>>>>>>>> Stereo:
>>>>>>>> If any tracks are selected, append to the first two tracks (whether
>>>>>>>> they
>>>>>>>> be
>>>>>>>> mono, left, or right) that are selected, else append to the first
>>>>>>>> two
>>>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>>>
>>>>>>>> So, for example if a project contains a mono track followed by a
>>>>>>>> stereo
>>>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>>>> stereo
>>>>>>>> append record adds audio to the mono track and the left hand track
>>>>>>>> of
>>>>>>>> the
>>>>>>>> stereo track.
>>>>>>>>
>>>>>>>> Or if in a project two mono tracks are selected, then regardless of
>>>>>>>> how
>>>>>>>> far
>>>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>>>
>>>>>>>> Given that people will inevitably be append recording by accident
>>>>>>>> when
>>>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>>>
>>>>>>>> David.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
In reply to this post by Stevethefiddle
Robert Hänggi wrote:
> James, your fix for the split is good even if the behaviour stays the same.
OK.  Done.
https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e


Steve, I don't see a warning as helpful.  As I see it the simple cases
are handled well, and the one real defect of the current approach is the
mono-in-stereo possibility.  If you want a solution that you really
like, best that you code and commit it.

If it is any use in so doing, this is the code I added to avoid putting
mono into a stereo track:

inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)

                // Don't record into one track of a stereo track...
                if( ((int)recordingTracks.size() >= recordingChannels
-1) &&
                    wt->GetLinked() )
                {   tt = it.Next();
                    continue;
                }

((int)recordingTracks.size() >= recordingChannels -1) checks if we are
assigning the last channel,
GetLinked() is checking if the channel assigned to is part of a stereo
track, it.Next advances past the partner channel too, and continue skips
assigning to this channel and moves on to examine later channels we
could assign to instead.

You'd probably set a flag instead and use the flag to pop up a dialog.

--James.



On 7/6/2017 3:15 PM, Steve the Fiddle wrote:

> On 6 July 2017 at 14:19, James Crook <[hidden email]> wrote:
>> On 7/6/2017 1:40 PM, Steve the Fiddle wrote:
>>> On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:
>>>> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>>>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>>>> Only a problem (surely?) for people who are deliberately using stereo
>>>>>>>> and
>>>>>>>> mono tracks in the same project.
>>>>>>>>
>>>>>>>> Most users will be all mono or all stereo.
>>>>>>> I don't think that's a safe assumption. The user may have imported a
>>>>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>>>>> default.
>>>>>>>
>>>>>>>> Those users who deliberately have stereo and mono in the same project
>>>>>>>> presumably know enough to understand what is happening when they
>>>>>>>> record.
>>>>>>>>
>>>>>>>> These users who mix stereo and mono are also opting to do
>>>>>>>> multi-track,
>>>>>>>> so
>>>>>>>> they may in any case be using shift-record.
>>>>>>> It's certainly not a safe assumption that users wanting to multi-track
>>>>>>> will understand what they are doing. Everyone that does multi-track
>>>>>>> recording has to start somewhere, and it's quite likely that they will
>>>>>>> start their multi-track career with Audacity (because Audacity is
>>>>>>> "simple").
>>>>>>>
>>>>>>> The behaviour is surprising, but is not a regression as append record
>>>>>>> does the same in Audacity 2.1.3.
>>>>>>>
>>>>>>> I agree with David that the current behaviour looks a bit weird, and
>>>>>>> is exacerbated by the fact that most existing users will be caught out
>>>>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>>>>> think it's clear what the most desirable behaviour would be. I can't
>>>>>>> think  of any common cases where one would want to record one of two
>>>>>>> channels into the left side of a stereo track.
>>>>>>>
>>>>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>>>>> sound card, or via Jack channel routing), then it probably would make
>>>>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>>>>> into the left/right channels of the stereo track respectively, but
>>>>>>> that is not a common use case.
>>>>>>>
>>>>>>> It may perhaps be helpful if we disallow recording into only the first
>>>>>>> channel of a stereo track (?) though it is still not clear what we
>>>>>>> should do if a user attempts to do so (either intentionally or
>>>>>>> unintentionally). Some options are:
>>>>>>>
>>>>>>> * Throw an error
>>>>>>> * Pop-up a warning that informs and allows the user to continue or
>>>>>>> cancel,
>>>>>>> * Record only into the first track,
>>>>>>> * Record only into the first stereo track,
>>>>>>> * Do as we do now,
>>>>>>> * Record into both tracks with silence in the right channel of the
>>>>>>> stereo
>>>>>>> track,
>>>>>>> * Record into both tracks with a mono mix in the first and stereo L/R
>>>>>>> into the stereo track
>>>>>>> * Something else.
>>>>>> 'Something else' could be to unselect (skip) a selected stereo track,
>>>>>> if
>>>>>> recording would record mono into stereo.  Users who really do want to
>>>>>> do
>>>>>> that can split the stereo into mono first (and join back up later).
>>>>> So you are proposing a "rule":
>>>>> "skip stereo track if only one channel will be recorded into it"
>>>>> Is that right?
>>>> Yes.  I've implemented it locally, but have not pushed it.
>>>>
>>>>
>>>>> In which case, what happens in David's original example of recording 2
>>>>> channels with one mono and one stereo track selected? Does it skip the
>>>>> mono track and record into the stereo track, or record into the mono,
>>>>> skip the stereo and create another mono, or something else?
>>>> It's like selecting a mono track with stereo recording enabled. Only the
>>>> mono track gets recorded into.
>>>> If they want the stereo track recorded into, they need to select it
>>>> alone,
>>>> or have it first in the track list.
>>>>
>>>>
>>>>> What happens if (fringe case), recording 4 tracks, one mono, one
>>>>> stereo then another mono?
>>>> Works fine.  All four channels get recorded.
>>>>
>>>>> What happens if (fringe case), recording 4 tracks, one stereo, one
>>>>> mono, one stereo, 4 mono?
>>>> (assuming all selected) Stereo gets recorded, then one mono, next stereo
>>>> not
>>>> recorded to, first of the 4 mono gets recorded to.
>>> That looks as weird as David's original case, though less likely to
>>> happen.
>>>
>>> Here's a nasty hidden trap for the unwary:
>>>
>>> Recording stereo with:
>>> Track 1 mono
>>> Track 2 stereo
>>> Track 3 stereo
>>> Track 4 stereo (off screen)
>>> Track 5 stereo (off screen)
>>> Track 6 stereo (off screen)
>>> Track 7 mono (off screen)
>>> Track 8 stereo (off screen)
>>> Track 9 mono (off screen)
>>> Track 10 mono (off screen)
>>> Track 11 stereo (off screen)
>>> Track 12 mono (off screen)
>>>
>>> On starting append record, the window scroll down to the bottom track,
>>> so you can't see what is happening because both tracks that are being
>>> recorded into are off-screen (not useful).
>>>
>>> Scroll up to the top and you can see that the first track is being
>>> recorded into.
>>>
>>> If you are really on the ball and looking like a hawk, you may notice
>>> that track 7 is also being recorded into.
>>> If track 1 was selected, will track 7 still be recorded into if
>>> recording was set to 2 channel stereo?
>> With my code, no.  Only track 1 gets recorded into.
> Good. We are in full agreement wrt the simple cases.
>
>> I am sure this exact situation with 7 stereo tracks and 3 interspersed mono
>> tracks will arise frequently (not).
> :grin: No. of course this exact situation will be extremely rare, but
> as David indicated, projects with a mix of mono and stereo tracks are
> quite common. Large multi-track projects are probably also a lot more
> common than suggested by user feedback (which is not surprisingly
> dominated by our least able users).
>
> Yes we need to do the least surprising thing and avoid weirdness for
> simple projects, but also for more complex use cases.
>
> We all agree that the current behaviour is not ideal in cases where
> only the left channel of a stereo pair will be recorded, but I don't
> think we yet have a really good solution.
>
> What I don't like about the proposal you put forward James is that it
> appears to do different things in different cases:
> * Stereo recording into mono track => drops the right channel.
> * Mono recording into stereo track => creates a new track with the
> right number of channels.
> * Stereo recording when more than one mono track => Splits the
> recording across the first two mono tracks.
>
> I agree that the proposed behaviour is fairly obvious if you know the
> rule, but I'm not sure that the rule is necessarily obvious from the
> observed behaviour. I do think that we need to help users with this as
> I expect that very many our existing (millions of) users will be
> initially caught out by the Record <=> Append Record swap.
>
>>
>> So can we cut to the chase Steve?  What do you want to do?  Leave as is, use
>> my fix or revert the 'record append'?  Or do you have another concrete
>> proposal in mind?
> My current thinking is to retain the current behaviour and add a
> "don't show again" style warning when actioning Append Record with the
> wrong number of channels selected. Something along the lines of:
>
> "Append Record:
> No audio tracks selected.
> "OK" will record x channels into track(s) y"
> [OK]  [Cancel]
>
> where "x" is the number of channels being recorded and "y" is the
> track number(s) that will be recorded into.
> If too many or not enough tracks are selected for the number of
> channels being recorded, the first line of the message would change
> accordingly.
>
>
> The message should indicate (as the above does) that the warning is
> occurring because the user has not selected the required number of
> channels to record into. If the correct number of channels is
> selected, regardless of mono/stereo, then the recording should go
> ahead without warning (avoids bugging users that know what they are
> doing).
>
>
> Steve
>
>>>>> The good thing about the current behaviour is that the rule is very
>>>>> simple in all cases - "use the first N channels", (where "N" is the
>>>>> number of channels being recorded).
>>>> The same rule is used here, provided it does not lead to a
>>>> mono-in-stereo-track recording.
>>>>
>>>>> The down side is that it looks a bit weird in the specific case that
>>>>> David cited.
>>>>
>>>> Not just weird, but not useful.  It isn't helpful to have a stereo track
>>>> with one channel with more content than the other.
>>> It's not common, but I've had several theatrical projects with
>>> different audio clips in each channel, where I needed a sound effect
>>> stage left or stage right. Yes I could have rendered silence in the
>>> other channel, but I didn't need to because we have always allowed
>>> different audio clips in each channel. Also, it can be handy to leave
>>> "white space" so that it's easier to insert mono clips into the space.
>>> Flexible ways of working is one of Audacity's greatest strength in the
>>> technically challenging art of theatrical "sound design".
>>>
>>> I don't recall ever needing to 'record' into one mono and half a
>>> stereo track, and I agree that is not very useful, but it does avoid
>>> hidden traps such as the example above.
>>>
>>>> Note:
>>>> Attempting to record mono into a stereo track adds a new mono track, as
>>>> if
>>>> no tracks had been selected.
>>> In your not-yet-committed version I presume. So that is an exception
>>> to the rule, whereas the current rule is always consistent.
>>>
>>> Steve
>>>
>>>>
>>>>
>>>>> Steve
>>>>>
>>>>>> I think it's not going to happen that often.
>>>>>>
>>>>>> So, for example, if there is a mono track (A), then a stereo track
>>>>>> (B+C),
>>>>>> then a mono track (D), and the user selects all, and then records 'in
>>>>>> stereo', they record into A and D.
>>>>>>
>>>>>>> When recording 4 or more channels simultaneously, the behaviour looks
>>>>>>> totally reasonable imo. Example, when recording 4 channels, the input
>>>>>>> channels record into the first 4 selected channels - if two stereo
>>>>>>> tracks are selected, they record as:
>>>>>>> In 1 -> Track 1 L
>>>>>>> In 2 -> Track 1 R
>>>>>>> In 3 -> Track 2 L
>>>>>>> In 4 -> Track 2 R
>>>>>>> In the absence of a "channel mapping" feature, I think this
>>>>>>> multi-channel behaviour is 'correct'.
>>>>>>>
>>>>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>>>>> either, not changing anything and accept that it can look a bit weird,
>>>>>>> or, pop up a warning with a "don't show again" option that informs the
>>>>>>> user what is happening.
>>>>>>
>>>>>> The proposed 'something else' would not disrupt that.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>> --James.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>>>> The rules appear to be:
>>>>>>>>>
>>>>>>>>> Mono:
>>>>>>>>> If any tracks are selected, append to the first, else append to the
>>>>>>>>> first
>>>>>>>>> track
>>>>>>>>>
>>>>>>>>> Stereo:
>>>>>>>>> If any tracks are selected, append to the first two tracks (whether
>>>>>>>>> they
>>>>>>>>> be
>>>>>>>>> mono, left, or right) that are selected, else append to the first
>>>>>>>>> two
>>>>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>>>>
>>>>>>>>> So, for example if a project contains a mono track followed by a
>>>>>>>>> stereo
>>>>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>>>>> stereo
>>>>>>>>> append record adds audio to the mono track and the left hand track
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> stereo track.
>>>>>>>>>
>>>>>>>>> Or if in a project two mono tracks are selected, then regardless of
>>>>>>>>> how
>>>>>>>>> far
>>>>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>>>>
>>>>>>>>> Given that people will inevitably be append recording by accident
>>>>>>>>> when
>>>>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>>>>
>>>>>>>>> David.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Robert Hänggi
On 06/07/2017, James Crook <[hidden email]> wrote:
> Robert Hänggi wrote:
>> James, your fix for the split is good even if the behaviour stays the
>> same.
> OK.  Done.
> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>

Thanks.
I think that's a reasonable change.

I don't yet fully understand the problem with "Energy displayed in
Spectrograms".
Does this happen for clips that do not fall into the grid of the
current spectrogram hop size?
I assume that this is coded in WaveClip.cpp, in other words a cache
and spectrogram for each clip individually.
I have to look how pre-/post padding is handled.

James is right and I think that micro-fades will at some point be inevitable.
However, I can't say if this remedies the issue.

Robert



>
> Steve, I don't see a warning as helpful.  As I see it the simple cases
> are handled well, and the one real defect of the current approach is the
> mono-in-stereo possibility.  If you want a solution that you really
> like, best that you code and commit it.
>
> If it is any use in so doing, this is the code I added to avoid putting
> mono into a stereo track:
>
> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)
>
>                 // Don't record into one track of a stereo track...
>                 if( ((int)recordingTracks.size() >= recordingChannels
> -1) &&
>                     wt->GetLinked() )
>                 {   tt = it.Next();
>                     continue;
>                 }
>
> ((int)recordingTracks.size() >= recordingChannels -1) checks if we are
> assigning the last channel,
> GetLinked() is checking if the channel assigned to is part of a stereo
> track, it.Next advances past the partner channel too, and continue skips
> assigning to this channel and moves on to examine later channels we
> could assign to instead.
>
> You'd probably set a flag instead and use the flag to pop up a dialog.
>
> --James.
>
>
>
> On 7/6/2017 3:15 PM, Steve the Fiddle wrote:
>> On 6 July 2017 at 14:19, James Crook <[hidden email]> wrote:
>>> On 7/6/2017 1:40 PM, Steve the Fiddle wrote:
>>>> On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:
>>>>> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>>>>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>>>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>>>>> Only a problem (surely?) for people who are deliberately using
>>>>>>>>> stereo
>>>>>>>>> and
>>>>>>>>> mono tracks in the same project.
>>>>>>>>>
>>>>>>>>> Most users will be all mono or all stereo.
>>>>>>>> I don't think that's a safe assumption. The user may have imported a
>>>>>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>>>>>> default.
>>>>>>>>
>>>>>>>>> Those users who deliberately have stereo and mono in the same
>>>>>>>>> project
>>>>>>>>> presumably know enough to understand what is happening when they
>>>>>>>>> record.
>>>>>>>>>
>>>>>>>>> These users who mix stereo and mono are also opting to do
>>>>>>>>> multi-track,
>>>>>>>>> so
>>>>>>>>> they may in any case be using shift-record.
>>>>>>>> It's certainly not a safe assumption that users wanting to
>>>>>>>> multi-track
>>>>>>>> will understand what they are doing. Everyone that does multi-track
>>>>>>>> recording has to start somewhere, and it's quite likely that they
>>>>>>>> will
>>>>>>>> start their multi-track career with Audacity (because Audacity is
>>>>>>>> "simple").
>>>>>>>>
>>>>>>>> The behaviour is surprising, but is not a regression as append
>>>>>>>> record
>>>>>>>> does the same in Audacity 2.1.3.
>>>>>>>>
>>>>>>>> I agree with David that the current behaviour looks a bit weird, and
>>>>>>>> is exacerbated by the fact that most existing users will be caught
>>>>>>>> out
>>>>>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>>>>>> think it's clear what the most desirable behaviour would be. I can't
>>>>>>>> think  of any common cases where one would want to record one of two
>>>>>>>> channels into the left side of a stereo track.
>>>>>>>>
>>>>>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>>>>>> sound card, or via Jack channel routing), then it probably would
>>>>>>>> make
>>>>>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>>>>>> into the left/right channels of the stereo track respectively, but
>>>>>>>> that is not a common use case.
>>>>>>>>
>>>>>>>> It may perhaps be helpful if we disallow recording into only the
>>>>>>>> first
>>>>>>>> channel of a stereo track (?) though it is still not clear what we
>>>>>>>> should do if a user attempts to do so (either intentionally or
>>>>>>>> unintentionally). Some options are:
>>>>>>>>
>>>>>>>> * Throw an error
>>>>>>>> * Pop-up a warning that informs and allows the user to continue or
>>>>>>>> cancel,
>>>>>>>> * Record only into the first track,
>>>>>>>> * Record only into the first stereo track,
>>>>>>>> * Do as we do now,
>>>>>>>> * Record into both tracks with silence in the right channel of the
>>>>>>>> stereo
>>>>>>>> track,
>>>>>>>> * Record into both tracks with a mono mix in the first and stereo
>>>>>>>> L/R
>>>>>>>> into the stereo track
>>>>>>>> * Something else.
>>>>>>> 'Something else' could be to unselect (skip) a selected stereo track,
>>>>>>> if
>>>>>>> recording would record mono into stereo.  Users who really do want to
>>>>>>> do
>>>>>>> that can split the stereo into mono first (and join back up later).
>>>>>> So you are proposing a "rule":
>>>>>> "skip stereo track if only one channel will be recorded into it"
>>>>>> Is that right?
>>>>> Yes.  I've implemented it locally, but have not pushed it.
>>>>>
>>>>>
>>>>>> In which case, what happens in David's original example of recording 2
>>>>>> channels with one mono and one stereo track selected? Does it skip the
>>>>>> mono track and record into the stereo track, or record into the mono,
>>>>>> skip the stereo and create another mono, or something else?
>>>>> It's like selecting a mono track with stereo recording enabled. Only
>>>>> the
>>>>> mono track gets recorded into.
>>>>> If they want the stereo track recorded into, they need to select it
>>>>> alone,
>>>>> or have it first in the track list.
>>>>>
>>>>>
>>>>>> What happens if (fringe case), recording 4 tracks, one mono, one
>>>>>> stereo then another mono?
>>>>> Works fine.  All four channels get recorded.
>>>>>
>>>>>> What happens if (fringe case), recording 4 tracks, one stereo, one
>>>>>> mono, one stereo, 4 mono?
>>>>> (assuming all selected) Stereo gets recorded, then one mono, next
>>>>> stereo
>>>>> not
>>>>> recorded to, first of the 4 mono gets recorded to.
>>>> That looks as weird as David's original case, though less likely to
>>>> happen.
>>>>
>>>> Here's a nasty hidden trap for the unwary:
>>>>
>>>> Recording stereo with:
>>>> Track 1 mono
>>>> Track 2 stereo
>>>> Track 3 stereo
>>>> Track 4 stereo (off screen)
>>>> Track 5 stereo (off screen)
>>>> Track 6 stereo (off screen)
>>>> Track 7 mono (off screen)
>>>> Track 8 stereo (off screen)
>>>> Track 9 mono (off screen)
>>>> Track 10 mono (off screen)
>>>> Track 11 stereo (off screen)
>>>> Track 12 mono (off screen)
>>>>
>>>> On starting append record, the window scroll down to the bottom track,
>>>> so you can't see what is happening because both tracks that are being
>>>> recorded into are off-screen (not useful).
>>>>
>>>> Scroll up to the top and you can see that the first track is being
>>>> recorded into.
>>>>
>>>> If you are really on the ball and looking like a hawk, you may notice
>>>> that track 7 is also being recorded into.
>>>> If track 1 was selected, will track 7 still be recorded into if
>>>> recording was set to 2 channel stereo?
>>> With my code, no.  Only track 1 gets recorded into.
>> Good. We are in full agreement wrt the simple cases.
>>
>>> I am sure this exact situation with 7 stereo tracks and 3 interspersed
>>> mono
>>> tracks will arise frequently (not).
>> :grin: No. of course this exact situation will be extremely rare, but
>> as David indicated, projects with a mix of mono and stereo tracks are
>> quite common. Large multi-track projects are probably also a lot more
>> common than suggested by user feedback (which is not surprisingly
>> dominated by our least able users).
>>
>> Yes we need to do the least surprising thing and avoid weirdness for
>> simple projects, but also for more complex use cases.
>>
>> We all agree that the current behaviour is not ideal in cases where
>> only the left channel of a stereo pair will be recorded, but I don't
>> think we yet have a really good solution.
>>
>> What I don't like about the proposal you put forward James is that it
>> appears to do different things in different cases:
>> * Stereo recording into mono track => drops the right channel.
>> * Mono recording into stereo track => creates a new track with the
>> right number of channels.
>> * Stereo recording when more than one mono track => Splits the
>> recording across the first two mono tracks.
>>
>> I agree that the proposed behaviour is fairly obvious if you know the
>> rule, but I'm not sure that the rule is necessarily obvious from the
>> observed behaviour. I do think that we need to help users with this as
>> I expect that very many our existing (millions of) users will be
>> initially caught out by the Record <=> Append Record swap.
>>
>>>
>>> So can we cut to the chase Steve?  What do you want to do?  Leave as is,
>>> use
>>> my fix or revert the 'record append'?  Or do you have another concrete
>>> proposal in mind?
>> My current thinking is to retain the current behaviour and add a
>> "don't show again" style warning when actioning Append Record with the
>> wrong number of channels selected. Something along the lines of:
>>
>> "Append Record:
>> No audio tracks selected.
>> "OK" will record x channels into track(s) y"
>> [OK]  [Cancel]
>>
>> where "x" is the number of channels being recorded and "y" is the
>> track number(s) that will be recorded into.
>> If too many or not enough tracks are selected for the number of
>> channels being recorded, the first line of the message would change
>> accordingly.
>>
>>
>> The message should indicate (as the above does) that the warning is
>> occurring because the user has not selected the required number of
>> channels to record into. If the correct number of channels is
>> selected, regardless of mono/stereo, then the recording should go
>> ahead without warning (avoids bugging users that know what they are
>> doing).
>>
>>
>> Steve
>>
>>>>>> The good thing about the current behaviour is that the rule is very
>>>>>> simple in all cases - "use the first N channels", (where "N" is the
>>>>>> number of channels being recorded).
>>>>> The same rule is used here, provided it does not lead to a
>>>>> mono-in-stereo-track recording.
>>>>>
>>>>>> The down side is that it looks a bit weird in the specific case that
>>>>>> David cited.
>>>>>
>>>>> Not just weird, but not useful.  It isn't helpful to have a stereo
>>>>> track
>>>>> with one channel with more content than the other.
>>>> It's not common, but I've had several theatrical projects with
>>>> different audio clips in each channel, where I needed a sound effect
>>>> stage left or stage right. Yes I could have rendered silence in the
>>>> other channel, but I didn't need to because we have always allowed
>>>> different audio clips in each channel. Also, it can be handy to leave
>>>> "white space" so that it's easier to insert mono clips into the space.
>>>> Flexible ways of working is one of Audacity's greatest strength in the
>>>> technically challenging art of theatrical "sound design".
>>>>
>>>> I don't recall ever needing to 'record' into one mono and half a
>>>> stereo track, and I agree that is not very useful, but it does avoid
>>>> hidden traps such as the example above.
>>>>
>>>>> Note:
>>>>> Attempting to record mono into a stereo track adds a new mono track, as
>>>>> if
>>>>> no tracks had been selected.
>>>> In your not-yet-committed version I presume. So that is an exception
>>>> to the rule, whereas the current rule is always consistent.
>>>>
>>>> Steve
>>>>
>>>>>
>>>>>
>>>>>> Steve
>>>>>>
>>>>>>> I think it's not going to happen that often.
>>>>>>>
>>>>>>> So, for example, if there is a mono track (A), then a stereo track
>>>>>>> (B+C),
>>>>>>> then a mono track (D), and the user selects all, and then records 'in
>>>>>>> stereo', they record into A and D.
>>>>>>>
>>>>>>>> When recording 4 or more channels simultaneously, the behaviour
>>>>>>>> looks
>>>>>>>> totally reasonable imo. Example, when recording 4 channels, the
>>>>>>>> input
>>>>>>>> channels record into the first 4 selected channels - if two stereo
>>>>>>>> tracks are selected, they record as:
>>>>>>>> In 1 -> Track 1 L
>>>>>>>> In 2 -> Track 1 R
>>>>>>>> In 3 -> Track 2 L
>>>>>>>> In 4 -> Track 2 R
>>>>>>>> In the absence of a "channel mapping" feature, I think this
>>>>>>>> multi-channel behaviour is 'correct'.
>>>>>>>>
>>>>>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>>>>>> either, not changing anything and accept that it can look a bit
>>>>>>>> weird,
>>>>>>>> or, pop up a warning with a "don't show again" option that informs
>>>>>>>> the
>>>>>>>> user what is happening.
>>>>>>>
>>>>>>> The proposed 'something else' would not disrupt that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>> --James.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>>>>> The rules appear to be:
>>>>>>>>>>
>>>>>>>>>> Mono:
>>>>>>>>>> If any tracks are selected, append to the first, else append to
>>>>>>>>>> the
>>>>>>>>>> first
>>>>>>>>>> track
>>>>>>>>>>
>>>>>>>>>> Stereo:
>>>>>>>>>> If any tracks are selected, append to the first two tracks
>>>>>>>>>> (whether
>>>>>>>>>> they
>>>>>>>>>> be
>>>>>>>>>> mono, left, or right) that are selected, else append to the first
>>>>>>>>>> two
>>>>>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>>>>>
>>>>>>>>>> So, for example if a project contains a mono track followed by a
>>>>>>>>>> stereo
>>>>>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>>>>>> stereo
>>>>>>>>>> append record adds audio to the mono track and the left hand track
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> stereo track.
>>>>>>>>>>
>>>>>>>>>> Or if in a project two mono tracks are selected, then regardless
>>>>>>>>>> of
>>>>>>>>>> how
>>>>>>>>>> far
>>>>>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>>>>>
>>>>>>>>>> Given that people will inevitably be append recording by accident
>>>>>>>>>> when
>>>>>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>>>>>
>>>>>>>>>> David.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Stevethefiddle
On 6 July 2017 at 17:16, Robert Hänggi <[hidden email]> wrote:

> On 06/07/2017, James Crook <[hidden email]> wrote:
>> Robert Hänggi wrote:
>>> James, your fix for the split is good even if the behaviour stays the
>>> same.
>> OK.  Done.
>> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>>
>
> Thanks.
> I think that's a reasonable change.
>
> I don't yet fully understand the problem with "Energy displayed in
> Spectrograms".
> Does this happen for clips that do not fall into the grid of the
> current spectrogram hop size?
> I assume that this is coded in WaveClip.cpp, in other words a cache
> and spectrogram for each clip individually.
> I have to look how pre-/post padding is handled.
>
> James is right and I think that micro-fades will at some point be inevitable.
> However, I can't say if this remedies the issue.
>
> Robert
>
>
>
>>
>> Steve, I don't see a warning as helpful.  As I see it the simple cases
>> are handled well,

Don't you think that in a multi-track project, there is a huge
assumption about Append Record doing "the right thing" unless a track
has explicitly been selected?

Taking David's example of one voice track and one music track. It is
very likely that the tracks will have different durations and it's a
50/50 chance that the "correct" track to append will be the first
track, so a 50/50 chance that Append Record will do the wrong thing
unless the correct track to append has been selected.

>> and the one real defect of the current approach is the
>> mono-in-stereo possibility.

If the user has selected the track(s) that they want to record into,
then should we assume that they want to append that/those tracks?

>>  If you want a solution that you really
>> like, best that you code and commit it.

I'm not a fan of relying on warning messages. When we feel that we
'need' a warning message, that is usually an indication that it is not
obvious for users, how to "do it right".

I'm hoping that someone may come up with a better idea of how to
handle this issue.

>>
>> If it is any use in so doing, this is the code I added to avoid putting
>> mono into a stereo track:
>>
>> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)
>>
>>                 // Don't record into one track of a stereo track...
>>                 if( ((int)recordingTracks.size() >= recordingChannels
>> -1) &&
>>                     wt->GetLinked() )
>>                 {   tt = it.Next();
>>                     continue;
>>                 }
>>
>> ((int)recordingTracks.size() >= recordingChannels -1) checks if we are
>> assigning the last channel,
>> GetLinked() is checking if the channel assigned to is part of a stereo
>> track, it.Next advances past the partner channel too, and continue skips
>> assigning to this channel and moves on to examine later channels we
>> could assign to instead.
>>
>> You'd probably set a flag instead and use the flag to pop up a dialog.

Thanks for the code tip.

Steve

>>
>> --James.
>>
>>
>>
>> On 7/6/2017 3:15 PM, Steve the Fiddle wrote:
>>> On 6 July 2017 at 14:19, James Crook <[hidden email]> wrote:
>>>> On 7/6/2017 1:40 PM, Steve the Fiddle wrote:
>>>>> On 6 July 2017 at 12:50, James Crook <[hidden email]> wrote:
>>>>>> On 7/6/2017 12:30 PM, Steve the Fiddle wrote:
>>>>>>> On 6 July 2017 at 12:14, James Crook <[hidden email]> wrote:
>>>>>>>> On 7/6/2017 11:18 AM, Steve the Fiddle wrote:
>>>>>>>>> On 6 July 2017 at 10:16, James Crook <[hidden email]> wrote:
>>>>>>>>>> Only a problem (surely?) for people who are deliberately using
>>>>>>>>>> stereo
>>>>>>>>>> and
>>>>>>>>>> mono tracks in the same project.
>>>>>>>>>>
>>>>>>>>>> Most users will be all mono or all stereo.
>>>>>>>>> I don't think that's a safe assumption. The user may have imported a
>>>>>>>>> file(s), which could be mono or stereo. Recording is stereo by
>>>>>>>>> default.
>>>>>>>>>
>>>>>>>>>> Those users who deliberately have stereo and mono in the same
>>>>>>>>>> project
>>>>>>>>>> presumably know enough to understand what is happening when they
>>>>>>>>>> record.
>>>>>>>>>>
>>>>>>>>>> These users who mix stereo and mono are also opting to do
>>>>>>>>>> multi-track,
>>>>>>>>>> so
>>>>>>>>>> they may in any case be using shift-record.
>>>>>>>>> It's certainly not a safe assumption that users wanting to
>>>>>>>>> multi-track
>>>>>>>>> will understand what they are doing. Everyone that does multi-track
>>>>>>>>> recording has to start somewhere, and it's quite likely that they
>>>>>>>>> will
>>>>>>>>> start their multi-track career with Audacity (because Audacity is
>>>>>>>>> "simple").
>>>>>>>>>
>>>>>>>>> The behaviour is surprising, but is not a regression as append
>>>>>>>>> record
>>>>>>>>> does the same in Audacity 2.1.3.
>>>>>>>>>
>>>>>>>>> I agree with David that the current behaviour looks a bit weird, and
>>>>>>>>> is exacerbated by the fact that most existing users will be caught
>>>>>>>>> out
>>>>>>>>> by the reversal in 2.2.0 of Record and Append Record, but I don't
>>>>>>>>> think it's clear what the most desirable behaviour would be. I can't
>>>>>>>>> think  of any common cases where one would want to record one of two
>>>>>>>>> channels into the left side of a stereo track.
>>>>>>>>>
>>>>>>>>> If recording 3 tracks simultaneously (either with a multi-channel
>>>>>>>>> sound card, or via Jack channel routing), then it probably would
>>>>>>>>> make
>>>>>>>>> sense to record channel 1 into the mono track and channels 2 and 3
>>>>>>>>> into the left/right channels of the stereo track respectively, but
>>>>>>>>> that is not a common use case.
>>>>>>>>>
>>>>>>>>> It may perhaps be helpful if we disallow recording into only the
>>>>>>>>> first
>>>>>>>>> channel of a stereo track (?) though it is still not clear what we
>>>>>>>>> should do if a user attempts to do so (either intentionally or
>>>>>>>>> unintentionally). Some options are:
>>>>>>>>>
>>>>>>>>> * Throw an error
>>>>>>>>> * Pop-up a warning that informs and allows the user to continue or
>>>>>>>>> cancel,
>>>>>>>>> * Record only into the first track,
>>>>>>>>> * Record only into the first stereo track,
>>>>>>>>> * Do as we do now,
>>>>>>>>> * Record into both tracks with silence in the right channel of the
>>>>>>>>> stereo
>>>>>>>>> track,
>>>>>>>>> * Record into both tracks with a mono mix in the first and stereo
>>>>>>>>> L/R
>>>>>>>>> into the stereo track
>>>>>>>>> * Something else.
>>>>>>>> 'Something else' could be to unselect (skip) a selected stereo track,
>>>>>>>> if
>>>>>>>> recording would record mono into stereo.  Users who really do want to
>>>>>>>> do
>>>>>>>> that can split the stereo into mono first (and join back up later).
>>>>>>> So you are proposing a "rule":
>>>>>>> "skip stereo track if only one channel will be recorded into it"
>>>>>>> Is that right?
>>>>>> Yes.  I've implemented it locally, but have not pushed it.
>>>>>>
>>>>>>
>>>>>>> In which case, what happens in David's original example of recording 2
>>>>>>> channels with one mono and one stereo track selected? Does it skip the
>>>>>>> mono track and record into the stereo track, or record into the mono,
>>>>>>> skip the stereo and create another mono, or something else?
>>>>>> It's like selecting a mono track with stereo recording enabled. Only
>>>>>> the
>>>>>> mono track gets recorded into.
>>>>>> If they want the stereo track recorded into, they need to select it
>>>>>> alone,
>>>>>> or have it first in the track list.
>>>>>>
>>>>>>
>>>>>>> What happens if (fringe case), recording 4 tracks, one mono, one
>>>>>>> stereo then another mono?
>>>>>> Works fine.  All four channels get recorded.
>>>>>>
>>>>>>> What happens if (fringe case), recording 4 tracks, one stereo, one
>>>>>>> mono, one stereo, 4 mono?
>>>>>> (assuming all selected) Stereo gets recorded, then one mono, next
>>>>>> stereo
>>>>>> not
>>>>>> recorded to, first of the 4 mono gets recorded to.
>>>>> That looks as weird as David's original case, though less likely to
>>>>> happen.
>>>>>
>>>>> Here's a nasty hidden trap for the unwary:
>>>>>
>>>>> Recording stereo with:
>>>>> Track 1 mono
>>>>> Track 2 stereo
>>>>> Track 3 stereo
>>>>> Track 4 stereo (off screen)
>>>>> Track 5 stereo (off screen)
>>>>> Track 6 stereo (off screen)
>>>>> Track 7 mono (off screen)
>>>>> Track 8 stereo (off screen)
>>>>> Track 9 mono (off screen)
>>>>> Track 10 mono (off screen)
>>>>> Track 11 stereo (off screen)
>>>>> Track 12 mono (off screen)
>>>>>
>>>>> On starting append record, the window scroll down to the bottom track,
>>>>> so you can't see what is happening because both tracks that are being
>>>>> recorded into are off-screen (not useful).
>>>>>
>>>>> Scroll up to the top and you can see that the first track is being
>>>>> recorded into.
>>>>>
>>>>> If you are really on the ball and looking like a hawk, you may notice
>>>>> that track 7 is also being recorded into.
>>>>> If track 1 was selected, will track 7 still be recorded into if
>>>>> recording was set to 2 channel stereo?
>>>> With my code, no.  Only track 1 gets recorded into.
>>> Good. We are in full agreement wrt the simple cases.
>>>
>>>> I am sure this exact situation with 7 stereo tracks and 3 interspersed
>>>> mono
>>>> tracks will arise frequently (not).
>>> :grin: No. of course this exact situation will be extremely rare, but
>>> as David indicated, projects with a mix of mono and stereo tracks are
>>> quite common. Large multi-track projects are probably also a lot more
>>> common than suggested by user feedback (which is not surprisingly
>>> dominated by our least able users).
>>>
>>> Yes we need to do the least surprising thing and avoid weirdness for
>>> simple projects, but also for more complex use cases.
>>>
>>> We all agree that the current behaviour is not ideal in cases where
>>> only the left channel of a stereo pair will be recorded, but I don't
>>> think we yet have a really good solution.
>>>
>>> What I don't like about the proposal you put forward James is that it
>>> appears to do different things in different cases:
>>> * Stereo recording into mono track => drops the right channel.
>>> * Mono recording into stereo track => creates a new track with the
>>> right number of channels.
>>> * Stereo recording when more than one mono track => Splits the
>>> recording across the first two mono tracks.
>>>
>>> I agree that the proposed behaviour is fairly obvious if you know the
>>> rule, but I'm not sure that the rule is necessarily obvious from the
>>> observed behaviour. I do think that we need to help users with this as
>>> I expect that very many our existing (millions of) users will be
>>> initially caught out by the Record <=> Append Record swap.
>>>
>>>>
>>>> So can we cut to the chase Steve?  What do you want to do?  Leave as is,
>>>> use
>>>> my fix or revert the 'record append'?  Or do you have another concrete
>>>> proposal in mind?
>>> My current thinking is to retain the current behaviour and add a
>>> "don't show again" style warning when actioning Append Record with the
>>> wrong number of channels selected. Something along the lines of:
>>>
>>> "Append Record:
>>> No audio tracks selected.
>>> "OK" will record x channels into track(s) y"
>>> [OK]  [Cancel]
>>>
>>> where "x" is the number of channels being recorded and "y" is the
>>> track number(s) that will be recorded into.
>>> If too many or not enough tracks are selected for the number of
>>> channels being recorded, the first line of the message would change
>>> accordingly.
>>>
>>>
>>> The message should indicate (as the above does) that the warning is
>>> occurring because the user has not selected the required number of
>>> channels to record into. If the correct number of channels is
>>> selected, regardless of mono/stereo, then the recording should go
>>> ahead without warning (avoids bugging users that know what they are
>>> doing).
>>>
>>>
>>> Steve
>>>
>>>>>>> The good thing about the current behaviour is that the rule is very
>>>>>>> simple in all cases - "use the first N channels", (where "N" is the
>>>>>>> number of channels being recorded).
>>>>>> The same rule is used here, provided it does not lead to a
>>>>>> mono-in-stereo-track recording.
>>>>>>
>>>>>>> The down side is that it looks a bit weird in the specific case that
>>>>>>> David cited.
>>>>>>
>>>>>> Not just weird, but not useful.  It isn't helpful to have a stereo
>>>>>> track
>>>>>> with one channel with more content than the other.
>>>>> It's not common, but I've had several theatrical projects with
>>>>> different audio clips in each channel, where I needed a sound effect
>>>>> stage left or stage right. Yes I could have rendered silence in the
>>>>> other channel, but I didn't need to because we have always allowed
>>>>> different audio clips in each channel. Also, it can be handy to leave
>>>>> "white space" so that it's easier to insert mono clips into the space.
>>>>> Flexible ways of working is one of Audacity's greatest strength in the
>>>>> technically challenging art of theatrical "sound design".
>>>>>
>>>>> I don't recall ever needing to 'record' into one mono and half a
>>>>> stereo track, and I agree that is not very useful, but it does avoid
>>>>> hidden traps such as the example above.
>>>>>
>>>>>> Note:
>>>>>> Attempting to record mono into a stereo track adds a new mono track, as
>>>>>> if
>>>>>> no tracks had been selected.
>>>>> In your not-yet-committed version I presume. So that is an exception
>>>>> to the rule, whereas the current rule is always consistent.
>>>>>
>>>>> Steve
>>>>>
>>>>>>
>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>> I think it's not going to happen that often.
>>>>>>>>
>>>>>>>> So, for example, if there is a mono track (A), then a stereo track
>>>>>>>> (B+C),
>>>>>>>> then a mono track (D), and the user selects all, and then records 'in
>>>>>>>> stereo', they record into A and D.
>>>>>>>>
>>>>>>>>> When recording 4 or more channels simultaneously, the behaviour
>>>>>>>>> looks
>>>>>>>>> totally reasonable imo. Example, when recording 4 channels, the
>>>>>>>>> input
>>>>>>>>> channels record into the first 4 selected channels - if two stereo
>>>>>>>>> tracks are selected, they record as:
>>>>>>>>> In 1 -> Track 1 L
>>>>>>>>> In 2 -> Track 1 R
>>>>>>>>> In 3 -> Track 2 L
>>>>>>>>> In 4 -> Track 2 R
>>>>>>>>> In the absence of a "channel mapping" feature, I think this
>>>>>>>>> multi-channel behaviour is 'correct'.
>>>>>>>>>
>>>>>>>>> Given the 'correct' multi-channel behaviour, I'm inclined towards
>>>>>>>>> either, not changing anything and accept that it can look a bit
>>>>>>>>> weird,
>>>>>>>>> or, pop up a warning with a "don't show again" option that informs
>>>>>>>>> the
>>>>>>>>> user what is happening.
>>>>>>>>
>>>>>>>> The proposed 'something else' would not disrupt that.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>>> --James.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 7/6/2017 9:50 AM, David Bailes wrote:
>>>>>>>>>>> The rules appear to be:
>>>>>>>>>>>
>>>>>>>>>>> Mono:
>>>>>>>>>>> If any tracks are selected, append to the first, else append to
>>>>>>>>>>> the
>>>>>>>>>>> first
>>>>>>>>>>> track
>>>>>>>>>>>
>>>>>>>>>>> Stereo:
>>>>>>>>>>> If any tracks are selected, append to the first two tracks
>>>>>>>>>>> (whether
>>>>>>>>>>> they
>>>>>>>>>>> be
>>>>>>>>>>> mono, left, or right) that are selected, else append to the first
>>>>>>>>>>> two
>>>>>>>>>>> tracks (again, whether they be mono, left, or right).
>>>>>>>>>>>
>>>>>>>>>>> So, for example if a project contains a mono track followed by a
>>>>>>>>>>> stereo
>>>>>>>>>>> track, and both tracks are either selected or not selected, then a
>>>>>>>>>>> stereo
>>>>>>>>>>> append record adds audio to the mono track and the left hand track
>>>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>> stereo track.
>>>>>>>>>>>
>>>>>>>>>>> Or if in a project two mono tracks are selected, then regardless
>>>>>>>>>>> of
>>>>>>>>>>> how
>>>>>>>>>>> far
>>>>>>>>>>> apart they are, a stereo append will add audio to these tracks.
>>>>>>>>>>>
>>>>>>>>>>> Given that people will inevitably be append recording by accident
>>>>>>>>>>> when
>>>>>>>>>>> 2.2.0 comes out, the above results don't seem that desirable,
>>>>>>>>>>>
>>>>>>>>>>> David.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
On 7/7/2017 9:37 AM, Steve the Fiddle wrote:

> On 6 July 2017 at 17:16, Robert Hänggi <[hidden email]> wrote:
>> On 06/07/2017, James Crook <[hidden email]> wrote:
>>> Robert Hänggi wrote:
>>>> James, your fix for the split is good even if the behaviour stays the
>>>> same.
>>> OK.  Done.
>>> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>>>
>> Thanks.
>> I think that's a reasonable change.
>>
>> I don't yet fully understand the problem with "Energy displayed in
>> Spectrograms".
>> Does this happen for clips that do not fall into the grid of the
>> current spectrogram hop size?
>> I assume that this is coded in WaveClip.cpp, in other words a cache
>> and spectrogram for each clip individually.
>> I have to look how pre-/post padding is handled.
>>
>> James is right and I think that micro-fades will at some point be inevitable.
>> However, I can't say if this remedies the issue.
>>
>> Robert
>>
>>
>>
>>> Steve, I don't see a warning as helpful.  As I see it the simple cases
>>> are handled well,
> Don't you think that in a multi-track project, there is a huge
> assumption about Append Record doing "the right thing" unless a track
> has explicitly been selected?
>
> Taking David's example of one voice track and one music track. It is
> very likely that the tracks will have different durations and it's a
> 50/50 chance that the "correct" track to append will be the first
> track, so a 50/50 chance that Append Record will do the wrong thing
> unless the correct track to append has been selected.
It sounds like you want the 'read my mind' interface!  If there are ten
tracks and I want to record on the end of one of them there is only a 1
in 10 chance of Append-Record getting it right - unless I tell it which
track.

I think that is just fine.

>
>>> and the one real defect of the current approach is the
>>> mono-in-stereo possibility.
> If the user has selected the track(s) that they want to record into,
> then should we assume that they want to append that/those tracks?
It's (probably) sufficiently rare that a user does want to record mono
into stereo that we can reasonably assume it is a mistake.  The users
who really do want to can split stereo.


>>>   If you want a solution that you really
>>> like, best that you code and commit it.
> I'm not a fan of relying on warning messages. When we feel that we
> 'need' a warning message, that is usually an indication that it is not
> obvious for users, how to "do it right".
>
> I'm hoping that someone may come up with a better idea of how to
> handle this issue.

I guess I'm saying that I don't see it as much of an issue.  Only the
mono-in-stereo aspect bothers me a little.  So I am probably not likely
to come up with a fix for something that I don't see as broken.  If at
the same time you don't have a solution you are happy with, and no one
else proposes one, then the outcome will be that the code stays the same.

I don't think I am useful to the dialogue any more, unless either you
can convince me that there is a problem bigger than mono-in-stereo, or
someone presents a concrete proposal to 'fix' the problem for
critiquing.  I personally don't like the warning solutions, as I think
it will be clear enough what Audacity is-doing / has-done in recording,
and how not to do that next time, without a warning


>
>>> If it is any use in so doing, this is the code I added to avoid putting
>>> mono into a stereo track:
>>>
>>> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)
>>>
>>>                  // Don't record into one track of a stereo track...
>>>                  if( ((int)recordingTracks.size() >= recordingChannels
>>> -1) &&
>>>                      wt->GetLinked() )
>>>                  {   tt = it.Next();
>>>                      continue;
>>>                  }
>>>
>>> ((int)recordingTracks.size() >= recordingChannels -1) checks if we are
>>> assigning the last channel,
>>> GetLinked() is checking if the channel assigned to is part of a stereo
>>> track, it.Next advances past the partner channel too, and continue skips
>>> assigning to this channel and moves on to examine later channels we
>>> could assign to instead.
>>>
>>> You'd probably set a flag instead and use the flag to pop up a dialog.
> Thanks for the code tip.
>
> Steve
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

James Crook
In reply to this post by Stevethefiddle
There is a possible argument that as soon as there is more than one
track, Audacity should switch to record-new-track as the default, when
no tracks are selected.

Someone who is working with more than one track can be assumed to know
how to move clips around.



On 7/7/2017 9:37 AM, Steve the Fiddle wrote:

> On 6 July 2017 at 17:16, Robert Hänggi <[hidden email]> wrote:
>> On 06/07/2017, James Crook <[hidden email]> wrote:
>>> Robert Hänggi wrote:
>>>> James, your fix for the split is good even if the behaviour stays the
>>>> same.
>>> OK.  Done.
>>> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>>>
>> Thanks.
>> I think that's a reasonable change.
>>
>> I don't yet fully understand the problem with "Energy displayed in
>> Spectrograms".
>> Does this happen for clips that do not fall into the grid of the
>> current spectrogram hop size?
>> I assume that this is coded in WaveClip.cpp, in other words a cache
>> and spectrogram for each clip individually.
>> I have to look how pre-/post padding is handled.
>>
>> James is right and I think that micro-fades will at some point be inevitable.
>> However, I can't say if this remedies the issue.
>>
>> Robert
>>
>>
>>
>>> Steve, I don't see a warning as helpful.  As I see it the simple cases
>>> are handled well,
> Don't you think that in a multi-track project, there is a huge
> assumption about Append Record doing "the right thing" unless a track
> has explicitly been selected?
>
> Taking David's example of one voice track and one music track. It is
> very likely that the tracks will have different durations and it's a
> 50/50 chance that the "correct" track to append will be the first
> track, so a 50/50 chance that Append Record will do the wrong thing
> unless the correct track to append has been selected.
>
>>> and the one real defect of the current approach is the
>>> mono-in-stereo possibility.
> If the user has selected the track(s) that they want to record into,
> then should we assume that they want to append that/those tracks?
>
>>>   If you want a solution that you really
>>> like, best that you code and commit it.
> I'm not a fan of relying on warning messages. When we feel that we
> 'need' a warning message, that is usually an indication that it is not
> obvious for users, how to "do it right".
>
> I'm hoping that someone may come up with a better idea of how to
> handle this issue.
>
>>> If it is any use in so doing, this is the code I added to avoid putting
>>> mono into a stereo track:
>>>
>>> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)
>>>
>>>                  // Don't record into one track of a stereo track...
>>>                  if( ((int)recordingTracks.size() >= recordingChannels
>>> -1) &&
>>>                      wt->GetLinked() )
>>>                  {   tt = it.Next();
>>>                      continue;
>>>                  }
>>>
>>> ((int)recordingTracks.size() >= recordingChannels -1) checks if we are
>>> assigning the last channel,
>>> GetLinked() is checking if the channel assigned to is part of a stereo
>>> track, it.Next advances past the partner channel too, and continue skips
>>> assigning to this channel and moves on to examine later channels we
>>> could assign to instead.
>>>
>>> You'd probably set a flag instead and use the flag to pop up a dialog.
> Thanks for the code tip.
>
> Steve
> https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Stevethefiddle
In reply to this post by James Crook
On 7 July 2017 at 10:01, James Crook <[hidden email]> wrote:

> On 7/7/2017 9:37 AM, Steve the Fiddle wrote:
>>
>> On 6 July 2017 at 17:16, Robert Hänggi <[hidden email]> wrote:
>>>
>>> On 06/07/2017, James Crook <[hidden email]> wrote:
>>>>
>>>> Robert Hänggi wrote:
>>>>>
>>>>> James, your fix for the split is good even if the behaviour stays the
>>>>> same.
>>>>
>>>> OK.  Done.
>>>>
>>>> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>>>>
>>> Thanks.
>>> I think that's a reasonable change.
>>>
>>> I don't yet fully understand the problem with "Energy displayed in
>>> Spectrograms".
>>> Does this happen for clips that do not fall into the grid of the
>>> current spectrogram hop size?
>>> I assume that this is coded in WaveClip.cpp, in other words a cache
>>> and spectrogram for each clip individually.
>>> I have to look how pre-/post padding is handled.
>>>
>>> James is right and I think that micro-fades will at some point be
>>> inevitable.
>>> However, I can't say if this remedies the issue.
>>>
>>> Robert
>>>
>>>
>>>
>>>> Steve, I don't see a warning as helpful.  As I see it the simple cases
>>>> are handled well,
>>
>> Don't you think that in a multi-track project, there is a huge
>> assumption about Append Record doing "the right thing" unless a track
>> has explicitly been selected?
>>
>> Taking David's example of one voice track and one music track. It is
>> very likely that the tracks will have different durations and it's a
>> 50/50 chance that the "correct" track to append will be the first
>> track, so a 50/50 chance that Append Record will do the wrong thing
>> unless the correct track to append has been selected.
>
> It sounds like you want the 'read my mind' interface!

Ooh yes please. We can put that in the same menu as the "Professional
Audio Filter (PAF)"
https://forum.audacityteam.org/viewtopic.php?p=80096#p80096

:-)

> If there are ten
> tracks and I want to record on the end of one of them there is only a 1 in
> 10 chance of Append-Record getting it right - unless I tell it which track.
>
> I think that is just fine.
>
>>
>>>> and the one real defect of the current approach is the
>>>> mono-in-stereo possibility.
>>
>> If the user has selected the track(s) that they want to record into,
>> then should we assume that they want to append that/those tracks?
>
> It's (probably) sufficiently rare that a user does want to record mono into
> stereo that we can reasonably assume it is a mistake.  The users who really
> do want to can split stereo.

So recording mono into a stereo track should be an error, whether that
track is selected or not?

>
>
>>>>   If you want a solution that you really
>>>> like, best that you code and commit it.
>>
>> I'm not a fan of relying on warning messages. When we feel that we
>> 'need' a warning message, that is usually an indication that it is not
>> obvious for users, how to "do it right".
>>
>> I'm hoping that someone may come up with a better idea of how to
>> handle this issue.
>
>
> I guess I'm saying that I don't see it as much of an issue.  Only the
> mono-in-stereo aspect bothers me a little.  So I am probably not likely to
> come up with a fix for something that I don't see as broken.  If at the same
> time you don't have a solution you are happy with, and no one else proposes
> one, then the outcome will be that the code stays the same.

I also don't think it's a big issue in itself, but my main concern is
that if we have a million existing users doing "the wrong thing"
because we have changed how to do "the right thing", then that 'could'
produce an overwhelming number of support requests. I think being
proactive and addressing this (small) issue could save a lot of
unhappy users and save a lot of time for the support crew.

The issue is "low severity", but this discussion is about "priority"
considering the number of users that will be affected by the Record /
Append Record change (nearly all).

Steve

>
> I don't think I am useful to the dialogue any more, unless either you can
> convince me that there is a problem bigger than mono-in-stereo, or someone
> presents a concrete proposal to 'fix' the problem for critiquing.  I
> personally don't like the warning solutions, as I think it will be clear
> enough what Audacity is-doing / has-done in recording, and how not to do
> that next time, without a warning
>
>
>>
>>>> If it is any use in so doing, this is the code I added to avoid putting
>>>> mono into a stereo track:
>>>>
>>>> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)
>>>>
>>>>                  // Don't record into one track of a stereo track...
>>>>                  if( ((int)recordingTracks.size() >= recordingChannels
>>>> -1) &&
>>>>                      wt->GetLinked() )
>>>>                  {   tt = it.Next();
>>>>                      continue;
>>>>                  }
>>>>
>>>> ((int)recordingTracks.size() >= recordingChannels -1) checks if we are
>>>> assigning the last channel,
>>>> GetLinked() is checking if the channel assigned to is part of a stereo
>>>> track, it.Next advances past the partner channel too, and continue skips
>>>> assigning to this channel and moves on to examine later channels we
>>>> could assign to instead.
>>>>
>>>> You'd probably set a flag instead and use the flag to pop up a dialog.
>>
>> Thanks for the code tip.
>>
>> Steve
>>
>
>
> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Robert Hänggi
The issue is in my opinion that the rooting for recording isn't
visible on screen.
The user has to guess (or to look up) the logic.

The means of displaying it are widely possible.
- a asterisk behind the track name
- a different colour for the first selected tracks
- a hint in the tool tip for append record
- a notice in the status bar
...and so on

I'm personally used to deselect all tracks before recording.
I can't say that I've fallen into this trap before although my input
is always stereo and the projects are a mixture of M and S.

Robert


On 07/07/2017, Steve the Fiddle <[hidden email]> wrote:

> On 7 July 2017 at 10:01, James Crook <[hidden email]> wrote:
>> On 7/7/2017 9:37 AM, Steve the Fiddle wrote:
>>>
>>> On 6 July 2017 at 17:16, Robert Hänggi <[hidden email]> wrote:
>>>>
>>>> On 06/07/2017, James Crook <[hidden email]> wrote:
>>>>>
>>>>> Robert Hänggi wrote:
>>>>>>
>>>>>> James, your fix for the split is good even if the behaviour stays the
>>>>>> same.
>>>>>
>>>>> OK.  Done.
>>>>>
>>>>> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>>>>>
>>>> Thanks.
>>>> I think that's a reasonable change.
>>>>
>>>> I don't yet fully understand the problem with "Energy displayed in
>>>> Spectrograms".
>>>> Does this happen for clips that do not fall into the grid of the
>>>> current spectrogram hop size?
>>>> I assume that this is coded in WaveClip.cpp, in other words a cache
>>>> and spectrogram for each clip individually.
>>>> I have to look how pre-/post padding is handled.
>>>>
>>>> James is right and I think that micro-fades will at some point be
>>>> inevitable.
>>>> However, I can't say if this remedies the issue.
>>>>
>>>> Robert
>>>>
>>>>
>>>>
>>>>> Steve, I don't see a warning as helpful.  As I see it the simple cases
>>>>> are handled well,
>>>
>>> Don't you think that in a multi-track project, there is a huge
>>> assumption about Append Record doing "the right thing" unless a track
>>> has explicitly been selected?
>>>
>>> Taking David's example of one voice track and one music track. It is
>>> very likely that the tracks will have different durations and it's a
>>> 50/50 chance that the "correct" track to append will be the first
>>> track, so a 50/50 chance that Append Record will do the wrong thing
>>> unless the correct track to append has been selected.
>>
>> It sounds like you want the 'read my mind' interface!
>
> Ooh yes please. We can put that in the same menu as the "Professional
> Audio Filter (PAF)"
> https://forum.audacityteam.org/viewtopic.php?p=80096#p80096
>
> :-)
>
>> If there are ten
>> tracks and I want to record on the end of one of them there is only a 1 in
>> 10 chance of Append-Record getting it right - unless I tell it which
>> track.
>>
>> I think that is just fine.
>>
>>>
>>>>> and the one real defect of the current approach is the
>>>>> mono-in-stereo possibility.
>>>
>>> If the user has selected the track(s) that they want to record into,
>>> then should we assume that they want to append that/those tracks?
>>
>> It's (probably) sufficiently rare that a user does want to record mono
>> into
>> stereo that we can reasonably assume it is a mistake.  The users who
>> really
>> do want to can split stereo.
>
> So recording mono into a stereo track should be an error, whether that
> track is selected or not?
>
>>
>>
>>>>>   If you want a solution that you really
>>>>> like, best that you code and commit it.
>>>
>>> I'm not a fan of relying on warning messages. When we feel that we
>>> 'need' a warning message, that is usually an indication that it is not
>>> obvious for users, how to "do it right".
>>>
>>> I'm hoping that someone may come up with a better idea of how to
>>> handle this issue.
>>
>>
>> I guess I'm saying that I don't see it as much of an issue.  Only the
>> mono-in-stereo aspect bothers me a little.  So I am probably not likely to
>> come up with a fix for something that I don't see as broken.  If at the
>> same
>> time you don't have a solution you are happy with, and no one else
>> proposes
>> one, then the outcome will be that the code stays the same.
>
> I also don't think it's a big issue in itself, but my main concern is
> that if we have a million existing users doing "the wrong thing"
> because we have changed how to do "the right thing", then that 'could'
> produce an overwhelming number of support requests. I think being
> proactive and addressing this (small) issue could save a lot of
> unhappy users and save a lot of time for the support crew.
>
> The issue is "low severity", but this discussion is about "priority"
> considering the number of users that will be affected by the Record /
> Append Record change (nearly all).
>
> Steve
>
>>
>> I don't think I am useful to the dialogue any more, unless either you can
>> convince me that there is a problem bigger than mono-in-stereo, or someone
>> presents a concrete proposal to 'fix' the problem for critiquing.  I
>> personally don't like the warning solutions, as I think it will be clear
>> enough what Audacity is-doing / has-done in recording, and how not to do
>> that next time, without a warning
>>
>>
>>>
>>>>> If it is any use in so doing, this is the code I added to avoid putting
>>>>> mono into a stereo track:
>>>>>
>>>>> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent &evt)
>>>>>
>>>>>                  // Don't record into one track of a stereo track...
>>>>>                  if( ((int)recordingTracks.size() >= recordingChannels
>>>>> -1) &&
>>>>>                      wt->GetLinked() )
>>>>>                  {   tt = it.Next();
>>>>>                      continue;
>>>>>                  }
>>>>>
>>>>> ((int)recordingTracks.size() >= recordingChannels -1) checks if we are
>>>>> assigning the last channel,
>>>>> GetLinked() is checking if the channel assigned to is part of a stereo
>>>>> track, it.Next advances past the partner channel too, and continue
>>>>> skips
>>>>> assigning to this channel and moves on to examine later channels we
>>>>> could assign to instead.
>>>>>
>>>>> You'd probably set a flag instead and use the flag to pop up a dialog.
>>>
>>> Thanks for the code tip.
>>>
>>> Steve
>>>
>>
>>
>> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: append record

Robert Hänggi
I meant routing, not rooting...
Sorry
Robert

On 07/07/2017, Robert Hänggi <[hidden email]> wrote:

> The issue is in my opinion that the rooting for recording isn't
> visible on screen.
> The user has to guess (or to look up) the logic.
>
> The means of displaying it are widely possible.
> - a asterisk behind the track name
> - a different colour for the first selected tracks
> - a hint in the tool tip for append record
> - a notice in the status bar
> ...and so on
>
> I'm personally used to deselect all tracks before recording.
> I can't say that I've fallen into this trap before although my input
> is always stereo and the projects are a mixture of M and S.
>
> Robert
>
>
> On 07/07/2017, Steve the Fiddle <[hidden email]> wrote:
>> On 7 July 2017 at 10:01, James Crook <[hidden email]> wrote:
>>> On 7/7/2017 9:37 AM, Steve the Fiddle wrote:
>>>>
>>>> On 6 July 2017 at 17:16, Robert Hänggi <[hidden email]> wrote:
>>>>>
>>>>> On 06/07/2017, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> Robert Hänggi wrote:
>>>>>>>
>>>>>>> James, your fix for the split is good even if the behaviour stays
>>>>>>> the
>>>>>>> same.
>>>>>>
>>>>>> OK.  Done.
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/739422ba70ceb4be0bb1829b6feb0c5401de641e
>>>>>>
>>>>> Thanks.
>>>>> I think that's a reasonable change.
>>>>>
>>>>> I don't yet fully understand the problem with "Energy displayed in
>>>>> Spectrograms".
>>>>> Does this happen for clips that do not fall into the grid of the
>>>>> current spectrogram hop size?
>>>>> I assume that this is coded in WaveClip.cpp, in other words a cache
>>>>> and spectrogram for each clip individually.
>>>>> I have to look how pre-/post padding is handled.
>>>>>
>>>>> James is right and I think that micro-fades will at some point be
>>>>> inevitable.
>>>>> However, I can't say if this remedies the issue.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>>
>>>>>> Steve, I don't see a warning as helpful.  As I see it the simple
>>>>>> cases
>>>>>> are handled well,
>>>>
>>>> Don't you think that in a multi-track project, there is a huge
>>>> assumption about Append Record doing "the right thing" unless a track
>>>> has explicitly been selected?
>>>>
>>>> Taking David's example of one voice track and one music track. It is
>>>> very likely that the tracks will have different durations and it's a
>>>> 50/50 chance that the "correct" track to append will be the first
>>>> track, so a 50/50 chance that Append Record will do the wrong thing
>>>> unless the correct track to append has been selected.
>>>
>>> It sounds like you want the 'read my mind' interface!
>>
>> Ooh yes please. We can put that in the same menu as the "Professional
>> Audio Filter (PAF)"
>> https://forum.audacityteam.org/viewtopic.php?p=80096#p80096
>>
>> :-)
>>
>>> If there are ten
>>> tracks and I want to record on the end of one of them there is only a 1
>>> in
>>> 10 chance of Append-Record getting it right - unless I tell it which
>>> track.
>>>
>>> I think that is just fine.
>>>
>>>>
>>>>>> and the one real defect of the current approach is the
>>>>>> mono-in-stereo possibility.
>>>>
>>>> If the user has selected the track(s) that they want to record into,
>>>> then should we assume that they want to append that/those tracks?
>>>
>>> It's (probably) sufficiently rare that a user does want to record mono
>>> into
>>> stereo that we can reasonably assume it is a mistake.  The users who
>>> really
>>> do want to can split stereo.
>>
>> So recording mono into a stereo track should be an error, whether that
>> track is selected or not?
>>
>>>
>>>
>>>>>>   If you want a solution that you really
>>>>>> like, best that you code and commit it.
>>>>
>>>> I'm not a fan of relying on warning messages. When we feel that we
>>>> 'need' a warning message, that is usually an indication that it is not
>>>> obvious for users, how to "do it right".
>>>>
>>>> I'm hoping that someone may come up with a better idea of how to
>>>> handle this issue.
>>>
>>>
>>> I guess I'm saying that I don't see it as much of an issue.  Only the
>>> mono-in-stereo aspect bothers me a little.  So I am probably not likely
>>> to
>>> come up with a fix for something that I don't see as broken.  If at the
>>> same
>>> time you don't have a solution you are happy with, and no one else
>>> proposes
>>> one, then the outcome will be that the code stays the same.
>>
>> I also don't think it's a big issue in itself, but my main concern is
>> that if we have a million existing users doing "the wrong thing"
>> because we have changed how to do "the right thing", then that 'could'
>> produce an overwhelming number of support requests. I think being
>> proactive and addressing this (small) issue could save a lot of
>> unhappy users and save a lot of time for the support crew.
>>
>> The issue is "low severity", but this discussion is about "priority"
>> considering the number of users that will be affected by the Record /
>> Append Record change (nearly all).
>>
>> Steve
>>
>>>
>>> I don't think I am useful to the dialogue any more, unless either you
>>> can
>>> convince me that there is a problem bigger than mono-in-stereo, or
>>> someone
>>> presents a concrete proposal to 'fix' the problem for critiquing.  I
>>> personally don't like the warning solutions, as I think it will be clear
>>> enough what Audacity is-doing / has-done in recording, and how not to do
>>> that next time, without a warning
>>>
>>>
>>>>
>>>>>> If it is any use in so doing, this is the code I added to avoid
>>>>>> putting
>>>>>> mono into a stereo track:
>>>>>>
>>>>>> inside one loop in: void ControlToolBar::OnRecord(wxCommandEvent
>>>>>> &evt)
>>>>>>
>>>>>>                  // Don't record into one track of a stereo track...
>>>>>>                  if( ((int)recordingTracks.size() >=
>>>>>> recordingChannels
>>>>>> -1) &&
>>>>>>                      wt->GetLinked() )
>>>>>>                  {   tt = it.Next();
>>>>>>                      continue;
>>>>>>                  }
>>>>>>
>>>>>> ((int)recordingTracks.size() >= recordingChannels -1) checks if we
>>>>>> are
>>>>>> assigning the last channel,
>>>>>> GetLinked() is checking if the channel assigned to is part of a
>>>>>> stereo
>>>>>> track, it.Next advances past the partner channel too, and continue
>>>>>> skips
>>>>>> assigning to this channel and moves on to examine later channels we
>>>>>> could assign to instead.
>>>>>>
>>>>>> You'd probably set a flag instead and use the flag to pop up a
>>>>>> dialog.
>>>>
>>>> Thanks for the code tip.
>>>>
>>>> Steve
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
12
Loading...