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.

Sign up for GitHub

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

Jump to bottom

Use LV2 state to store preset index in presetBank, to unload the .ttl #810

Open
p0nce opened this issue Nov 2, 2023 · 1 comment
Open

Use LV2 state to store preset index in presetBank, to unload the .ttl #810

p0nce opened this issue Nov 2, 2023 · 1 comment
Labels
Blocked Resolution depends on another issue. Enhancement This issue is about a new feature rather than a bug. Low interest Importance of this issue seems questionable for the bottom-line..

Comments

@p0nce
Copy link
Collaborator

p0nce commented Nov 2, 2023 •
edited

See also #808

Blocked by futureBinState not being default.

even without futureBinState, saving a state allows to use a whole Dplug chunk, hence not relying on host for resetting state... => I don't think future changes would be state-V1 incompatible? So I don't see a point in saving the whole plugin state in binary. Maybe more compact than .ttl port descriptions though? => this probably can be done later, as presets can change without breaking compat. If we do that, we'll use another URI instead of pluginState (say, pluginChunk = pluginState + parameters). Besides, it's not clear now how much LV2 hosts like our state interface.
@p0nce p0nce mentioned this issue Nov 2, 2023
Closed
5 tasks
@p0nce p0nce changed the title even without futureBinState, saving a state allows to use a whole Dplug chunk, hence not relying on host for resetting state... => I don't think future changes would be state-V1 incompatible? So I don't see a point in saving the whole plugin state in binary. Maybe more compact than .ttl port descriptions though? => this probably can be done later, as presets can change without breaking compat. If we do that, we'll use another URI instead of pluginState (say, pluginChunk = pluginState + parameters). Besides, it's not clear now how much LV2 hosts like our state interface. Use LV2 state to store whole plugin chunk, to unload the .ttl Nov 2, 2023
@p0nce p0nce added Enhancement This issue is about a new feature rather than a bug. Blocked Resolution depends on another issue. labels Nov 2, 2023
@p0nce
Copy link
Collaborator Author

p0nce commented Nov 2, 2023

To unload the .ttl, another option is to just store an internal preset number in another URI.

@p0nce p0nce changed the title Use LV2 state to store whole plugin chunk, to unload the .ttl Use LV2 state to store preset index in presetBank, to unload the .ttl Nov 2, 2023
@p0nce p0nce added the Low interest Importance of this issue seems questionable for the bottom-line.. label Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Blocked Resolution depends on another issue. Enhancement This issue is about a new feature rather than a bug. Low interest Importance of this issue seems questionable for the bottom-line..
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@p0nce