Not quite. I've been programmer a long time, and usually you make a call and get the size of the buffer needed to store the data, then you allocate memory for that and make the call and put the data in the buffer. Not seldom in Windows it's the same call, but you have NULL parameter for the pointer, then what you get is the size of data. In other calls you have a size of a buffer you have as a parameter, if it's not enough you get needed size as a reply instead.

So that is not an issue. Host only need to know which data belongs to which plugin, and send it back when project opens.

You cannot replace something that is not there obviously. But you can make the switch real easy to pop up a dialog with the plugins you have, and you choose from what you have. One EQ can replace another, a compressor replace another etc. More useful though I would find volume envelopes at least.

Sure there will be stuff missing, but compared to just audio and midi you can do a lot more.

Import formats for sampler cannot emulate everything either, and it will not sound exactly the same due to different filters, features not supported etc.

If there was a big demand for this I guess it would exist by now - so my hopes are not so high it will happend.

I was curious to see how people felt about it.

Actually something like this did happen with Rebirth back then. Two TB-303s, an 808 and a few FX plus basic automation- seems trivial enough to transfer in comparison to a DAW import today. So a few imports existed, iirc in FLStudio. It worked, yes, but too many details got lost, making it inferior to an audio or MIDI transfer, or even starting from scratch.

Richard

I think we're maybe at least partly losing the script here.

I wasn't personally talking about moving a full song from Live to FlStudio intact, from places where people would often use a lot of the included instruments or plugs, or anything like that. I was talking about maybe having a rough mix of a project in say, Cubase, and having it translated 90% to say, Sonar or PT, with all the channel fader levels, pan settings, 3rd party audio insert plugs, busses, basic level, pan and mute automation for tracks, clip gain if applicable, fades, maybe all the recorded "takes" positioned on one track if applicable, etc, etc... especially in cases where there are no software instruments involved at all, and maybe even no midi at all?

Currently AA Translator does some of that but the developer has to hack into multiple different formats. Translation done purposefully (by the various product owners, with a standard format for where it applies) could easily do so much more, if there was a generic import / export standard for those things. There will never be perfect translation and no, these things will never universally apply to, or be useful for, everything, every situation.

Electronic music people need to come to grips with the idea that many people actually do make music without any software instruments. If this general translation concept doesn't apply so much to a project in BitWig Studio or something using mostly proprietary plugs and instruments and features, it just doesn't apply so much. But (in the concept) loading an audio project from PT into Cubase should be able to bring - most - of the more commonly shared mix settings with it, minus the things that actually technically can't be translated, described, and recreated.

So maybe we should try to avoid framing everything from that singular angle, the electronic music angle. That's actually not the only thing. If it doesn't apply to thing that so much, or as much, it doesn't apply so much.

never mind

Would be possible, sort of a MIDI song, but for audio. EQ settings would translate too, if the standard is well-defined.

Richard

i wasnt aware you were talking about anything, i was taking to the OP

in order to do that i guess every plugin, the factory ones included, should be a vst standard. I've always moved songs on different DAWS, and the result is so similar that nobody hear any difference at all. Sometimes they change in volume. But I use only vsts and midi tracks. Never used audio tracks. The same song played on a different DAW remains the same.

Yeah, sorry about quoting you there. I only meant that in general this kinda thing is maybe less useful overall for DAW's like Orion, which are more specialized electronic music production apps.

I would guess that's why some of them (no clue about Orion though) may not support OMF, AAF, OpenTL, some of the most common exchange formats... because the point in those apps is mostly to just stay there and maybe most of the users don't actually have any need for those things. Obviously, you can print audio stems from anything though if just you need to move raw audio tracks.

FLStudio doesn't really have any issue there since the entire app will load as an instrument. Just load it up as a VI and route the tracks out into your DAW to mix. So producing in FL and mixing the result in Cubase is rather easy.

OTOH, a lot of people who produce music in (for example) Logic, may actually mix in Pro Tools... so the more of a basic production mix that could possibly directly translate, basic panning and levels and basic audio edits that aren't frozen in a stem, etc, etc, the better. It's not even (in that case anyway) about sharing a project with anyone else or worrying about if they have the same 3rd party plugs.

It's (granted) likely a pipe dream. Thanks.

Is that the rewire support that you use?

That is a clever approach I didn't think of. So if producing in Reaper if letting it get mixed by someone having ProTools is easy - or the other way.

If you double up with hosts that can be run as rewire slaves - it's piece of cake to do jobs for anybody.

I tried doing this to use Reaper project in Sonar, and it works fine for audio. But midi tracks - which I wanted - to use staff view in Sonar did not work.

Is there support in rewire specification for midi tracks in the same way as audio tracks?

That might be why nobody bothered with import formats - rewire in another host and you are done.

They already did - AES31, a simple text format that was quite effective but it got little support once Avid/Dodgy refused to accept it. They reckoned that they had a much better 'universal' format - OMF1. This of course wasn't that good because some devs actually were able to work it out so they made it harder and called it OMF2 and once a few poorly implemented OMF formats were introduced they moved to something even less useful and even more complex and called it AAF.

Anyone notice a trend here?

Ah... good to know. Thanks. Yep, I do see the trend.

At least we have AA Translator to fall back on. Great product.

Not rewire. FLStudio (the entire application) loads as a VSTI, so if you produce a song in it, you can just load the entire song in any host that supports VSTI. It will still be running inside FLStudio, but still, there's no "translation" to do, just maybe some track routing to your DAW mixer.

It will sound exactly the same.

So if you prefer mixing in Cubase, Sonar, S1, or whatever, just load your FLStudio song up in an instrument instance there and route the tracks out individually or in groups as you prefer.

So, for example, if I use a Waves Comp (or an Imageline comp) on a track in FL, it will still be on that track when I load the FL song into Cubase running FL.

Of course, the caveat there is that the user has to actually own FlStudio, to run it in any case, as an instrument instance or otherwise.
Last edited by LawrenceF on Tue Aug 14, 2012 7:28 am; edited 2 times in total

Thanks mate much appreciated - you should be pleased to know that our next release should hopefully export to PTF format - working on it right now and it's doing my head in.

BTW if you think writing conversion software for daws is hard trust me that picture you have in your head is not even anywhere near close

Oh, I know it's very hard the way you're being forced to do it. I know, trust me, I know.

It would be easier if every DAW mfg only had to deal with one single song format for import/export, their own proprietary format + a standard that everyone could export to and import from with varying degrees of translation. You (OTOH) have to deal with multiple wacky standards and multiple proprietary song formats, some of which (I assume) may occasionally change.

A bit of a monumental achievement imo.