Database for all files; File history; File bookmarks.

[HSJIII]

I save my work as I go. I try to be very strict about doing this, because I've seen lots of crashes over the years. An unfortunate side effect of this is that FL's "recently opened" shortcut off the file menu tends to get cluttered with recent back versions, and everything before that is like water under the bridge. It's on disk, but harder to find. Often the things I need to do are scattered across multiple project and audio media files, and I would like to be able to access them more freely, and from inside the FL environment. When the file menu shortcuts are gone, I have to go to disk instead. Then when I open files from disk, very often there is version incompatibility, because I've been using FL since version 4. What opened easily back then is now a tedious open, with mandatory file browsing, etc. This is possible, but it breaks the stride of the workflow... so I understand that we can "dig" for those files with the file browser, but I have something a bit more comprehensive in mind here. That brings me to the to-do:

I believe it would help workflow with FL if there were a database utility which could search and maintain an index on specified media and project file directories. The database would track content with this metadata (some of it would be user-provided, and others FL could handle by itself):
A description of the media file or project.
A star rating.
What recent change was made to it (i.e. what differentiates it from version 1.00231 and version 1.00230, etc).
The mood and/or special purpose of the media.
The location on disk.
A shortcut to allow the media to be instantly dragged into FL.
What version of FL the project file was made with (for compatible loading).
What media, vst, plugin, settings files the project depends on (shortcuts included).
What soundcard dependencies are used by the project file. (very critical if you are working on a system with more than one card)
Audio criteria. (What bitrate audio files use, etc.)
Midi criteria.
Primary purpose of the project file (i.e. an audio processing effect, a song, a composition, an instrument, etc)
Incidental side breakthroughs of the project file (i.e. if you discovered a really cool sound there, or if you "worked out" a method for accomplishing something new)
A brief summary.
A name.
Descriptive Tags.
Date Created, Modified.
What is being worked on (i.e. testing an improvement, trying to fix a problem, adding automation, whatever your "current goal" is inside a project.
Plugin Settings (which plugin the setting or preset is for, what version of the plugin, directory, intended purpose, description, etc)

Then, through an FL module, the user could search the governed directories by specifying these metadata with an advanced search (SQL under the hood), and find everything matching the specified search criteria. The search would conclude with some basic ties which let the user "skim" the "meaning" of what they have found (like how you can hear an audio file when you click it in the FL file browser).

I believe that this sort of media data mining capability would really expand the accessibility of older projects. When I think of how much I have on disk (that's multiple thousands of flp projects), and how hard it is to find things I know I spent years working on, it really makes me feel a little crazy... what I've done just goes to this pool of hard-to-find stuff. Organization only goes so far when the media was created over the course of years, multiple versions of FL, changing computer hardware, changing operating system... my directory structure itself has changed many times, and I simply can not keep track of it all... I try to be organized, but it's just overwhelming.

I understand that this is a "tall order"... it's a fully fledged feature, seriously, but I also believe it could put FL into the "big league", and put it onto the radar even for media production companies with huge file bases, so although it would require some work on your part, I think you could certainly market it afterwards.

As a final note: If you decide to proceed with this, consider using MySQL as your database engine. There is a version of MySQL which can be compiled into an exe so you don't need to install a separate database server on the host system. It's free. I've programmed with it before. It uses SQL, just like any other database. The learning curve is fast. I'd never used SQL before I used it, and yet I made some very functional databases with it.

[HSJIII]

I almost forgot to expand on the other two idea...