Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

param-resolutions extension #428

Draft
wants to merge 9 commits into
base: next
Choose a base branch
from

Conversation

Trinitou
Copy link
Contributor

@Trinitou Trinitou commented Nov 1, 2024

see in-code documentation. If something is not specified enough, please ask/propose changes of course 👍

NatureIsFrequency and others added 8 commits September 2, 2024 16:06
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
@Trinitou Trinitou changed the base branch from main to next November 1, 2024 04:32
@baconpaul
Copy link
Collaborator

could these two be combined into a 'param-extended-info' extension which was also somehow extensible easily?

@abique
Copy link
Contributor

abique commented Nov 1, 2024

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.
In the undo ext we did split the interface to lower the requirements on implementing one or the other.

@abique
Copy link
Contributor

abique commented Nov 1, 2024

Regarding the extension, in the semitone example, would the user wants to be able to "quantize" the steps?

So if he is at 0.23 he'd jump to 1.0 instead of 1.23?
Would the host implicitly quantize or there would be a flag?
Toward which value should we quantize the distance? Would it be the value origin?

@Trinitou
Copy link
Contributor Author

Trinitou commented Nov 1, 2024

Regarding the extension, in the semitone example, would the user wants to be able to "quantize" the steps?

So if he is at 0.23 he'd jump to 1.0 instead of 1.23? Would the host implicitly quantize or there would be a flag? Toward which value should we quantize the distance? Would it be the value origin?

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:

  • for a relative "Transpose" parameter it might be good to snap to whole octave values (+7.23st -> +12.00st)
  • but for an absolute "Pitch" parameter it might be more adequate to move the parameter by exactly one octave (from C1+56cents to C2+56cents)

I'm against depending on param-origin here. But instead just depend on param so a resolution together with min_value and max_value define an absolute grid of the value range. If implementing both extensions, it would probably be good to place the origin_value exactly on one of the grid points. But more as a recommendation but not a hard requirement.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants