Add a build for Linux

[ycollet]

I looks like Scream can only be built on Mac and Windows.
Is it possible to add a Linux build support ?

[derEremit]

i just vibe-coded a prototype. it definitely is possible but the frontend might look a bit different.

[Tachy-Bunker]

oh ok

[derEremit]

Small update — it's gone from "prototype" to a published port over the weekend.
Repo: https://gitlab.com/z3nlabs/scream-dpf

Formats: CLAP, LV2, VST3, JACK standalone. Native Linux build using DPF + NanoVG; the C99 DSP code is vendored verbatim (see PROVENANCE.md for the file-by-file attribution and the tiny include-swap patch the upstream xhl/*.h headers needed). MIT attribution preserved; my port glue is ISC to match DPF.

Cross-tested against the Windows VST3 via yabridge at 48 kHz — bypass path nulls bit-exactly (−600 dB), the distortion residual is around −25 dB and tracks entirely to libm differences in tanh/exp/log inside Tanh_ADAA2_process between glibc and the msvcrt libm you compile against. Same C source, different numerical noise floor.

Releases have Linux binaries attached:

• v0.1.0: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.0
• v0.1.1: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.1

Renamed the plugin to "ScreamDPF" so it can coexist with the original in a DAW's plugin browser. Happy to rename, add disclaimers, or take it down if you'd prefer — just let me know.

[Tremus]

@ycollet This is already being worked on. The two main tasks are:

1. Port the CPLUG dependency to Linux, in particular the windowing library
2. Make an installer for Linux

Personally I don't know much about Linux conventions, APIs and the like, but there is a volunteer working on it here

@derEremit Very interesting! If you'd like to help, would you consider working with VISΛGE on the port? See the link above.

[dromer]

Small update — it's gone from "prototype" to a published port over the weekend. Repo: https://gitlab.com/z3nlabs/scream-dpf

This is kind of almost impressive!
It seems to work, except for adjusting the curve on downward slopes then it snaps to the top or bottom.

@Tremus DPF doesn't directly support visage. Or do you mean porting CPLUG to Linux?
I'd recommend against vibe-coding all of that ..

[derEremit]

just to clarify a few things.

I do not think i can help with some other porting issues as I am not that deep into this type of coding.

I just thought i read from the project description that a linux port is NOT WANTED or INTENDED by the original developers.

And as I just had a nice vibe coding setup and some spare time and tokens i wanted to see what can be done.

RANT
I am just a Linux enthusiast and for Music production switching to linux as the best possible solution there really only is the burden of plugins not being natively supported. For everything else linux is already the optimal audio production platform.
RANT OFF

Thanks for making the awesome plugin open source in the first place again!

[Tremus]

@dromer by "Visage" I was referring to a persons username (not Matt Tytels graphics library). They genorously volunteed to work on a CPLUG port to Linux

[dromer]

by "Visage" I was referring to a persons username (not Matt Tytels graphics library).

lol, why did I not realize this 🤣

[MetalMan1245]

Small update — it's gone from "prototype" to a published port over the weekend. Repo: https://gitlab.com/z3nlabs/scream-dpf

Formats: CLAP, LV2, VST3, JACK standalone. Native Linux build using DPF + NanoVG; the C99 DSP code is vendored verbatim (see PROVENANCE.md for the file-by-file attribution and the tiny include-swap patch the upstream xhl/*.h headers needed). MIT attribution preserved; my port glue is ISC to match DPF.

Cross-tested against the Windows VST3 via yabridge at 48 kHz — bypass path nulls bit-exactly (−600 dB), the distortion residual is around −25 dB and tracks entirely to libm differences in tanh/exp/log inside Tanh_ADAA2_process between glibc and the msvcrt libm you compile against. Same C source, different numerical noise floor.

Releases have Linux binaries attached:

• v0.1.0: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.0
• v0.1.1: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.1

Renamed the plugin to "ScreamDPF" so it can coexist with the original in a DAW's plugin browser. Happy to rename, add disclaimers, or take it down if you'd prefer — just let me know.

Thank you for saving me some time, I was doing exactly this when I found your version. Much appreciated. It would be nice if they could merge this in with the original or if it could be forked off so it is easier to find even if they don't want to merge the code for some reason.

[Tremus]

Small update — it's gone from "prototype" to a published port over the weekend. Repo: https://gitlab.com/z3nlabs/scream-dpf
Formats: CLAP, LV2, VST3, JACK standalone. Native Linux build using DPF + NanoVG; the C99 DSP code is vendored verbatim (see PROVENANCE.md for the file-by-file attribution and the tiny include-swap patch the upstream xhl/*.h headers needed). MIT attribution preserved; my port glue is ISC to match DPF.
Cross-tested against the Windows VST3 via yabridge at 48 kHz — bypass path nulls bit-exactly (−600 dB), the distortion residual is around −25 dB and tracks entirely to libm differences in tanh/exp/log inside Tanh_ADAA2_process between glibc and the msvcrt libm you compile against. Same C source, different numerical noise floor.
Releases have Linux binaries attached:

• v0.1.0: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.0
• v0.1.1: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.1

Renamed the plugin to "ScreamDPF" so it can coexist with the original in a DAW's plugin browser. Happy to rename, add disclaimers, or take it down if you'd prefer — just let me know.

Thank you for saving me some time, I was doing exactly this when I found your version. Much appreciated. It would be nice if they could merge this in with the original or if it could be forked off so it is easier to find even if they don't want to merge the code for some reason.

If we merged this port, we would be responsible for maintaining it. I do not want to be responsible for a vibe coded port to another framework on an OS I do not understand. This is very risky. I also beleive our framework is considerably better for our needs.
Building a CPLUG port is the most sensible move for us

[MetalMan1245]

Small update — it's gone from "prototype" to a published port over the weekend. Repo: https://gitlab.com/z3nlabs/scream-dpf
Formats: CLAP, LV2, VST3, JACK standalone. Native Linux build using DPF + NanoVG; the C99 DSP code is vendored verbatim (see PROVENANCE.md for the file-by-file attribution and the tiny include-swap patch the upstream xhl/*.h headers needed). MIT attribution preserved; my port glue is ISC to match DPF.
Cross-tested against the Windows VST3 via yabridge at 48 kHz — bypass path nulls bit-exactly (−600 dB), the distortion residual is around −25 dB and tracks entirely to libm differences in tanh/exp/log inside Tanh_ADAA2_process between glibc and the msvcrt libm you compile against. Same C source, different numerical noise floor.
Releases have Linux binaries attached:

• v0.1.0: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.0
• v0.1.1: https://gitlab.com/z3nlabs/scream-dpf/-/releases/v0.1.1

Renamed the plugin to "ScreamDPF" so it can coexist with the original in a DAW's plugin browser. Happy to rename, add disclaimers, or take it down if you'd prefer — just let me know.

Thank you for saving me some time, I was doing exactly this when I found your version. Much appreciated. It would be nice if they could merge this in with the original or if it could be forked off so it is easier to find even if they don't want to merge the code for some reason.

If we merged this port, we would be responsible for maintaining it. I do not want to be responsible for a vibe coded port to another framework on an OS I do not understand. This is very risky. I also beleive our framework is considerably better for our needs. Building a CPLUG port is the most sensible move for us

That makes a lot of sense. Very understandable. If you need a Linux tester let me know, this is a cool plugin and I'm glad that I can use it without running the Windows version at all, and hopefully an official Linux version can exist at some point.

[derEremit]

well, i support that opinion

ScreamDPF is an experimental but probably working port to another framework. I also wanted to make sure it is know this is vibe coded by an amateur :D
Its a fork / port, whatever but not something that should live within the project.

for now linux users have something to play with. while there is no pressure to build a proper implementation ( hopefully ).
And in my testing ScreamDPF already run more stable than the windows version with wine compatibility layer on linux.