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.

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

Surge++ FX Section #1368

Closed
baconpaul opened this issue Dec 1, 2019 · 2 comments
Closed

Surge++ FX Section #1368

baconpaul opened this issue Dec 1, 2019 · 2 comments
Labels
UI Issues related to UI look&feel

Comments

@baconpaul
Copy link
Collaborator

FX in Surge++ are complicated and difficult.

Step 1 is to move them over as is without parameterizing the layout so we can at least kill the legacy side. Once that's done we can figure out the right thing to do. But save that.

@baconpaul baconpaul added this to the Surge++ alpha 1 milestone Dec 1, 2019
@baconpaul
Copy link
Collaborator Author

baconpaul commented Dec 1, 2019

Step 2 is, as I knew, and as I discussed with @mkruselj on slack, to have a separate <layout> block for each FX type which is swappable based on an FX selector. Maybe default those in and just have overrides. And then have the UI engine swap out the sub-layouts appropriately.

So engineering to the XML spec, the parser, the whole nine yards.

Probably add a new type a <hidablelayout> which is a layout subclass when I do this. That would also be useful elsewhere - like the big FM matrix we will need one day.

@baconpaul baconpaul changed the title Surge++ FX Step One Surge++ FX Section Dec 1, 2019
@mkruselj mkruselj added UI Issues related to UI look&feel Layout engine labels Feb 5, 2020
@baconpaul
Copy link
Collaborator Author

Re-tooling the S++ plan so closing these issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UI Issues related to UI look&feel
Projects
None yet
Development

No branches or pull requests

2 participants