View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001274 | ardour | bugs | public | 2006-10-12 06:48 | 2020-04-19 20:12 |
| Reporter | ldg | Assigned To | paul | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0001274: Selecting playlisting for a bunch of grouped trackes | ||||
| Description | I noticed that I now (2 beta 2, the only ardour 2 dmg I could find), create a new playlist for a track, and by doing that new playlists are created to all other tracks that are in the same group. But if only change a track's playlist, the other tracks doesn't jump to the corresponding playlist (1.1, 2.1 etc...). This feature is what makes multitrack editing in protools so fun. Sorry, if I'm reporting about older beta, while newer already has this implemented... Thanks Eldad | ||||
| Tags | No tags attached. | ||||
|
|
The possibility to recall playlists in a grouped manner has been on my mind for some time, so I searched the bugtracker and found this and bug 0001769 wich cover this issue. I was thinking about a possible solution and took a look at a session file: As far as I can see playlists currently only have the tags "name", "orig_diskstream_id" and "fozen". A tag "creation_time" could be added. If playlists then get created as a group they all should get the same time of creation. So on recall it would be possible to instruct the other tracks in a group to load the playlist with the corresponding creation time, if there is such a playlist - else keeping the current. There are sure other approaches that would work, but to me it seems to be a relativly simple approach. Grouped recall would be a really big improvement for working with multiple takes of a multitrack recorded istrument such as drums. BTW: IMO the "creation_time" tag would also be very usefull for ordering the playlists in the playlist selection menu, wich I currently find a bit unintuitive to use, because of the entries jumping around on selection. Axel. |
|
|
Wheee! Thanks, sampo. =^.^= I only did a few quick tests, but your "primitive take system" introduced in ongoing in rev. 3871 seems to work fine for me and should be more flexible from the users POV (e.g. by renaming playlists) than my idea above. Thanks again. :) |
|
|
Just noticed a problem with it: I made one take (*.take.1), then deactivated the group, made a copy of one playlist in one track (*.take.2), reactivated the group and made a new take. New takes/playlists in all tracks got the number 2 except the one in the track where I made a copy, wich got number 3. This of course screws things up on recall. IMO it should be taken care of not only that all playlists get the same number, but also one number higher than the highest number in any of all playlists in that group. So if there is one number missing inbetween it's simply left out so that users don't get confused wich take was fist. |
|
|
the_CLA: the numbering issue that you describe appears to have been fixed in current 2.0. Can you confirm that? |
|
|
Yes, I think this was fixed quite some time ago and a quick test seems to confirm this. The only remainig issue is that the initial playlists wich get created when you create new tracks are not recalled as a group. So you have to edit the playlist names by hand to make them group-recallable or you have to think of it in time to create a "new take" before the first recording, wich is easily forgotten IMHO. So the question is: Should this be addressed? Create a separate report or track it in this one? |
|
|
the_CLA: i think that it a "new" issue (though we've known about it for a while). Take management is tricky, and really an area that needs some good, clever work (and/or copying of recent Logic approaches :) The playlist selection stuff that we have now is a band-aid for this, but is not how we intend to really tackle take management in the long term. so i'm going to mark this resolved for now, but please feel free to check for any existing take mgmt bugs and if none are broad enough, add one. thanks a lot. |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-10-12 06:48 | ldg | New Issue | |
| 2008-10-02 17:48 | the_CLA | Note Added: 0005151 | |
| 2008-10-05 20:43 | the_CLA | Note Added: 0005153 | |
| 2008-10-05 21:43 | the_CLA | Note Added: 0005155 | |
| 2009-10-29 00:43 | cth103 | Note Added: 0006932 | |
| 2009-10-29 00:43 | cth103 | Status | new => feedback |
| 2009-10-29 17:22 | the_CLA | Note Added: 0006970 | |
| 2009-10-31 12:52 | paul | cost | => 0.00 |
| 2009-10-31 12:52 | paul | Note Added: 0007017 | |
| 2009-10-31 12:52 | paul | Status | feedback => resolved |
| 2009-10-31 12:52 | paul | Resolution | open => fixed |
| 2009-10-31 12:52 | paul | Assigned To | => paul |
| 2020-04-19 20:12 | system | Note Added: 0021484 | |
| 2020-04-19 20:12 | system | Status | resolved => closed |
