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

CLAP 1.2.3 #432

Merged
merged 14 commits into from
Jan 20, 2025
Merged

CLAP 1.2.3 #432

merged 14 commits into from
Jan 20, 2025

Conversation

abique
Copy link
Contributor

@abique abique commented Nov 18, 2024

No description provided.

@abique abique force-pushed the next branch 2 times, most recently from 773e346 to 069d784 Compare November 18, 2024 19:32
baconpaul and others added 3 commits November 18, 2024 20:35
* 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
@abique abique force-pushed the next branch 2 times, most recently from fc4a9c3 to ab54bc5 Compare November 18, 2024 19:46
@abique abique marked this pull request as ready for review November 18, 2024 19:46
@abique abique self-assigned this Nov 18, 2024
Copy link
Collaborator

@baconpaul baconpaul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some comments on the location extension.

include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
@baconpaul
Copy link
Collaborator

LGTM also.

Copy link
Contributor

@messmerd messmerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some questions and suggestions regarding the location extension

include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
include/clap/ext/draft/location.h Show resolved Hide resolved
include/clap/ext/draft/location.h Show resolved Hide resolved
include/clap/ext/draft/location.h Outdated Show resolved Hide resolved
include/clap/ext/draft/location.h Show resolved Hide resolved
include/clap/ext/draft/location.h Show resolved Hide resolved
@messmerd
Copy link
Contributor

How much information should a host provide to a plugin through the location extension? Should it provide all the information it can, or only information about the plugin itself?

@abique
Copy link
Contributor Author

abique commented Dec 2, 2024

How much information should a host provide to a plugin through the location extension? Should it provide all the information it can, or only information about the plugin itself?

I'm not sure I understood well your question.

Think that you have a very large project, all you need to know your location is:
/project/track_group[0]/track[3]/device[6]

Here from the root track group, take the third track, then the 6th device and here we are.

Does that clarify the question?

jatinchowdhury18 and others added 2 commits December 19, 2024 16:41
comment refered to a previous version of the ambisonic extension.
@abique
Copy link
Contributor Author

abique commented Dec 19, 2024

I've squashed some changes to the scratch-memory for max_concurrency_hint, and simplified the doc.

@messmerd
Copy link
Contributor

@abique
Sorry it took so long for me to respond.

Think that you have a very large project, all you need to know your location is:
/project/track_group[0]/track[3]/device[6]

Okay, I was assuming that since the location API allows the host to tell the plugin its index within a parent element (i.e. in your example, the device is on the 3rd track), it could also provide information about other parts of the project structure which are not directly related to the plugin itself.

For example, if a plugin is the 2nd effect in an effects chain, could the location API provide information about the effects before it and after it in the chain?

I was assuming it could, since I don't see what the purpose is in telling a plugin it is the 2nd effect in the chain if it cannot also know what devices are the 1st and the 3rd.

But if I'm wrong about that, as it seems that I am based on your comment, that would explain my initial confusion about how the location API is supposed to provide that information. All location information would be as simple as your example - it can only provide the minimal amount of information needed to identify a device's location within the project tree, similar to a filesystem path.

Copy link
Contributor

@messmerd messmerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the undo, scratch-memory, location, and gain-reduction extensions be listed in the README alongside the other extensions?

include/clap/events.h Outdated Show resolved Hide resolved
@baconpaul
Copy link
Collaborator

I had suggested on discord and I think alex agreed that gain_reduction may be better as gain_adjustment_display since

  1. It is an adjustment (+ve and -ve values)
  2. It is a display thing the plugin reports, not a gain adjuster that the host applies to the signal

If 'display' bugs people then gain_adjustment_reporting is also a good choice, for hosts which don't display it.

@abique
Copy link
Contributor Author

abique commented Jan 17, 2025

Maybe I like gain_adjustment_reporting even more. 👍

@abique
Copy link
Contributor Author

abique commented Jan 17, 2025

Should the undo, scratch-memory, location, and gain-reduction extensions be listed in the README alongside the other extensions?

We can wait for those to be stable.

ChangeLog.md Outdated Show resolved Hide resolved
include/clap/all.h Outdated Show resolved Hide resolved
@@ -266,6 +271,12 @@ enum clap_transport_flags {
CLAP_TRANSPORT_IS_WITHIN_PRE_ROLL = 1 << 7,
};

// clap_event_transport provides song position, tempo, and similar information
// from the host to the plugin. There are two ways a host communicates these values.
// In the `clap_process` structure sent to each processing block, the host must
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote must here, and I think that's right, but lets all be sure that we don't want a null transport in process to be valid. If a null transport in process is valid we should change this to 'may'

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe 'may and is strongly encouraged to'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transport is allowed to be null in the process struct, because some hosts may not have a transport, for example a mini host that runs a distortion effect in a guitar pedal.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrected in #443

include/clap/ext/draft/gain-reduction.h Outdated Show resolved Hide resolved
@abique abique force-pushed the next branch 3 times, most recently from ab437e3 to 7087e88 Compare January 17, 2025 23:43
@schwaaa
Copy link
Contributor

schwaaa commented Jan 18, 2025

Maybe I like gain_adjustment_reporting even more. 👍

I just saw this comment. Either way is fine with me, if you have a preference I'm happy to change it from the current gain_adjustment_display to gain_adjustment_reporting.

@baconpaul
Copy link
Collaborator

Maybe I like gain_adjustment_reporting even more. 👍

I just saw this comment. Either way is fine with me, if you have a preference I'm happy to change it from the current gain_adjustment_display to gain_adjustment_reporting.

After our (painful, long) conversation yesterday I think the best name is gain_adjustment_metering since this is the first metering extension we have (a metering extension is an extension where you grab a value on the audio thread with a functionally const double get function at the end of a process block, since alex didn't read the entire conversation, appropriately)

@baconpaul
Copy link
Collaborator

the conversation was painful and long because of me, by the way! Again sorry for that but I think we got a better result for it :)

basically expand some comments around ranges, meaning, and so on.
@abique abique force-pushed the next branch 2 times, most recently from 05fc5ff to 406a11c Compare January 20, 2025 17:12
@abique abique merged commit 309d1da into main Jan 20, 2025
7 checks passed
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.