Ideas for version 3 » History » Version 22
Version 21 (Chris Cannam, 2015-09-24 03:05 PM) → Version 22/23 (Chris Cannam, 2015-09-24 03:07 PM)
h1. Features for version 3
h2. Implemented
The following are already included in some branch or in some capacity, though the implementation is not necessarily complete.
h5. Audio recording
Live analysis may have to remain out of scope. But recording a clip (using a popup window to start/stop recording) and then analysing that should be quite feasible. Would be useful for apps such as Tony as well.
h5. Unit conversion utility
See #905. This is suitable to ship.
h5. Handle very long audio files
As requested e.g. "here":http://vamp-plugins.org/forum/index.php/topic,276.0.html. Around 30 hours at 44100Hz is a good starting point (exceeding 2^32 frames). This is mostly working in 64-bit builds but there are some associated problems still, such as #1284.
h5. True retina rendering on OS/X
Largely done, see #1158.
h5. Icon and widget overhaul
Scalable icons for high-resolution displays, etc. This is really a requirement for the true retina support. This work is started in the scalable-icons branch but there is still quite a bit to do.
h5. Multiplex audio input into plugins
Allowing plugins like MATCH that require separate audio files as inputs to be run and output displayed within SV. See #1108. This is essentially working but needs a number of fixes.
h5. Simpler FFT model
The existing FFT model code in SV is based on assumptions that are not always reliable, in particular that a machine has vastly more hard disc space than any other storage (which became unreliable when SSDs started appearing, though sizes are going back up again now) and that it's cheaper to store and recall transform outputs for large FFT sizes than it is to recompute them from the original audio (this is still just about true, but only just). Meanwhile the code to handle FFT cacheing is complex and problematic in many ways. There is now a branch @simple-fft-model@ which replaces it with only the bare minimum of cacheing and it works more predictably, though it may still need some work in the SpectrogramLayer code to make the results faster to render.
h2. Required
Blockers for SV v3.0. v3.0 (in my mind at least).
h5. Windows 64-bit build
Not much point in being able to open very long audio files in the 64-bit build, if the majority of SV users aren't getting the 64-bit build.
The blocker here is loading Vamp plugins, which are all 32-bit only on Windows at the moment (and some of the existing binaries will likely never be updated). So this has a dependency on being able to run 32-bit plugins from a 64-bit build, which probably means running the plugins in a separate process (though I've listed that as a separate item below because it isn't necessarily the only way to achieve this).
h5. Colourblind-safe default colour scheme for spectrogram and colour 3d plot
The green-red default scheme is about as bad as it gets for colourblind viewers. I wince every time I see a poster or presentation that uses screengrabs from it.
h5. Improve layer parameter box layout for OS/X
The layer parameters easily get very squashed on OS/X (and only there, I wonder why). This absolutely needs fixing. See #1304.
h2. Desired
These are features I am hoping to get into the release, but haven't implemented yet.
h5. Audio recording
Live analysis may have to remain out of scope. But recording a clip (using a popup window to start/stop recording) and then analysing that should be quite feasible. Would be useful for apps such as Tony as well.
h5. Additional normalisations for colour 3d plot and spectrogram
The normalisation used in Tony is quite useful -- it exists on a branch (normalize_hybrid_option) in spectrogram only, but without any sensible UI. See also #147. Additionally recent default branch of SV has added a feature-derivative option to the colour 3d plot -- I actually think this was a mistake, at least to add a whole new button for it. That should either be backed out or replaced with better UI.
h5. Permit changing colour of overview widget waveform
Some chap who made a nice Youtube video about SV complained that he hated the green waveform colour in the overview. Anyone who goes to the trouble of making a nice video about SV deserves some small compensations. This is slightly trickier to work out where to fit into the UI than I'd originally thought though.
h5. Combo gain/pan widgets
As used in Tony, but with higher adjustable resolution.
h5. Multi-feature editing
See #209.
h5. Run plugins in a separate process
For reliability, and to allow e.g. Win64 build to run Win32 plugins
h2. Other
Things that have been added to this list at some point but that are currently not planned for inclusion.
h5. Sub-sample zoom
Currently SV limits the max zoom level to 1 pixel per sample: you can't zoom in to sub-sample resolutions. Might be nice if you could. (Of course the sub-sample display would need to be accurate, i.e. oversampled.) There are rather a lot of assumptions about integer zoom levels in the code so this would take a bit of care.
I'd definitely like to do this, but probably not for the next major release.
h5. Score display
Either or both of: page-by-page PDF rendering along the lines of the Image layer; proper score rendering from a symbolic format.
h5. Collapsible quick-view strips
See #25. Tony's selection strip might give some idea of how this could look.
h5. SV Mini Edition (and Tablet Editions?)
See "SV Mini project":/projects/sv-mini.
h5. Integrate IMAF support
The "IMAF build":/projects/sv-imaf-enc is still a separate project and branch; what's the best way to merge it?
h2. Unknown status
h5. Bundle some plugins
See "SF feature request 151":http://sourceforge.net/p/sv1/feature-requests/151/. Bundling at least MATCH, VamPy, and the QM plugins would be a great help.
h5. SVG export
Has been requested several times, but see e.g. "SF feature request 146":http://sourceforge.net/p/sv1/feature-requests/146/.
h2. Implemented
The following are already included in some branch or in some capacity, though the implementation is not necessarily complete.
h5. Audio recording
Live analysis may have to remain out of scope. But recording a clip (using a popup window to start/stop recording) and then analysing that should be quite feasible. Would be useful for apps such as Tony as well.
h5. Unit conversion utility
See #905. This is suitable to ship.
h5. Handle very long audio files
As requested e.g. "here":http://vamp-plugins.org/forum/index.php/topic,276.0.html. Around 30 hours at 44100Hz is a good starting point (exceeding 2^32 frames). This is mostly working in 64-bit builds but there are some associated problems still, such as #1284.
h5. True retina rendering on OS/X
Largely done, see #1158.
h5. Icon and widget overhaul
Scalable icons for high-resolution displays, etc. This is really a requirement for the true retina support. This work is started in the scalable-icons branch but there is still quite a bit to do.
h5. Multiplex audio input into plugins
Allowing plugins like MATCH that require separate audio files as inputs to be run and output displayed within SV. See #1108. This is essentially working but needs a number of fixes.
h5. Simpler FFT model
The existing FFT model code in SV is based on assumptions that are not always reliable, in particular that a machine has vastly more hard disc space than any other storage (which became unreliable when SSDs started appearing, though sizes are going back up again now) and that it's cheaper to store and recall transform outputs for large FFT sizes than it is to recompute them from the original audio (this is still just about true, but only just). Meanwhile the code to handle FFT cacheing is complex and problematic in many ways. There is now a branch @simple-fft-model@ which replaces it with only the bare minimum of cacheing and it works more predictably, though it may still need some work in the SpectrogramLayer code to make the results faster to render.
h2. Required
Blockers for SV v3.0. v3.0 (in my mind at least).
h5. Windows 64-bit build
Not much point in being able to open very long audio files in the 64-bit build, if the majority of SV users aren't getting the 64-bit build.
The blocker here is loading Vamp plugins, which are all 32-bit only on Windows at the moment (and some of the existing binaries will likely never be updated). So this has a dependency on being able to run 32-bit plugins from a 64-bit build, which probably means running the plugins in a separate process (though I've listed that as a separate item below because it isn't necessarily the only way to achieve this).
h5. Colourblind-safe default colour scheme for spectrogram and colour 3d plot
The green-red default scheme is about as bad as it gets for colourblind viewers. I wince every time I see a poster or presentation that uses screengrabs from it.
h5. Improve layer parameter box layout for OS/X
The layer parameters easily get very squashed on OS/X (and only there, I wonder why). This absolutely needs fixing. See #1304.
h2. Desired
These are features I am hoping to get into the release, but haven't implemented yet.
h5. Audio recording
Live analysis may have to remain out of scope. But recording a clip (using a popup window to start/stop recording) and then analysing that should be quite feasible. Would be useful for apps such as Tony as well.
h5. Additional normalisations for colour 3d plot and spectrogram
The normalisation used in Tony is quite useful -- it exists on a branch (normalize_hybrid_option) in spectrogram only, but without any sensible UI. See also #147. Additionally recent default branch of SV has added a feature-derivative option to the colour 3d plot -- I actually think this was a mistake, at least to add a whole new button for it. That should either be backed out or replaced with better UI.
h5. Permit changing colour of overview widget waveform
Some chap who made a nice Youtube video about SV complained that he hated the green waveform colour in the overview. Anyone who goes to the trouble of making a nice video about SV deserves some small compensations. This is slightly trickier to work out where to fit into the UI than I'd originally thought though.
h5. Combo gain/pan widgets
As used in Tony, but with higher adjustable resolution.
h5. Multi-feature editing
See #209.
h5. Run plugins in a separate process
For reliability, and to allow e.g. Win64 build to run Win32 plugins
h2. Other
Things that have been added to this list at some point but that are currently not planned for inclusion.
h5. Sub-sample zoom
Currently SV limits the max zoom level to 1 pixel per sample: you can't zoom in to sub-sample resolutions. Might be nice if you could. (Of course the sub-sample display would need to be accurate, i.e. oversampled.) There are rather a lot of assumptions about integer zoom levels in the code so this would take a bit of care.
I'd definitely like to do this, but probably not for the next major release.
h5. Score display
Either or both of: page-by-page PDF rendering along the lines of the Image layer; proper score rendering from a symbolic format.
h5. Collapsible quick-view strips
See #25. Tony's selection strip might give some idea of how this could look.
h5. SV Mini Edition (and Tablet Editions?)
See "SV Mini project":/projects/sv-mini.
h5. Integrate IMAF support
The "IMAF build":/projects/sv-imaf-enc is still a separate project and branch; what's the best way to merge it?
h2. Unknown status
h5. Bundle some plugins
See "SF feature request 151":http://sourceforge.net/p/sv1/feature-requests/151/. Bundling at least MATCH, VamPy, and the QM plugins would be a great help.
h5. SVG export
Has been requested several times, but see e.g. "SF feature request 146":http://sourceforge.net/p/sv1/feature-requests/146/.