Surge++: The plan (was “Experimental Branch”)

[baconpaul]

Edit Oct 6: This is underway! For now it is all in this repo on the surge++-master branch and most of the todo list is being managed as text file or on slack until it is ready to merge back in as described in #1239.

Here's an edited version of the message I put on Slack with some further comments.

I've just generally I’ve been thinking about surge and what to do with it, kinda like we discussed on slack in the end of August. I scanned all the open issues and they fall into three groups.

1. Things I’m really interested in (6 operators and lots of FM algos! Kurzweil-style language for routing and wavetables! Accesibility done right on the Mac!);
2. Things which I could do but aren’t that exciting (midi program control; make it so your an type in a value on a slider) and
3. Things which I actually don’t care about at all (The UI doesn’t show in Energy XT).

I then realized that those groupings have something in common.

The ones I’m sort of interested in I could do in the synth now. That makes sense - because the ones I was really interested in that I could do in the synth now, I’ve done. That's kind of what 1.6.2 is.

The ones I’m not interested in I’m still not interested in.

But the ones I’m really interested in are all blocked behind two fundamental questions.

1. can we expand the UI and
2. can we add parameters and maintain backwards compatilbility in all our host flavors with automation.

The answer to both questions right now is “no”. But I have ideas how to make the answers “yes”. So I've decided, post 1.6.2, to try and unlock those questions so we can level up the features possible in an imagined 1.7 release

But that unlocking is a lot of change. And if another dev comes along and wants to do one of those moderately-interesting-to-me-but-very-interesting-to-her ones I don’t want that to be blocked.

So my plan, post 1.6.2, which will center around this GitHub issue is

1. make a branch called “experimental” which is ahead of master and builds its own nightly (so there’s an official nightly from master and an experimental nightly from the branch)
2. Whack on the experimental branch until I’ve convinced myself that I can flex the UI and parameter order; or I can’t
3. If I can, merge, proceed. If I can’t, replan. That replan may involve leaving the synth as "pretty good" and "more or less like the 1.6.n releases" forever.

To set a concrete goal for "experimental working" I propose the following change for a merge back.

Add 2 more oscillators per scene, which don't participate in FM right away, but do have mixer entries. And make each oscillator independently pannable with a control in the mixer.

And it all has to work VST2/3/AU/LV2 on Win32/64 Mac and Lin.

This ticks all the boxes. It adds parameters (those pans; those oscillator controls), deals with streaming versions (those oscillators should be off-by-default totally in old patches) and adds them in an order which is not trivially "at the end" (so they need to retain display grouping but keep stable IDs). It requires more "space" in the UI (to expand the mixer and the oscillator selections) and also requires a new control (a pan knob in the mixer). It requires a moderate, but not insane, change in the DSP code also.

If I can modify the code so that change is feasible and works, then we can unlock all the other cool stuff in the issues.

And so that's kinda my plan for surge for the fall. So putting this here and adding a milestone and a label.

[mortfell]

Nice!

[baconpaul]

Oh @jpcima since you are active on the synth and I don't think are on slack, wanted to draw your attention to this issue so you knew some of my thinking on my next steps.

[mkruselj]

You mention panning the oscillators in the mixer - yay!

I would also love to see the filter pan option. Right now there's just a hard switch between F1>both>F2. Wouldn't it be awesome if this were a continuous pan, AND modulatable?

This gets Surge in Waldorf Q territory - one of rare synths that have this sort of feature.

[baconpaul]

That's wonderful idea; but can you stick it in a separate issue? This issue is really just "do the technical work to let me solve this class of problem; and the instance i pick is ___". I don't want this issue to become the list of good ideas. Just focus on the architectural problem with one test case.

Thanks!

(but yes, modulatable of course).

[baconpaul]

So I am sort of scrapping and revisiting this plan so let me close and unpin this.