LWinterberg
I agree with the general thrust of what you are saying.
Sorry for the long note below - hopefully it is not confusing… as that can easily happen when one covers many things (yet easily miss covering all the points).
YES. Without a good understanding of the actual architecture and implementation of the system - one cannot make “good” judgments about ease and difficulty of a enhancement idea.
YES. Useful to know what would be needed ultimately - having a good view of the potential, full, true evolution /migration path of the “enhancement idea” for a robust design architecture while implementation may proceed in stages.
NO. The example you give about “log the files you import automatically” are kinds of things I will certainly and completely keep out.
*This is an important line I will draw. *
For keeping the requirements semantics and scope precise and contained.
I would like the “Notes Blob” a term, I just coined for the ease of discussion here, remain Opaque to Audacity, and also not Audacity-Aware. The contents of the “Notes Blob” are managed by Users to suit their needs and meanings are known only to them.
Additional Clarifications About the Requirement.
a) Notes Blobs
From my perspective, I will declare them as text-oriented.
Meaning will not contain Media (picture, audio, video or other complex mimes).
User can certainly add include textual Links/URLS to external documents.
b) Blob Editor & UI
Provide functions for viewing, text-editing the contents of the Blob.
Copy/Paste from Clipboards
Plus Print, Export, Import (load a file from the file system).
c) Context & Blob Browser
I had not talked about these or elaborated this so far.
Context represents the attachment point in Audacity for this Blob.
In case of Cakewalk - Blobs are attached to the Overall Project.
This is what was implicitly suggesting so far.
Over time I would like to be able attach Blobs to different elements in Audacity, specific to “selected” contexts. That contextual information stands to add significantly to the organization and clarity of the Blobs.
Like,
Project, Track, Clips, Regions, Audio Data etc.
(I am just giving some illustrative examples suggesting that they may be added, in principle, to any element in the Audacity Data Schema, within reasons of Granularity and Utility).
This impacts Cardinalities.
The Project to Blob 1:1 relationship would start changing.
We may allow 1:N here.
Also Project can have many Blobs resulting from transitive closure of the Blobs attached at lower levels in the data hierarchy.
We can have
A Track may have One or more Blobs.
Similarly Clips etc.
As a result we would need a Blobs Browser to see all the Blobs as well as Navigate/Open Blobs attached to an Audacity Element.
Clearly this would take Blobs to a different League of Functionality and Complexity.
To me this is not even “Near Future” and hence I was not stating it in my original needs/requirements note.
Overall
I will summarize as follows:
Requirements are (a) and (b) only, for the foreseeable future.
(c) gives an idea of the key evolution path from my perspective.
I am not opposed to automated tracking and annotation of Blobs by Audacity for various operations - like Copyright clearing example you mentioned. Along those lines, I would probably vote for auto capturing/tracking do/undo actions.
Thanks to the team. The real time non-destructive effects capability has significantly ameliorated and obviated that problem - which I was struggling with, before.
regards Sri.