CLAP 1.2.3 #432
CLAP 1.2.3 #432
Conversation
abique
force-pushed
the
next
branch
2 times, most recently
from
773e346 to
069d784
Compare
* 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
per conversation on discord, oct 29
comment refered to a previous version of the ambisonic extension.
abique
requested review from
baconpaul,
robbert-vdh,
Bremmers and
defiantnerd
basically expand some comments around ranges, meaning, and so on.
| // 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.
I think so.
It'd need to explain what happens if the plugins performs more access to the buffer than initially requested.
It'd need to state that even if concurrent_buffers == 1, you may still get a thread local pointer, so if you want the same pointer on all threads, you need to fetch it before calling into the thread pool.
Thanks!
There was a problem hiding this comment.
@p--b will you make that PR?
There was a problem hiding this comment.
Hey, apologies for the delay. Yes, I can have something to you in the next 24 hours.
|
LGTM also. |
| // The first device within a track group has the index of | ||
| // the last track or track group within this group + 1. |
There was a problem hiding this comment.
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 clap_plugin_location_element_t *path array in set_location?
There was a problem hiding this comment.
Actually, it could be simplified.
We could say that index starts at 0 for tracks and then 0 again for devices.
This is the model:
track_group
`- track0 -|
`- track1 -| -> (+) -> device0 -> device1 -> ...
`- ... -|
| // 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.
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.
A device chain is a serial list of devices.
A device can contain multiple device chains, which maybe use for parallel processing.
There are similarities between tracks and device chain. Though there's a different semantic, which the plugin can use for display. Think Fabfilter Pro Q3, with sidechain.
| // 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.
If I understand correctly, this array is a flattened tree structure?
There was a problem hiding this comment.
Yes it is an array, which describes the path toward the current plugin instance.
| // Represents a document/project/session. | ||
| CLAP_PLUGIN_LOCATION_PROJECT = 1, |
There was a problem hiding this comment.
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.
I don't think it should, because if your host is just a device chain, it doesn't have a track or a project.
| // Index within the parent element. | ||
| // Set to 0 if irrelevant. | ||
| uint32_t index; |
There was a problem hiding this comment.
So index does not refer to the array index of this element's parent element within the array passed to set_location?
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 set_location's path array is the same order that elements would be visited in a pre-order depth-first traversal of the tree. Then each index would be the array index of the element's direct parent. And since the root element does not have a parent, its index could be the index of the plugin device itself.
There was a problem hiding this comment.
The index here, refers to the position within the track/device_chain/...
|
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? |
Co-authored-by: Dalton Messmer <[email protected]>
Co-authored-by: Dalton Messmer <[email protected]>
Co-authored-by: Dalton Messmer <[email protected]>
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: Here from the root track group, take the third track, then the 6th device and here we are. Does that clarify the question? |
No description provided.