-
Notifications
You must be signed in to change notification settings - Fork 103
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
base: main
Are you sure you want to change the base?
CLAP 1.2.3 #432
Changes from 9 commits
0473fa2
6f80a82
851aa37
8d2ca0f
19d8d01
73cc632
a85a2a1
0bcbee9
50f004f
3b9e673
e19a50d
f7c28f9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
#pragma once | ||
|
||
#include "../../color.h" | ||
#include "../../plugin.h" | ||
#include "../../string-sizes.h" | ||
|
||
// This extension allows a host to tell the plugin more about its position | ||
// within a project or session. | ||
|
||
static CLAP_CONSTEXPR const char CLAP_EXT_LOCATION[] = "clap.location/1"; | ||
|
||
#ifdef __cplusplus | ||
extern "C" { | ||
#endif | ||
|
||
enum { | ||
// Represents a document/project/session. | ||
CLAP_PLUGIN_LOCATION_PROJECT = 1, | ||
|
||
// Represents a group of tracks. | ||
// It can contain both track groups, tracks and devices (post processing). | ||
abique marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// The first device within a track group has the index of | ||
// the last track or track group within this group + 1. | ||
Comment on lines
+22
to
+23
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Specifically the first device, or should this be the first child (whether that is track group, track, or device?). What is the purpose of setting the index to that value? Is it to tell the plugin the range of location elements that are children (direct or not) of the parent element? That should probably be made clear. Is the first child required to immediately follow its parent element in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, it could be simplified. This is the model:
|
||
CLAP_PLUGIN_LOCATION_TRACK_GROUP = 2, | ||
|
||
// Represents a single tracks. It contains devices (serial). | ||
abique marked this conversation as resolved.
Show resolved
Hide resolved
|
||
CLAP_PLUGIN_LOCATION_TRACK = 3, | ||
|
||
// Represents a single device. | ||
// It contains other nested device chains. | ||
abique marked this conversation as resolved.
Show resolved
Hide resolved
|
||
CLAP_PLUGIN_LOCATION_DEVICE = 4, | ||
|
||
// Represents a nested device chain (serial). | ||
// Its parent must be a device. | ||
// It contains other devices. | ||
CLAP_PLUGIN_LOCATION_NESTED_DEVICE_CHAIN = 5, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a reason why nested device chains & devices function differently from how track groups & tracks function? That is, why do device chains need to be a child of a device rather than function as a "device group" which can have child devices? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A device chain is a serial list of devices. |
||
}; | ||
|
||
typedef struct clap_plugin_location_element { | ||
// Kind of the element, must be one of the CLAP_PLUGIN_LOCATION_* values. | ||
uint32_t kind; | ||
|
||
// Index within the parent element. | ||
// Set to 0 if irrelevant. | ||
uint32_t index; | ||
Comment on lines
+44
to
+46
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I could be completely wrong, but it seems like a simpler way of flattening the tree would be to specify that the order of elements in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The index here, refers to the position within the track/device_chain/... |
||
|
||
// Internal ID of the element. | ||
// This is not intended for display to the user, | ||
// but rather to give the host a potential quick way for lookups. | ||
char id[CLAP_PATH_SIZE]; | ||
|
||
// User friendly name of the element. | ||
char name[CLAP_NAME_SIZE]; | ||
|
||
// Color for this element, should be CLAP_COLOR_TRANSPARENT if no color is | ||
// used for this element. | ||
clap_color_t color; | ||
} clap_plugin_location_element_t; | ||
|
||
typedef struct clap_plugin_location { | ||
// Called by the host when the location of the plugin instance changes. | ||
// | ||
// The last item in this array always refers to the device itself, and as | ||
// such is expected to be of kind CLAP_PLUGIN_LOCATION_DEVICE. | ||
// [main-thread] | ||
void(CLAP_ABI *set_location)(clap_plugin_t *plugin, | ||
clap_plugin_location_element_t *path, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I understand correctly, this array is a flattened tree structure? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes it is an array, which describes the path toward the current plugin instance. |
||
uint32_t num_elements); | ||
} clap_plugin_location_t; | ||
|
||
#ifdef __cplusplus | ||
} | ||
#endif |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
#pragma once | ||
|
||
#include "../../plugin.h" | ||
|
||
// This extension lets the plugin request "scratch" memory | ||
// from the host. Scratch memory can be accessed during the | ||
// `process()` callback, but its content is not persistent | ||
// between callbacks. | ||
// | ||
// The motivation for this extension is to allow the plugin host | ||
// to "share" a single scratch buffer across multiple plugin | ||
// instances. | ||
// | ||
// For example, imagine the host needs to process three plugins | ||
// in sequence, and each plugin requires 10K of scratch memory. | ||
// If each plugin pre-allocates its own scratch memory, then 30K | ||
// of memory is being allocated in total. However, if each plugin | ||
// requests 10K of scratch memory from the host, then the host can | ||
// allocate a single 10K scratch buffer, and make it available to all | ||
// three plugins. | ||
// | ||
// This optimization may allow for reduced memory usage and improved | ||
// CPU cache usage. | ||
|
||
static CLAP_CONSTEXPR const char CLAP_EXT_SCRATCH_MEMORY[] = "clap.scratch-memory/1"; | ||
|
||
#ifdef __cplusplus | ||
extern "C" { | ||
#endif | ||
|
||
typedef struct clap_host_scratch_memory { | ||
// Asks the host for certain amount of scratch memory. | ||
// If the host is unable to provide the memory, it should | ||
// return "false". | ||
// | ||
// The plugin may call this method multiple times (for | ||
// example, gradually decreasing the amount of scratch | ||
// being asked for until the host returns true), however, | ||
// the plugin should avoid calling this method un-neccesarily | ||
// since the host implementation may be relatively expensive. | ||
// If the plugin calls `reserve()` multiple times, then the | ||
// final call determines the actual amount of scratch memory | ||
// that will be available to the plugin. If the final call | ||
// returns false then no scratch memory will be provided, | ||
// regardless of any previous calls to `reserve()`. | ||
// | ||
// When the plugin is de-activated, the scratch memory | ||
// is invalidated, and the host may free the memory if | ||
// appropriate. The plugin will need to reserve scratch | ||
// memory again the next time it is activated. | ||
// | ||
// In the context of plugins and hosts that implement | ||
// the "thread-pool" extension, scratch memory is assumed | ||
// to be "thread-local". The plugin should request the maximum | ||
// amount of scratch memory that it will need on a single | ||
// thread. Accordingly, the host must ensure that each | ||
// thread can independently provide the requested amount | ||
// of scratch memory. | ||
// | ||
// [main-thread & being-activated] | ||
bool(CLAP_ABI *reserve)(const clap_host_t *host, uint32_t scratch_size_bytes); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think so. It'd need to explain what happens if the plugins performs more access to the buffer than initially requested. Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @p--b ETA? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @p--b will you make that PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hey, apologies for the delay. Yes, I can have something to you in the next 24 hours. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. #436 :) |
||
|
||
// Asks the host for the previously reserved scratch memory. | ||
// If the host returned "true" when scratch memory was requested, | ||
// then this method must return a pointer to a memory block at least | ||
// as large as the reserved size. If the host returned "false" | ||
// when scratch memory was requested, then this method must not | ||
// be called, and will return NULL. | ||
// | ||
// This method may only be called by the plugin from the audio thread, | ||
// (i.e. during the process() or thread_pool.exec() callback), and | ||
// the provided memory is only valid until the plugin returns from | ||
// that callback. The plugin must not hold any references to data | ||
// that lives in the scratch memory after returning from the callback, | ||
// as that data will likely be over-written by another plugin using | ||
// the same scratch memory. | ||
// | ||
// The provided memory is not initialized, and may have been used | ||
// by other plugin instances, so the plugin must correctly initialize | ||
// the memory when using it. | ||
// | ||
// The provided memory is owned by the host, so the plugin must not | ||
// free the memory. | ||
// | ||
// [audio-thread] | ||
void*(CLAP_ABI *access)(const clap_host_t *host); | ||
} clap_host_scratch_memory_t; | ||
|
||
#ifdef __cplusplus | ||
} | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be required to be the first element in the array passed to
set_location
, if it is provided?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it should, because if your host is just a device chain, it doesn't have a track or a project.