-
Notifications
You must be signed in to change notification settings - Fork 138
Guidelines and Roadmap
Moving forward let's plan to follow the Semantic Versioning guidelines. This means all future changes should be assessed based on whether they are a backward-compatible bug fix or refactor, backward-compatible feature addition, or incompatible public API change.
We should push out bug fix versions reasonably quickly and can use Issues to track bugs and create Milestones for each bug fix release so that Issues can be tagged with which release they occurred in. This is primarily to simplify creating the changelog for each release, which we've been kinda shitty at in the past.
Depending on the complexity of a refactoring pass, a private branch should be created for the work and then merged back into the main branch when complete. The idea is to always have the main branch in a releasable state so that bug fix releases never need to be delayed because a refactoring job is only partially complete.
Feature additions should be handled similarly to refactoring. We don't want new public classes showing up in the documentation that are not yet fully functional.
API changes will also be developed in a branch until complete, but one that will likely be pushed to Github so that it is available to everyone. We should try to keep these RARE because it's a potential pain for users to deal with and because we are not going to have the bandwidth to both move forward with a new major release and release bug fix versions of the previous major release for people who don't want to upgrade for whatever reason.
Version 2.2.1 will likely go out in mid-January. There are just a couple additional bugs that can hopefully be resolved for additional bug fix releases, these will have Milestones set appropriately in the Issues list.
Refactoring passes that we can consider for 2.2.x releases would be:
- change AudioPlayer so that it wraps a FilePlayer UGen, in anticipation of looping methods getting removed from the AudioRecordingStream interface
- change AudioSample so that it wraps a Sampler UGen, in anticipation of removing the requirement that implementations of MinimServiceProvider need to provide a concrete implementation of AudioSample
- implement a shared AudioOut scheme in the Minim class so that multiple AudioPlayer objects don't result in multiple AudioOut objects
The primary goal of Version 3.0.0 is to remove all references to JavaSound from packages other than ddf.minim.javasound in order to prepare the way for implementing Android support. Secondarily it is to remove functionality that has already been marked as deprecated in order to present a cleaner interface to new users. Major tasks include:
- creation of Minim-specific AudioFormat object
- simplification of interfaces in ddf.minim.spi to minimize implementation requirements
- removing AudioRecordingStream and AudioRecording and moving stream position setting methods to AudioStream
- removing loop setting requirements altogether
- removing getAudioSample from MinimServiceProvider
- removing getAudioRecording from MinimServiceProvider
- renaming getAudioRecordingStream to getAudioStream and requiring only a filename
- removal of "buffered" argument for getSampleRecorder, we should support recording to memory at a higher level
- removal of Effectable and Polyphonic interfaces and implementations
- possible removal of AudioSignal and AudioEffect entirely, but could consider providing adapter classes so that people who have implemented these things already can easy hook into the UGen framework.
- removal of references to JavaSound Control objects. preference would be to keep the get/set/shift methods of Controller and implement them with UGens under the hood.
This is where will see Android support. There is no target date for this as of yet.