Vember Audio Surge is now open-source

[EvilDragon]

Yeah so custom VST2 extension that doesn't work in other DAWs. Not a thing that would work in any DAW - as schwa also explains in that thread

So no, this won't happen for Surge.

[Dandruff]

Sure that no other DAW has it implemented too? Even Claes had considered it in the past

[baconpaul]

Yeah in surge the VST3 doesn't implement getParamValueByString. Mostly because we didn't have string -> value until 1.7 and the VST3 is older than that. Also we really want to avoid hand rolled vst3 investment and move to JUCE as soon as practical.

Evil is exactly right - we are focused on a juce port - but lemme see if this is easy to add. Right now we just return false always. It might be quick now we have the right api.

[Dandruff]

Cool, thanks!

[baconpaul]

Yeah it was easy enough (https://github.com/surge-synthesizer/su ... 3807/files there's the diff)

Would have been impossible before 1.7. There's a massive diff required behind that that which makes typein values work in the UI. Luckily we wrote that last summer! Now just refactoring to re-use that code through the VST3 api here.

should be in a nightly in an hour or two. And should work in any VST3 host that supports that VST3 API point. But I only tested bitwig mac.

[baconpaul]

Oh and that reaper vst2 extension isn't what we did. Evil is spot on that that's not right for surge. Since we aren't a VST2

[The Nerdy Music Guy]

Some chill ambient soundtrack kind of thing. Just one instance of Surge again, nothing else:

https://soundcloud.com/user-589036812-2 ... -1-x-surge

[bboxdw]

Yeah it was easy enough (https://github.com/surge-synthesizer/su ... 3807/files there's the diff)

Would have been impossible before 1.7. There's a massive diff required behind that that which makes typein values work in the UI. Luckily we wrote that last summer! Now just refactoring to re-use that code through the VST3 api here.

should be in a nightly in an hour or two. And should work in any VST3 host that supports that VST3 API point. But I only tested bitwig mac.

Getting a better foundation in place w/ JUCE rather than getting distracted by putting out too many fires before then makes total sense to me. I mention the remaining related issue knowing it might be easier to address later, and again suggest a workaround to help address questions in the meantime.

The Bitwig knob and Surge slider values differ in value when turning the Bitwig parameter knob. They seem to systematically differ by one point of resolution (from the perspective of the Bitwig knob). This is with no Bitwig or Surge LFO modulating the parameter.

In other words, if turning the Bitwig knob for A Filter 2 Cutoff jumps from values of 680.54 to 706.57 Hz, setting that parameter at 680.54 in Bitwig will set it at 706.57 in Surge. When increasing the value with the Bitwig knob, the Surge value is one step higher, and when decreasing the value with the Bitwig knob, the Surge value is one step lower. I've observed this with the filter cutoff, filter envelope, and LFO rate parameters (latter when not synced to tempo--works perfectly when synced to tempo).

In addition to the latest nightly, I went back and checked it with the 1.8.1 release version. Same thing there, so not an issue intro'd w/ the latest changes.

Recommended user workaround: When you make the adjustment within the Surge GUI, the Surge slider and Bitwig values match up exactly. So do it there in the meantime if you need a particular value to be exact, or if you're working with a parameter where one point of resolution is a significant difference.

[Held]

Is it possible to change the font size of the patch browser? It's so big that I have to scroll about two pages to get to the bottom. The scroll speed with the mouse wheel is also really slow.

I would also prefer to have the user patches at the top since I use those most often. Is there currently a way to change this?

(I'm on Manjaro Linux with REAPER v6.18 if that matters)

Thanks for all the great work you're doing with Surge!

[baconpaul]

Is it possible to change the font size of the patch browser? It's so big that I have to scroll about two pages to get to the bottom. The scroll speed with the mouse wheel is also really slow.

I would also prefer to have the user patches at the top since I use those most often. Is there currently a way to change this?

(I'm on Manjaro Linux with REAPER v6.18 if that matters)

Thanks for all the great work you're doing with Surge!

There are three primary things motivating our port to juce. The first is just raw software quality vs our current platform. The second is missing a particular widget which isn’t important right now in vstgui. The third is I couldn’t bear the idea of writing a proper patch browser in vstgui when juce was just - you know - sitting there.

So short version is: Yes we know that menu stinks. Our plan is proper tagged patch browser. My guess is one of the earlier things we do once we are into the SurgeXT cycle.

[baconpaul]

Yeah it was easy enough (https://github.com/surge-synthesizer/su ... 3807/files there's the diff)

Would have been impossible before 1.7. There's a massive diff required behind that that which makes typein values work in the UI. Luckily we wrote that last summer! Now just refactoring to re-use that code through the VST3 api here.

should be in a nightly in an hour or two. And should work in any VST3 host that supports that VST3 API point. But I only tested bitwig mac.

Getting a better foundation in place w/ JUCE rather than getting distracted by putting out too many fires before then makes total sense to me. I mention the remaining related issue knowing it might be easier to address later, and again suggest a workaround to help address questions in the meantime.

The Bitwig knob and Surge slider values differ in value when turning the Bitwig parameter knob. They seem to systematically differ by one point of resolution (from the perspective of the Bitwig knob). This is with no Bitwig or Surge LFO modulating the parameter.

In other words, if turning the Bitwig knob for A Filter 2 Cutoff jumps from values of 680.54 to 706.57 Hz, setting that parameter at 680.54 in Bitwig will set it at 706.57 in Surge. When increasing the value with the Bitwig knob, the Surge value is one step higher, and when decreasing the value with the Bitwig knob, the Surge value is one step lower. I've observed this with the filter cutoff, filter envelope, and LFO rate parameters (latter when not synced to tempo--works perfectly when synced to tempo).

In addition to the latest nightly, I went back and checked it with the 1.8.1 release version. Same thing there, so not an issue intro'd w/ the latest changes.

Recommended user workaround: When you make the adjustment within the Surge GUI, the Surge slider and Bitwig values match up exactly. So do it there in the meantime if you need a particular value to be exact, or if you're working with a parameter where one point of resolution is a significant difference.

So just so I understand

Surge Slider drag -> bitwig knob. AOK
Bitwig knob -> surge slider - off by one ‘resolution minimum’

Independent of typein?

Thanks!

[bboxdw]

So just so I understand

Surge Slider drag -> bitwig knob. AOK
Bitwig knob -> surge slider - off by one ‘resolution minimum’

Independent of typein?

Thanks!

Thanks for seeking clarification. I'm pretty sure we're on the same page. If you need more info, or further explanation, let me know.

[bboxdw]

So just so I understand

Surge Slider drag -> bitwig knob. AOK
Bitwig knob -> surge slider - off by one ‘resolution minimum’

Independent of typein?

Thanks!

Thanks for seeking clarification. I'm pretty sure we're on the same page. If you need more info, or further explanation, let me know.

I'll give one more example, just to make sure we're on the same page with the term "resolution minimum."

Using hypothetical rounded integers to simplify:

Say that mouse dragging a Surge filter cutoff knob in Bitwig jumps to values of 20, 40, 60, 80, 100, and so on, at increments of 20, without use of the shift key to achieve a finer adjustment resolution--just a really small movement of the mouse.

If you start at 60 and drag the knob down to 40 in Bitwig, the value will be at 20 in Surge. If you start at 60 and drag it up to 80 in Bitwig, the value will be at 100 in Surge.

At least that seems to be the pattern, with the few parameters I tried.

[baconpaul]

Cool thanks - added an issue to our milestone https://github.com/surge-synthesizer/surge/issues/3818

BTW, the folks in this thread have been super useful in finding and identifying bugs. Thank you! Happy for any of you to make github accounts too if your want though - github issues are our ‘memory’ of things we don’t forget. And feel free to open one! If its a dup or what not we can always close it.

[Mutant]

Thanks to the original dev Kurasu and to the team.