KVR Audio

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:25 pm

I like the idea of musicians being able to share patches. The Reaktor User Library is a good example.
It promotes sharing of techniques as well as iterating on someone else's products to create even new techniques.

ghettosynth · Post by **ghettosynth** » Mon Jul 10, 2017 8:25 pm

mgw38 wrote:
ghettosynth wrote:While there are exceptions, it being worthwhile is incompatible with you asking questions like this.
Wow, that is a statement of utter passive aggressive beauty.

And now, was it more prescient, or ignorant?

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:31 pm

Fluky wrote:I like the idea of musicians being able to share patches. The Reaktor User Library is a good example.
It promotes sharing of techniques as well as iterating on someone else's products to create even new techniques.

The Reaktor User Library is actually fairly good place to be for this kind of thing, because there are many talented developers there and it's backed up by a big company.

There are few negatives though. User-led extension is somewhat more limited in scope and there's the initial cost of purchasing the software as well as upgrade costs. Also, it doesn't host VSTs, nor does it support general programming languages, so everything has to be implemented in "Reaktor language".

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:34 pm

From the developers' as well as musicians' perspective it'd be easiest if there were no "double standards". As a developer I find it stupid having to learn multiple languages or frameworks for doing the same exact thing and as a musician I find it stupid having to use and buy different programs to do about the same thing.

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:35 pm

ONE VISION. ONE SUPREME LEADER. ONE DIRECTION.

Russell Grand · Post by **Russell Grand** » Mon Jul 10, 2017 8:35 pm

I would warn you it sounds like a waste of time.

I think you've made that quite clear.

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:37 pm

At the very least it'd be useful if there was even some kind of formalism for translating between different standards.

For programming languages there already exists cross-compilation frameworks such as https://haxe.org, why does such not exist for musical DSP apps?

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:44 pm

I get the impression your level of experience is very limited and that you're making a lot of assumptions which lead you to believe such an implementation could potentially work when it couldn't.

Also if we were to all agree upon one single vision and adopt that amongst us all it wouldn't be an issue with software and plug-in formats, different synthesizers with all sorts of analog filter emulations and such ...

It would just be this:
https://www.youtube.com/watch?v=sq7q5d15-aY

BlueprintInc · Post by **BlueprintInc** » Mon Jul 10, 2017 8:54 pm

Fluky wrote:Well what I was speculating above in the picture before "this might fundamentally be breaking some rights" was if "hiding" commericial DSP in such patch would make the output complicated enough that commercial DSP is non-distinguishable. This is sort of "grey area", because technically one might be ripping commercial DSP, but if the patch is given in a way that it's not interpretable from the output, nor from the binary, then there's no way for anyone to display rights infringement. It sort of reminds of sampling from commercial records. If one processes the sample so that it's non-recognizable, then it's very difficult to display copyright infringement.

At first I liked your idea, but then you began with this. My thoughts: it is not easy to just hide a commercial plugin in your patch. Some copy protections rely on machine ids, on checksums, on uplinks to online servers, on dongles, ... . What you think is a greyzone, basically assumes cracking the plugin first. Good luck, there are teams trying this for some software for years without success

My 2nd thought is: you won't be able to create a "standard" that fits to everything & everyone. Besides this, making it abstract and generic, often creates unnecessary overhead for this wide range of usage.

To be honest, I don't see the profit for a DAW developer implementing this.

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:57 pm

What about a "cross-compiler" between few common frameworks (e.g. Reaktor, CSound, VST C++)?

I know one framework which is already doing Pure Data - VST - C++ - Javascript cross-compilation.
https://enzienaudio.com

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 9:16 pm

I'm not proposing that any of the ideas are worthwhile in terms of work.

Even I'm constantly trying to gauge whether it's more productive to speculate or work on these kinds of things, rather than working on new musical algos for existing platforms.

But I think open platforms are more likely to stay alive, even if they might not be that well supported.

It'd be horrible if NI decides to dump Reaktor at some point, for example.

camsr · Post by **camsr** » Tue Jul 11, 2017 4:53 am

The most important thing, is to make sure the new standard works with both Windows and Apple computers, and possibly linux as well.

Miles1981 · Post by **Miles1981** » Tue Jul 11, 2017 10:38 am

It's not even just C++ compiler, it's any language.
And then, what you be the benefit of them anyway? There is no chance any additional performance would come from recompiling the plugins. It works for Reaktor because they own the platform and they know the blocks they have. It won't work for an open platform (not even talking about mixing 32bits and 64bits plugins...).

soundmodel · Post by **soundmodel** » Tue Jul 11, 2017 10:39 am

Miles1981 wrote:It's not even just C++ compiler, it's any language.
And then, what you be the benefit of them anyway? There is no chance any additional performance would come from recompiling the plugins. It works for Reaktor because they own the platform and they know the blocks they have. It won't work for an open platform (not even talking about mixing 32bits and 64bits plugins...).

Not having to rewrite plug-ins for different frameworks?

That'd lower the overhead of deciding for one platform (e.g. Reaktor), because then one'd be able to do automatic porting to other platforms.

Miles1981 · Post by **Miles1981** » Tue Jul 11, 2017 10:41 am

What different frameworks? Even if you talk about JUCE vs WDL-OL, the difference is mainly the GUI support, the actual DSP code is identical. And you support all major plugin APIs.

The one you didn't talk about is the open community LADSPA... It's not implemented in any big DAW.

I have a new idea for a plug-in standard/extension, what should I do with it?