param-resolutions extension #428
Conversation
Add .DS_Store to .gitignore (MacOS specific) Fixes: free-audio#390
Summarizing the conversation in discussion free-audio#414, this PR adds a more complete description of when the realtime constraint must be met, by which party, and how it interacts with the thread safe tag.
- allow plugin_latency->get to be called during plugin->activate - require host_latency->changed to be called during plugin->activate
- the plugin interfaces have been separated into 2 independent ones - the plugin interfaces are optional - simplification of the design
…-audio#422) * Add a description of the expectation of request_callback timing Without making a requirement, indicate the intent of the timing. * Add an apostrophe * Add host can starve feedback from alex * more review feedback * notjusthosts
|
could these two be combined into a 'param-extended-info' extension which was also somehow extensible easily? |
I think it is cool that they have their own interface. |
|
Regarding the extension, in the semitone example, would the user wants to be able to "quantize" the steps? So if he is at |
This is a good question. Concerning quantizing the distance (0.23 -> 1.23) vs. quantizing the absolute value, I think both can be the desired behaviour. E.g. let's use a coarse octave resolution as an example:
I'm against depending on Defining the "absolute grid" also implies that at each grid point there potentially is a meaningful value (e.g. a whole semitone). Thus I think it is always good to snap to the next meaningful value. But there could be a flag "prefer_relative_increments" to give the host a hint that it it can quantize the distance, not the absolute value for better user experience. Makes sense? |
abique
force-pushed
the
next
branch
5 times, most recently
from
533e849 to
50f004f
Compare
see in-code documentation. If something is not specified enough, please ask/propose changes of course 👍