Why aren't there import formats from all other major hosts?

[lfm]

Hi

When it comes to samplers, all major sampler have import format support from almost all other major samplers. Both Kontakt, GigaStudio, Vsampler, Halion etc import each others sample formats. And there are a number of 3rd party products that do these conversions as well - which is great.

Why isn't that the case with daws, that can import projects from any other daw?

This is a fact that troubles me.

Some export to OMF, and have OMF import though. But that is really poor interchange format and does not translate very well since you loose so much.

What do you think about this?

I would really like ProTools, Logic, Reaper, Sonar, StudioOne, Samplitude import any of the others project formats.

Thanks.

[BertKoor]

Because importing projects from other hosts is not a SMOP. Vital features and concepts might prove hard to translate to another host. The common concept is equal (tracks with instruments, controlled by midi) but group bussing etc, there it all goes wrong. Cubase alone has like a hundred minor versions, each might have picky little details in the project files to take care of.

In the world of samples the features are much more in common, so there it's easier to translate.

[LawrenceF]

I don't think it would be all that difficult (relatively speaking) to create a universal XML format or something that captured most of the stuff we need for much better translation between various hosts. Something that would easily exceed OMF, AAF and similar.

Getting every product to support it would be another story. There is a good bit of "self interest" involved in all that, where (I suppose) some companies actually don't want it to be so easy to do that, to move a song from their product to another fully or mostly intact. Part of what keeps some users even occasionally using products is the sheer number of old projects in that format.

XML can (afaik) describe the status of anything. It would only take one well designed universal XML import/export format to do that... and the willingness of products to support it. It's surprising to me that an AES committee hasn't done something like that already, worked on a standard for that.

[BertKoor]

Yes, vendor lock-in comes to mind, the opposite of open standards...

[LawrenceF]

Yeah. That's pretty much it. They have no real incentive to make it easier for you to move things you worked on over to competitor products (intact) and maybe like it better there and stay there. They want it to be a relative hassle to do that... and it usually is.

In the sampler world it's pretty much the exact opposite. Very few people would spend hundreds of dollars for a sampler that couldn't load sample formats they already paid for and use, so in that case they have a clear financial incentive to support as many formats as possible.

[Xenakios]

There is a good bit of "self interest" involved in all that

I would say this is the main reason instead of any technical difficulties. (Which obviously exist but might not really be that severe compared to the obstacle of the companies simply not wanting things to be portable between applications.)

[Richard_Synapse]

Yeah. That's pretty much it. They have no real incentive to make it easier for you to move things you worked on over to competitor products (intact) and maybe like it better there and stay there. They want it to be a relative hassle to do that... and it usually is.

I think it would be great if it were possible.

Trouble is, most hosts like Orion, FLStudio, Protools, Logic etc have a raft of native instruments and effects built in, how do we translate their settings? Many users take advantage of this stuff, so just dumping or bouncing this data would ruin most projects.

Richard

[LawrenceF]

Trouble is, most hosts like Orion, FLStudio, Protools, Logic etc have a raft of native instruments and effects built in, how do we translate their settings? Many users take advantage of this stuff, so just dumping or bouncing this data would ruin most projects.

Richard

Sure. You obviously can't translate a proprietary instrument or a proprietary audio plugin to a host that can't load it in any case.

I assume the OP was talking about stuff that actually can be recreated between various hosts, but it has to be recreated manually now because the limited formats we have now don't capture most of it.

I think it would be more logical to look at what "more" can be done, not what can't be done. Some things... like loading REVerence reverb from Cubase into PT, obviously can't be done. The point is to get "much better" translation, not perfect translation in all cases, which is ... impossible.

[lfm]

Because importing projects from other hosts is not a SMOP. Vital features and concepts might prove hard to translate to another host. The common concept is equal (tracks with instruments, controlled by midi) but group bussing etc, there it all goes wrong. Cubase alone has like a hundred minor versions, each might have picky little details in the project files to take care of.

In the world of samples the features are much more in common, so there it's easier to translate.

Thanks for input.

But still, making some sample libraries from scratch, there are numerous structures and complex stuff in library format as well. All kinds of conditions between samples, layering, envelopes on volume and filter and many other things. Not all is expected to translate 100%, but still there are maybe 20 import formats in the major samplers.

One would think something better than OMF would be possible for daws.

If one vendor would start to really improve this - maybe others would follow. It could be that kind of incentive that is needed.

One is trying to compete being better at import - and other have to follow.

[lfm]

Trouble is, most hosts like Orion, FLStudio, Protools, Logic etc have a raft of native instruments and effects built in, how do we translate their settings? Many users take advantage of this stuff, so just dumping or bouncing this data would ruin most projects.

Richard

Sure. You obviously can't translate a proprietary instrument or a proprietary audio plugin to a host that can't load it in any case.

I assume the OP was talking about stuff that actually can be recreated between various hosts, but it has to be recreated manually now because the limited formats we have now don't capture most of it.

I think it would be more logical to look at what "more" can be done, not what can't be done. Some things... like loading REVerence reverb from Cubase into PT, obviously can't be done. The point is to get "much better" translation, not perfect translation in all cases, which is ... impossible.

Thanks for input.

Usually every host have some startup mode where you confirm every plugin, in case one plugin causes crashes etc. The same procedure could be used to leave space for a plugin not identified - or make a dialog and ask what should be put there.

As I understand OMF basically support the tracks for audio and midi. No envelopes, no plugins. At least looking at Sonar that is about it.

I don't know how universal it is, but there is AATranslator that at least support some format to Reaper.

Maybe having just about the same features on major daws - that one of them is trying to compete with better import from the others to be the better choice. They have all kinds of crossgrade offers and crossgrade to one with better import would really be a strong incentive.

[Kriminal]

Short of making sure both users have the same plugins and exporting/importing MIDI i cant see how anything else would be practical. Too many variables.

[lfm]

There is a good bit of "self interest" involved in all that

I would say this is the main reason instead of any technical difficulties. (Which obviously exist but might not really be that severe compared to the obstacle of the companies simply not wanting things to be portable between applications.)

Thanks for input.

Export formats is one thing they might not put so much effort into, but importing the competitors project would be a great feature I think. It would lower threshold switching daw to the one with better import.

[lfm]

Yeah. That's pretty much it. They have no real incentive to make it easier for you to move things you worked on over to competitor products (intact) and maybe like it better there and stay there. They want it to be a relative hassle to do that... and it usually is.

I think it would be great if it were possible.

Trouble is, most hosts like Orion, FLStudio, Protools, Logic etc have a raft of native instruments and effects built in, how do we translate their settings? Many users take advantage of this stuff, so just dumping or bouncing this data would ruin most projects.

Richard

Thanks for input.

I don't know for sure, have not programmed daw software - but I think each plugins settings format to be stored with host is just a binary clog, with length and a pointer to data, or something like that. So finding the same plugins on the host where you import should really be possible I think - once identified how it's stored.

But if host start to encrypt data, that is an obstacle of course. Me doing stockmarket analysis software - there are software that encrypt stored stockmarket data not to allow other analysis software to use it.

[Kriminal]

I don't know for sure, have not programmed daw software - but I think each plugins settings format to be stored with host is just a binary clog, with length and a pointer to data, or something like that. So finding the same plugins on the host where you import should really be possible I think - once identified how it's stored.

thats assuming every Host has a collection of plugins that have exactly the same amount of parameters and sound the same....which they dont. Using audio files and MIDI is the only way you can share projects betwqeen Hosts and still have an accurate file. While its a nice idea, i wouldnt hold your breath for it to ever be implimented or actually work.

[Richard_Synapse]

I don't know for sure, have not programmed daw software - but I think each plugins settings format to be stored with host is just a binary clog, with length and a pointer to data, or something like that. So finding the same plugins on the host where you import should really be possible I think - once identified how it's stored.

Native instruments+effects are not plugins. For instance, our 909 emulation does not currently exist outside of Orion, so there's no way to recall it in any other host. Moreover, its step sequencer is linked to the piano roll, which is impossible to do in a VST or AU plugin (the only format which might allow this would be RE).

Richard