Obxd synthesizer

[audiojunkie]

You want to be compensated for work, sure that is understandable.
But the way this was done is also quite sleazy in my opinion. And bringing up VCV Rack only adds to the points of things **NOT** to do.
It is still not possible to fork and build an alternative version of Rack without significant effort, because of a catch-22 with artwork. Artwork has CC ND rules in there, so cant be modified, but it includes copyrighted logos so you cant use it in forks. Pretty much the entire core module collection needs to be replaced if one ever just wants to e.g. publish a build for an unsupported target or platform.

The fact that we had what was described as a GPL licensed project and that is now being stated that is not redistributable is ridiculous.

The assets are encoded in the code, so they show up on screen, it needs to be part of the build.
So say if one were to clone the project for gitlab or something custom, by the updated readme terms their are infringing on copyrights because they did not ask for permisison for distributing the assets that are part of the codebase..

It sounds like this part needs to be straightened out and clarified. In my opinion, the proprietary bits need to be kept separate from the GPL source code to make things more clear.

Exactly!

Just to be clear. I have absolutely nothing to do with DiscoDSP. I’m not sure if that first part was directed at George or if you thought I had something to do with DiscoDSP. I’m just a linux user who sees the benefits of open source and I want people to understand that it is perfectly ok to monetize open source—if done correctly.

[OBSOLETE160530]

[DELETED]

[audiojunkie]

These parts need to be separated and clarified on GitHub.

Already done.

FalkTX apparently does not feel that the separation is sufficient enough, but I’ll let him speak for himself.

[OBSOLETE160530]

[DELETED]

[audiojunkie]

Wow wow, calm down a little bit

I’m calm, but frankly quite shocked at the ingratitude and the false sense of entitlement coming from so many people. Clearly, this aspect of open source (which is great, by the way) is not well understood amongst some of the KVR crowd.

I haven't meant you. Forgot to quote.

No worries, I’m not offended

[audiojunkie]

It looks like FalkTX plans to fork it under his umbrella of projects, so that the fork can remain completely free with no commercial pieces. I think that is actually for the best. Those who want continued commercial development and support can use George’s binaries. Those who want a version completely free of all commercial aspects can use the forked version.

This needs a correction. Any fork of GPL projects can be commercial, which is what is attempted here but in some hush hush meh whatever way.
Nothing stops something based on the DISTRHO fork or other bits to become commercial later on.
I have donations and a patreon set up, that already makes it a commercial project.

Cool! I’m learning as I go. Thanks for the clarification.

[audiojunkie]

Although sometimes complicated, this is where the benefit lies over commercial software. Take a look at Cardinal and VCV Rack. Or look at Vital. There are a lot of similar models for how all of this can be done.

For example, Vital was released as open source. Whatever code was written, and whatever stipulations were made when the GPL was created apply. In the case of Vital, the preset store had to be removed and the name changed (amongst other things). This has been done a couple of times, under names like Vitality and Vitalium. Those forked projects are available on the internet for anyone to use as long as they obey the GPL.

However, as far as I can tell, little has been done with those forked versions, and that is a risk with open source. The commercial version has been continuously developed while the forked code has sat. Vital is probably a better product than the forked versions. In addition to that, the Vital developer has priced the commercial version so well, that there is little reason to use Vitality or Vitalium when you can get the fully supported version so cheaply.

This needs some correction too.

Vital as released commercially is not available as opensource.
The source that was released corresponds to a now outdated 1.0.6 version (or something in between).

The "official" commercial version is always going to be more up to date because it is the author's version and I am not sure if there is interest on updating the public code ever again.

There are issues building old/public Vital with new JUCE, required for new OS support but there has been no comments on the ticket for it yet https://github.com/mtytel/vital/issues/31.
The alternative would be for Matt to publish his custom JUCE, perhaps there have been fixes there, but that also didnt happen as per https://github.com/mtytel/vital/issues/16

So Vital/ium is in limbo in regards to its opensource nature. There was ever only 1 opensource release, and only the author can really update that.

It is not that there isn't interest on keeping Vitalium and other forks alive, it just isn't possible to have things in sync with latest Vital changes because latest Vital is not opensource (yet?).

I do keep things building for DISTRHO-Ports as much as possible, recently with a full build system rewrite (old premake to meson) and even adjusting the build to allow 3 different JUCE versions just because of Vital(ium) because we require a static JUCE6 version in order to use the plugin.
While other plugins will eventually move to JUCE7, unless there is a new source code release of Vital, the Vitalium fork has no choice but to stay behind.

Thanks again for the clarifications I welcome your clarifications and corrections.

[audiojunkie]

These parts need to be separated and clarified on GitHub.

Already done.

FalkTX apparently does not feel that the separation is sufficient enough, but I’ll let him speak for himself.

Assets are still in the code https://github.com/reales/OB-Xd/blob/ma ... naryData.h

Good to know—apparently George has more to do get the commercial and open source parts separated. BTW, I have to take your word for it, since I am not a trained programmer. I don’t have the first idea as to what is what in the actual code.

[Vortifex]

..

[george]

Assets are still in the code https://github.com/reales/OB-Xd/blob/ma ... naryData.h

Those are simple dialog error bitmaps. I won’t complain about those.

[george]

So not useful for non-programmers then, which is fine. I don't really care if something is open source or not. If it's good then I'll use it, free or otherwise if the price is right.

The idea is keeping OB-Xd free for non-profit usage and fully functional in trial which seems fair enough to me.

[OBSOLETE160530]

[DELETED]

[audiojunkie]

What this means, is that if you have the programming know-how, the GPL part of the source code, which is available to the public, can be run through a compiler program to create a working DLL library (plugin) that you can put into your plugin folder.

So not useful for non-programmers then, which is fine. I don't really care if something is open source or not. If it's good then I'll use it, free or otherwise if the price is right.

Yes, at least to some extent. Simple projects aren’t too difficult, but OB-XD would be too complicated for me. FalkTX wouldn’t even blink an eye—he’s an expert at all of this, and an excellent open source advocate.

[OBSOLETE160530]

[DELETED]

[george]

@falkXT right, Binarydata.cpp and Binarydata.h had some old images embedded from discoDSP Grey Theme but those files are not necessary for compilation as they never got recalled in latest sources.

It was some unused legacy stuff from 2Dat GUI code that was replaced by our XML based theme system which looks for resources on external locations to make binaries less heavy and share the same resources between any plugin type or app. It also makes theme creation much easier because the designer does not relies on compiling.

I have updated GitHub without those now. Thanks for pointing up.

By the way, if you want to save some time I can give you permission to include the discoDSP Gray or Blue theme on your distributions it's fine to me as long as you state it on some part something like "OB-Xd theme used in accordance with discoDSP" or similar.