Maybe, if there is any consensus about where SHIFT + B loops back from. But IMO that shortcut should only explicitly loop to/from the pointer, not the cursor - i.e. if pointer is at 2 mins and cursor at 2 mins 30s, SHIFT + B loops from 2 mins to 2 mins 30s; if cursor at 2 mins 30s and pointer at 3 mins, SHIFT + B loops from 2 mins 30s to 3 mins. Actually I like that, it’s a loop equivalent of what B does now. But if you really wanted to loop from cursor to end of track, I don’t think you should use SHIFT + B and have to move the pointer off the waveform. If the default isn’t to loop from the cursor when there is no selection, then I think there should be a separate shortcut to loop from cursor.
The only argument I’ve seen for looping the whole track when there is no selection is that this is a time saving if the track is itself the entire loop. I’m convinced loop should play from cursor if you just SHIFT + Space, and if there are complaints when that is implemented, then looping the whole track if there is no selection could be a preference. We might in any case need a preference as to what happens if you SHIFT + Space to loop from cursor. Clearly there are two camps, one of which says you loop to the end of the track, the other says you loop through from the end of the track to the cursor.
I still think we need a shortcut to play from start of selection to pointer where the pointer is past midpoint, and pointer to end of selection if pointer is before midpoint. I guess ALT +B would be OK and gives an ALT + SHIFT + B way to loop that. You could also make a case for doing away with the midpoint distinction. If the pointer is after the midpoint of the selection, B still plays start of selection to pointer, so following the rule elsewhere that the cursor is deemed to be at the start of the selection. ALT + B would then play from pointer to end of selection.
The problem I see with using the mouse pointer’s position as one anchor of a loop is that even with your hand off the mouse the pointer moves constantly in tiny amounts; it is amazing how much your desk surface jiggles. On a CAD program I beta-test for we found that this was causing real accuracy issues once screen resolutions started getting over 1200x1000. It is also a problem when you want to zoom in to one anchor, set it and listen–the display scrolls and you cannot get back to the exact location accurately without a label.
Steve, are you the one who DLed L2C v2? If so, does it do what you want?
As the SVN HEAD does not compile, I hesitate to create a new patch. Can you apply the changes manually? There are no changed nor removed lines of code, only the addition of a few lines plus two functions (both of which can go at the bottom of the affected file). If you feel hesitant to apply manually, let me know and I can zip up the files and send them to you.
I’m working on a copy so I’ve been bold
Applied the patch and built without errors.
Unfortunately it does not quite do what I need.
The main problem is that after playing from the cursor to the end of the label there is a brief pause (just a little stutter really) before playback begins again from the beginning of the label region. This makes it impossible to tell if the loop position is in exactly the right place. (When it has played through the entire loop and loops the second time there is no pause, but of course the purpose was to avoid having to wait for it to play all through the loop).
From a user point of view I think that looping the selection from the pointer position would be more convenient than using labels. I don’t think that inaccuracy of the pointer position would be a problem as it works well enough with the current “B” key action.
I would agree with that.
Agreed, but I also want the loop equivalent of what “B” does now when inside a selection.
That sounds good to me.
Playing tracks that are entire loops is a common task for people that make loop based music, but looping an entire track from the cursor position would be a great bonus when working with longer loops. For short loops it doesn’t really matter where in the loop playback starts (as it will be back to the beginning soon enough anyway).
In cases where looping from the beginning of the track is specifically wanted then it is easy enough to either select the entire track, or press the HOME button, or click on the “Rewind” button.
What I would expect, and what would be most useful for me, would be that:
With no selection; SHIFT+Space starts playing from the cursor position and plays up to the end of the track. On reaching the end of the track it would loop back to the beginning of the track. Playback would then continue to the end of the track and then loop back to the beginning, and so on.
When there is a selection: SHIFT+Space starts playing from the beginning of the selection (which is also the cursor position) and plays through to the end of the selection. On reaching the end of the selection it loops back to the beginning of the selection, and continues looping the entire selection.
Increasing the number causes a longer pause before it loops back, but decreasing the number has no effect.
A good way to test is with a constant sine tone. Press “Z” before creating the label (so that the loop points are at zero crossing points).
This should loop seamlessly (play as a constant tone), which it does when looped with SHIFT+Space.
A less important issue is that while it plays from the cursor to the end of the label the cursor does not move.
Thanks for trying with this Edgar but please don’t feel any obligation to spend time fixing it - I have other ways of working round the looping limitation.
Upon reflection, I think Bill’s note that some of Audacity’s actions are performed using behind-the-scenes tracks has the answer. If a hidden track were created and the samples between the mouse pointer’s hot spot (note–this is a very questionable “point”–it differs with the tool selected; I still think cursor is better, but as I’m not the one using it, would accept your choice) and the end of the section (selection or, again as I would use it, Label Region) were copied into the beginning of that track, then the samples from the start of the section up the last sample not included in the first chunk were added to the hidden track’s end it would work. This is a lot more front-end time setting it all up and way beyond my abilities to program Audacity.
I have transferred the main gist of the FR conversation from this thread to the Pending Feature Requests of the Wiki. I have retained the full thread here so as to retain access to Edgar’s patch.
