I thought maybe we can start thinking about some projects we can propose for this years GSOC (they can also be feature requests for future versions ). I don't know about some of the technical issues that may arise but we can discuss things in this thread and then add the proposals to the wiki for the students to choose. Some things have to do with MLT so maybe we can see if Dan and the other devs agree to participate.

Audio
Audio Mixer (maybe use the code of qtractor)
LV2 Filters (mlt)
Match audio tracks (mlt?)

Timeline
Tabs in timeline
Change height of individual tracks

Editing
Slip and Roll move modes

Import/Export
MOX (mlt)
EDL (mlt)

Effects
SlowmoVideo
Gmic (mlt?)
Keyframeable effects

General
Shortcut system
GPU processing for timeline
Multicam editing

EDIT: something's broken here -- I'm TheDiveO but now logged in as farid???

Let me throw in also another idea.

Transition Tree pane -- a new pane for both newcomers and old hands that visualizes for the current cursor position in timeline how MLT actually combines the individual clips.

My idea is as follows: many users seem to struggle as soon as they want to compose more complex scenes using multiple transition in a way where simply layering does not work. In the past I also came across situations where I scratched my head trying to figure out how to tell Kdenlive what I want to achieve and not understanding what Kdenlive actually did. So this view would show on the basis how MLT works how the tree(!) of transitions actually looks like and what the clips (with effects) are that are going into this transition tree.

Remember that MLT uses a tractor, pulling in only those things actually required, leaving out clips in the timeline that are not part of the transition tree connected with the tractor.

This visualization could also help users quickly figuring out when a clip doesn't form part of the final rendering tree despite adding a transition to it. For instance, clips on tracks not used could be specially marked as such.

The overall reading flow of the transition tree would be left to right, bottom to top(!). The final rendered result would be in the bottom right and on height with the track where the final transition occurs. From there the tractor flow would go left and up.

This is just a coarse description of the idea I have in mind. Would such a view be interesting to other users, both new and old hand?

(Posting this now correctly as TheDiveO)

Let me throw in also another idea.

Transition Tree pane -- a new pane for both newcomers and old hands that visualizes for the current cursor position in timeline how MLT actually combines the individual clips.

My idea is as follows: many users seem to struggle as soon as they want to compose more complex scenes using multiple transition in a way where simply layering does not work. In the past I also came across situations where I scratched my head trying to figure out how to tell Kdenlive what I want to achieve and not understanding what Kdenlive actually did. So this view would show on the basis how MLT works how the tree(!) of transitions actually looks like and what the clips (with effects) are that are going into this transition tree.

Remember that MLT uses a tractor, pulling in only those things actually required, leaving out clips in the timeline that are not part of the transition tree connected with the tractor.

This visualization could also help users quickly figuring out when a clip doesn't form part of the final rendering tree despite adding a transition to it. For instance, clips on tracks not used could be specially marked as such.

The overall reading flow of the transition tree would be left to right, bottom to top(!). The final rendered result would be in the bottom right and on height with the track where the final transition occurs. From there the tractor flow would go left and up.

This is just a coarse description of the idea I have in mind. Would such a view be interesting to other users, both new and old hand?

test, please ignore.

Maybe also we could add:

Windows port
OSX port

Don't know if they are too complicated for a GSOC though.

Hello,

Thanks for brainstorming.

The problem with SoC is mentoring: I tried last year but this was a pain as I had not enough availability (could have worked if the student had been already used to hacking kdenlive, but we can't ask for this).
I'm not ready to feel that stress again this year, and I think JB neither.

Other thing regarding MLT contribution: Google allocates slots more easily to big organizations like KDE, for small projects it seems to be quite much paperwork. The rule to accept foreign projects under the organization for SoC was quite fuzzy but it is getting more clearly refused (maybe I didn't understand well).

Regarding wishes, for me the place were I would look for is down in the Roadmap wiki page... Ok, maybe not a place for open discussion, but in the end it would be good to keep a trace of IRC/forum/etc choices summarized in an organized place?

I think Win/OSX ports could be topics for which we could find rather autonomous students, and I think it could be interesting (our fear was to boost problems without boosting *code* contributions)