KVR Audio

Urs · Post by **Urs** » Thu May 10, 2012 9:13 am

Hey there,

an ongoing discussion makes me think.

Since last week it has been clear in Europe that file formats belong to noone. Thus, we can add SysEx import to our plugins for anything we ever wanted to. E.g. if we added SysEx import for the Virus, there's nothing Access could do about, unless we violated their trademarks whatsoever. (I'll dig this info up if need be)

But how about sound designers? Does a sound designer have the right to say "My sounds must not be used with anything else than Synth XY", even though another synth can import that SysEx/fxp/whatever and even though the user legally owns those sounds?

I was of the opinion that if a user legally obtains a preset, he can do with it as he sees fit, unless he violates the actual copyright and terms.

I'm posting this here because it may be an implication for us devs whether it makes sense to add SysEx support whatsoever to our stuff or not.

What's your thoughts?

Urs

otristan · Post by **otristan** » Thu May 10, 2012 9:30 am

Reverse engineering for interoperability is legal in Europe

So I don't think a Sound Designer would be able to forbid this in Europe

AdmiralQuality · Post by **AdmiralQuality** » Thu May 10, 2012 9:35 am

Urs wrote:Hey there,

an ongoing discussion makes me think.

Since last week it has been clear in Europe that file formats belong to noone. Thus, we can add SysEx import to our plugins for anything we ever wanted to. E.g. if we added SysEx import for the Virus, there's nothing Access could do about, unless we violated their trademarks whatsoever. (I'll dig this info up if need be)

But how about sound designers? Does a sound designer have the right to say "My sounds must not be used with anything else than Synth XY", even though another synth can import that SysEx/fxp/whatever and even though the user legally owns those sounds?

I was of the opinion that if a user legally obtains a preset, he can do with it as he sees fit, unless he violates the actual copyright and terms.

I'm posting this here because it may be an implication for us devs whether it makes sense to add SysEx support whatsoever to our stuff or not.

What's your thoughts?

Urs

Does "file formats" include plug-in APIs?

And as for reading SysEx files, I'd think the issue would be more the potential copyright or (ugh!) patent violation that exactly cloning their product's feature set would entail. So unless you're making a flat-out emulation, which is already pretty shaky ground, the issue doesn't really apply.

Planning to clone a classic?

Richard_Synapse · Post by **Richard_Synapse** » Thu May 10, 2012 9:53 am

Interesting topic Urs...

I don't see much point in SysEx, though, except perhaps for old machines, e.g. old FM sounds. None of the bigger synths is really clonable, ihmo, unless you have a <1:1 import in mind that only works on say half the available patches, and even there only to some extent.

Does a sound designer have the right to say "My sounds must not be used with anything else than Synth XY", even though another synth can import that SysEx/fxp/whatever and even though the user legally owns those sounds?

Ihmo it makes no sense for sound designers to limit their work to one synth, when they can reach a lot more users. As a sound designer I'd be more than happy if anyone owning a popular plugin could use my patches.

Richard

Urs · Post by **Urs** » Thu May 10, 2012 11:24 am

Well, I hadn't had anything specific in mind.

We have thought about SysEx import on and off for years. A (semi-)modular synth could probably cover a lot of simpler synths featurewise, even though the sound wouldn't be exactly the same. Nevertheless, the resulting patch might still be very useful for the user.

Today it somehow occurred to me that this also holds true for softsynths and thus for their fxp files whatsoever. Has anyone ever considered to import Synth1 presets? - That would give any synth an instant expansion of possible patches by, uhm, 10000?

Which then leads to the inevitable question:

What about presets that ship with a demo version?

I see a huge potential of conflict coming up...

AdmiralQuality · Post by **AdmiralQuality** » Thu May 10, 2012 11:48 am

Urs wrote:Well, I hadn't had anything specific in mind.

We have thought about SysEx import on and off for years. A (semi-)modular synth could probably cover a lot of simpler synths featurewise, even though the sound wouldn't be exactly the same. Nevertheless, the resulting patch might still be very useful for the user.

Today it somehow occurred to me that this also holds true for softsynths and thus for their fxp files whatsoever. Has anyone ever considered to import Synth1 presets? - That would give any synth an instant expansion of possible patches by, uhm, 10000?

Which then leads to the inevitable question:

What about presets that ship with a demo version?

I see a huge potential of conflict coming up...

Oh I see what you mean.

Well, it would be a rather large task to reverse engineer all the various formats. For example, if you wanted to load a Poly-Ana patch with a cutoff parameter equal to 0.73165, what does that actually mean in Hz?

But yes, certainly do-able after you've calibrated all the parameters between the two synths. You'd also of course need some mode that defaulted all the extraneous parameters to something sane.

Importing Synth1 patches is actually a great idea. Why didn't I think of that? When you mentioned SysEx at first I was thinking, hmmmm, I need to find an MKS-80 to study its SysEx format. FXPs from other soft-synths didn't even occur to me.

I'm adding this to my new feature idea list right now...

AdmiralQuality · Post by **AdmiralQuality** » Thu May 10, 2012 11:53 am

You could also just make a stand-alone patch converter. You could even release it into the wild to avoid any potential legal hassle. "There's an MKS-80 to Poly-Ana patch converter? Sorry Roland, didn't come from me."

Urs · Post by **Urs** » Thu May 10, 2012 11:56 am

AdmiralQuality wrote:You could also just make a stand-alone patch converter. You could even release it into the wild to avoid any potential legal hassle. "There's an MKS-80 to Poly-Ana patch converter? Sorry Roland, didn't come from me."

Urs · Post by **Urs** » Thu May 10, 2012 11:57 am

The external converter could even be a VST-host, that... oh oh... can of worms...

AdmiralQuality · Post by **AdmiralQuality** » Thu May 10, 2012 12:09 pm

What makes this a really daunting task is that fxp files store the knob position. Not the real internal parameter value (which only rarely will map 1:1 to the knob value). So you'd have to map all the curves of the knobs/sliders as well. For BOTH synths.

Oh shit, this just reminded me that something I planned to do is going to be a lot harder than I was thinking it would. I wanted to allow text entry of any knob in the parameter display area. But I can't do that without providing a reverse curve function for every knob. (Right now I only have conversion one way. From knob position to internal parameter value.)

Oh well. On the bright side my TODO: list just got one item shorter.

Urs · Post by **Urs** » Thu May 10, 2012 12:18 pm

Well, you could do an "intelligent" converter that you could "teach" what to do.

Like, it opens two plugins, "source" and "target". First you copy the init patch from source on target, then you go through parameters. For each knob you set a value on source, then dial in the corresponding value on target. Do this 5-20 times per knob, until e.g. a cubic interpolation does the trick. For each probe the converter pulls the preset out of source and checks for the float that has changed. In a few hours you have a more or less working converter...

(okok, I'm being optimistic here)

AdmiralQuality · Post by **AdmiralQuality** » Thu May 10, 2012 12:26 pm

Or even more optimistic: Automate the dialing-in process as well and have the converter analyze the output of both instruments.

You know, the more I think about it, saving the knob positions as if they were actually "parameter" values is stupid. You can never change polarity of a knob without breaking preexisting patches. Same with curve. Unfortunately that's how all the various plug-in APIs want us to do it. But the knob position should be incidental. It's what the knob is representing that we should be storing. (In an MVC paradigm, we're saving View state instead of saving the Model state.)

Howard · Post by **Howard** » Thu May 10, 2012 1:04 pm

AdmiralQuality wrote:...saving the knob positions as if they were actually "parameter" values is stupid. You can never change polarity of a knob without breaking preexisting patches. Same with curve.

+1. Same for names of mod sources/destinations etc. etc..

Dentoid · Post by **Dentoid** » Thu May 10, 2012 1:21 pm

Urs wrote:Today it somehow occurred to me that this also holds true for softsynths and thus for their fxp files whatsoever. Has anyone ever considered to import Synth1 presets? - That would give any synth an instant expansion of possible patches by, uhm, 10000?

Which then leads to the inevitable question:

What about presets that ship with a demo version?

I see a huge potential of conflict coming up...

Very interesting thought!

First of all, I just want to note that I'm no lawyer so this is just speculation.

That said, I think there are two separate questions in this.
a) Can I as a developer of synth A legally make it read presets from synth B
b) Can I as a user of synth A legally use presets I got for synth B in synth A (provided it can read them)

What I mean is that even if it's legal for synth A to technically read presets from B, I'm guessing the EULA of synth A could say that the user can't use the presets received with the product in any other products. Possibly the EULA of the product can even say that presets written by the product are only allowed to be used in the product, effectively limiting third party preset libs as well.

AdmiralQuality · Post by **AdmiralQuality** » Thu May 10, 2012 1:25 pm

Dentoid wrote:Possibly the EULA of the product can even say that presets written by the product are only allowed to be used in the product, effectively limiting third party preset libs as well.

Kind of like how Google owns any content you create in Google Docs?

http://www.zdnet.com/blog/greenbaum/the ... google/130

Or not...

http://cybernetnews.com/google-docs-dat ... not-quite/

preset format ownership