Talk:GSoC Ideas 2009

Summarized 11 March 09

 * Text of GSoC Ideas -> emphasise "useful release".
 * Linked to Release checklist not aiming for 1.4 and Feature Requests in De-Niggler.
 * Improving response in multi-track projects orders of magnitude more important than split-new refinement.
 * Must KEEP split-new and duplicate new. There were complaints when we removed split new from Beta
 * Bugfix Ninja -> Bugfix Superstar, and this and De-niggler with more staid wording

More discussion at time of finalising GSoC ideas March 2009

 * Gale: Yes. Some command to split new/duplicate into an existing track if there is white space available would be handy but the rules it obeys would need thinking about (two tracks selected for "split into available track" with one of the available tracks between the selected ones)? There is of course Time Shift Tool for those who can see, and Mix and Render to amalgamate tracks (the mix shifting to bottom, so possibly out of view, being one of my own niggles). Generally, the difficulty of fitting more than a limited number of tracks comfortably is another niggle with multi-track projects, to add to "responsiveness". This is something else I think we'll have to grasp sooner or later, whether with a tree, mixing panel or whatever. I think the buttons and sliders on the tracks themselves are a liability, with all the hassle of expanding/contracting and Fit Vertically when you want change the sliders/buttons (try setting Fit Vertically "on" in Preferences, drag a track bottom downwards to adjust the gain and pan at the same time, and watch what happens).

In the outline we don't have to spell out the exact solution. Part of the brief for a good de-niggler is to recognise what a good solution would be. I'm thinking we might also take optimization out of it and make 'Speed Demon' a new idea, with just Michael as potential mentor - and we'd have to be very careful to stress we want a sequence of complete in themselves changes that improve responsiveness step at a time, a task at a time, not a big-bang "let's re-write the wave rendering". It'd be a bit featurey though so I've not made a new idea for it.
 * Gale: I think that's the problem with splitting it at this stage so perhaps we shouldn't. Speed is a particular class of niggle, and we need perhaps a broader view of all niggles for now that gets some bugs fixed into the bargain? After 1.4 maybe a holistic approach to "speed" or "multi-track usability" might be good. I think other things affecting speed are threading issues too?

James Gale, this all makes good sense. I'd be happy with the rule 'add it in last track, if there is space there, otherwise new track'. That is discoverable, it will usually happen on the second split-new that a user does. It also is flexible. You can drag any track to be the last.
 * Gale: Thanks. Let's keep a menu item for the current meaning of Edit > Duplicate too though (i.e. Duplicate New)? I don't think people will want to have to add a track manually for the second and subsequent duplicates if that's what they really want (e.g so they can control gain/pan individually). This makes the Edit menu even longer but I don't see much choice if there's a strong case for letting second/subsequent splits/duplicates stop in one track.

James My thinking is make the behaviour a preference. Having many menu items for very similar things confuses. Few people will want to mix the two 'workflows' and those who do can take the hit of manually adding an extra track.


 * Gale: Certainly another way to do it, though Preferences are pretty full too. Factors against a preference: less discoverable (especially for VI users where ploughing through Preferences is a pain), and I think default would have to be current behaviour (Split *New* and Duplicate seem to somehow imply it, and are heavily used so a support problem to have it do something else). In favour: what do we call the "Split New" that always makes subsequent splits into the same new track if it can - "Split Out", "Split to Track"? I'm marginally inclined to keep everything in menus, because I think sooner or later we'll have to collapse some items in the Edit menu into a popout to restrict the length anyway.