You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It could be very interesting to see how this crate could be ported to the new API, in particular in regards to how it could ease some of the parameter communication which is made more complicated by the change.
Thanks a lot for this!
I'm very busy currently, so I don't have time to do this atm, but I'm also interested in this, to make the thread-safety as ergonomic as possible.
Do you think a branch of easyvst should be based on thread_safe_plugin before that branch is merged into master of the vst crate to inform/refine the design, or is that design already settled?
One of the open questions was which possible multi-threading scenarios can happen in VST hosts, IIRC @wrl said "there are no rules" so we have to ensure that the splitting of the methods (which only allows certain multi-threading scenarios) will work in all popular hosts.
Which hosts have been confirmed to work with the thread_safe_plugin changes?
In https://github.com/askeksa/rust-vst/commits/thread_safe_plugin I have made a proposal for making the rust-vst crate safe.
It could be very interesting to see how this crate could be ported to the new API, in particular in regards to how it could ease some of the parameter communication which is made more complicated by the change.
Pull request is here: RustAudio/vst-rs#65
The text was updated successfully, but these errors were encountered: