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

VST3: Split Processor vs Controller? #164

Closed
whydoubt opened this issue Dec 27, 2018 · 2 comments
Closed

VST3: Split Processor vs Controller? #164

whydoubt opened this issue Dec 27, 2018 · 2 comments
Labels
Design Required We need to design a solution to this issue VST3 VST3 plugin related issues
Milestone
1.6.n

Comments

@whydoubt
Copy link
Contributor

SurgeVst3EditController is unused. Either the processor and controller should be split properly into separate components, or this vestigial controller should go away. Knowing the history of the VST3 code could be of value here. FWIW, Steinberg discourages using the single-component pattern for VST3 plugins.

From messing with the code a bit, the main issue I run into with trying to split the components is that methods from both components access surgeInstance, and I don't know how to handle that.
@whydoubt whydoubt changed the title VST3: Split Effect vs Controller? VST3: Split Processor vs Controller? Dec 27, 2018
@baconpaul baconpaul added the Design Required We need to design a solution to this issue label Jan 3, 2019
@baconpaul
Copy link
Collaborator

I'm struggling with VST3 zoom #305 #357 and I think it's because of this split also. The API to indicate resize to a host is not clearly reachable from our single class to me. Not sure I am correct, but just linking the issues.

baconpaul added a commit to baconpaul/surge that referenced this issue Jan 28, 2019
@baconpaul
Implement VST3 zoom
dec0772 
VST3 zoom is very similar to VST2 zoom since both rely on
VSTGUI (and the associated bugs therein), but differ on the approach
to notify the host. The primary difference in notifying the host
is requiring a reference to the Steinberg::IPlugFrame frame class,
which has to be publically exposed to allow the processor to see it.
(This may be indicative of issues still with us choosing to not have
a formal processor/editor split, as mentioned in surge-synthesizer#164). Regardless,
once the IPlugFrame is exposed, we can use the resizeView() API
in vst3 to inform hosts in our zoom callback, as implemented here.
@baconpaul baconpaul mentioned this issue Jan 28, 2019
Merged
baconpaul added a commit to baconpaul/surge that referenced this issue Jan 28, 2019
@baconpaul
Implement VST3 zoom
3d241b8 
VST3 zoom is very similar to VST2 zoom since both rely on
VSTGUI (and the associated bugs therein), but differ on the approach
to notify the host. The primary difference in notifying the host
is requiring a reference to the Steinberg::IPlugFrame frame class,
which has to be publically exposed to allow the processor to see it.
(This may be indicative of issues still with us choosing to not have
a formal processor/editor split, as mentioned in surge-synthesizer#164). Regardless,
once the IPlugFrame is exposed, we can use the resizeView() API
in vst3 to inform hosts in our zoom callback, as implemented here.
baconpaul added a commit that referenced this issue Jan 29, 2019
@baconpaul
Implement VST3 zoom (#406)
8a7b5a7 
VST3 zoom is very similar to VST2 zoom since both rely on
VSTGUI (and the associated bugs therein), but differ on the approach
to notify the host. The primary difference in notifying the host
is requiring a reference to the Steinberg::IPlugFrame frame class,
which has to be publically exposed to allow the processor to see it.
(This may be indicative of issues still with us choosing to not have
a formal processor/editor split, as mentioned in #164). Regardless,
once the IPlugFrame is exposed, we can use the resizeView() API
in vst3 to inform hosts in our zoom callback, as implemented here.
Closes #357
@esaruoho esaruoho added VST3 VST3 plugin related issues and removed VST3 VST3 plugin related issues labels Jan 29, 2019
@baconpaul baconpaul mentioned this issue Feb 22, 2019
Closed
@baconpaul baconpaul added this to the 1.6.n milestone Feb 24, 2019
baconpaul added a commit to baconpaul/surge that referenced this issue Jul 10, 2019
@baconpaul
Implement VST3 zoom (surge-synthesizer#406)
229dab3 
VST3 zoom is very similar to VST2 zoom since both rely on
VSTGUI (and the associated bugs therein), but differ on the approach
to notify the host. The primary difference in notifying the host
is requiring a reference to the Steinberg::IPlugFrame frame class,
which has to be publically exposed to allow the processor to see it.
(This may be indicative of issues still with us choosing to not have
a formal processor/editor split, as mentioned in surge-synthesizer#164). Regardless,
once the IPlugFrame is exposed, we can use the resizeView() API
in vst3 to inform hosts in our zoom callback, as implemented here.
Closes surge-synthesizer#357 

Former-commit-id: 1c7fac21cbd6c1835b8f9fbefa8908dc154fd26e [formerly 8a7b5a7]
Former-commit-id: 261ab8f8067137d2823d48074a3284cc8b8aa347
Former-commit-id: 368499d70341cbd99947f4fbd76c66bbc0d862bb
@baconpaul
Copy link
Collaborator

So I'm going to close this issue because I just opened #1208 which will subsume this. We need to do this for sure, but it's a big change which #1208 covers for all the host flavors.

@bobobo199733 bobobo199733 mentioned this issue Mar 5, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Design Required We need to design a solution to this issue VST3 VST3 plugin related issues
Projects
None yet
Milestone
1.6.n
Development

No branches or pull requests
3 participants
@whydoubt @esaruoho @baconpaul