Closed skrytt closed 5 years ago
I decided to build a readline-style solution using third-party crate "rustyline". As part of implementing this, I redid all of the command-line input code and moved it into its own "cli" module.
The new solution allows tab completion of commands. There is more work to do in this area, but it's a nice starting point.
Will rename this ticket and use it to track progress in that area.
Need to determine a nice solution to setting parameters, which have:
Also would like to be able to bind parameters to controllers:
Thinking to aim for the following (using filter frequency ...
as an example):
filter frequency <base>
filter frequency <base> <max>
filter frequency learn
filter frequency cc<##>
filter frequency <base> <max> learn
filter frequency <base> <max> cc<##>
Since looking at how VST might work, I decided to simplify things for the time being:
Each parameter has a predefined range (base and max values, and a default value that falls within or on the edge of that range.
Supported commands are now like
filter frequency 100
(this sets the parameter, and is only useful if it is not being modulated)
filter frequency learn
(sets midi learn mode for the parameter, binds to the next CC controller moved)
filter frequency cc <###>
(binds a specified CC number to the parameter)
It is currently not possible to adjust the range of the controller for simplicity. I am considering whether to add this back in future.
Since looking at how VST might work, I decided to simplify things for the time being:
Each parameter has a predefined range (base and max values, and a default value that falls within or on the edge of that range.
Supported commands are now like
filter frequency 100
(this sets the parameter, and is only useful if it is not being modulated)filter frequency learn
(sets midi learn mode for the parameter, binds to the next CC controller moved)filter frequency cc <###>
(binds a specified CC number to the parameter)It is currently not possible to adjust the range of the controller for simplicity. I am considering whether to add this back in future.
The above work has been completed; the command line interface works in the described way as of the previous comment.
The current synth design includes a crude event loop for receiving text input from the user, interacting with the audio thread to apply changes that are required, then providing the result back to the user.
This works fine for now but as the functionality of the event loop becomes increasingly complex the code is going to become harder and harder to understand. It's not the intention here to redesign event loops - can't this be abstracted using a third-party event loop library?