FL Studio 6 Mixer...

[Trancit]

A simple plugin could assist us greatly without causing any problems that you are mentioning.

you mean, you'd be happy with a delay plugin? I can do that in 5 min

And the possibilty to route the outputs from sendchannels to another track as only the master...

so you get 10 min

Another question:

How do I set up a VSTi in FLS so that it receives Midi on more than 1 channel???
Let me explain: I love to use the East West Symphonic Choirs triggert by their Wordbuilder Midi Plugin...
This midiplugin p.e. sends mididata on channel 1 to 5 to Kontakt, which I host as Vsti in FLS...but in FLS Kontakt receives only on channel 1...
In other hosts I can set the Midi input to p.e. "all channels"...is there a way in FLS to do this???


Trancit

[Hink]

Here's about PDC, freezing, and solo:

-Freezing.
All that's missing is that it won't disable generators and effects for you - you have to do this manually. I know some think that completely removing the plugin from the project (to 'save ram'..) is better - it's not really, but I don't feel like debating about it.
.

why not debate on this...its crucial man...
i dont have problems with manualy disabling effects(couse when u disable them they dont use CPU anymore) but i have a big problem with removing the generator(vsti) from my project to save CPU (couse they use CPU regardless of them being desabled)...this is a stupid way....the clever way is freezing...u freeze the generator(vsti) and u can return it with one click without deleting it and u save the wav with the same click and u can return it when u want it back

why would you have to remove your generators? After you render it all you have to do is mute that channel in the step sequencer...a generator without a signal won't use cpu...

[Trancit]

Here's about PDC, freezing, and solo:

-Freezing.
All that's missing is that it won't disable generators and effects for you - you have to do this manually. I know some think that completely removing the plugin from the project (to 'save ram'..) is better - it's not really, but I don't feel like debating about it.
.

why not debate on this...its crucial man...
i dont have problems with manualy disabling effects(couse when u disable them they dont use CPU anymore) but i have a big problem with removing the generator(vsti) from my project to save CPU (couse they use CPU regardless of them being desabled)...this is a stupid way....the clever way is freezing...u freeze the generator(vsti) and u can return it with one click without deleting it and u save the wav with the same click and u can return it when u want it back

why would you have to remove your generators? After you render it all you have to do is mute that channel in the step sequencer...a generator without a signal won't use cpu...

Perhaps not a "generator" but a VSTi...and not only CPU although sometimes a lot of Ram, p.e. Stylus RMX


Trancit

[Jaeson Merrill]

That said, FL already has freezing, since it's just about rendering mixer tracks. You can already get FL to render a mixer track and automatically insert it in the playlist. All that's missing is that it won't disable generators and effects for you - you have to do this manually. I know some think that completely removing the plugin from the project (to 'save ram'..) is better - it's not really, but I don't feel like debating about it.
But I just think that some consider that FL's track rendering isn't freezing because it takes too much time to render, and they do expect freezing to work another way.
I had suggested a way to freeze parts of the song and not just the whole song, maybe it'll be implemented, but: -it will STILL take time to render, obviously -it won't work perfectly, because some plugins are multiout, and can't be disabled because one of their mixer tracks was frozen.

Now that I have explained this, I'm sure that it'll still be the same 'IL is too stubborn to implement PDC' or 'they showed no interest in freezing'.

You have the same view on freezing you did a year ago, and its bordering on ignorance.

you dont have to just disable a generator.

it would be nice to turn off that little light next to a generator and be done with it.

but it goes further.

have you tried the process?

Lets say you come up with a patch in a vsti...
you want to maintain a low cpu so that it doesnt add up eventually, and you realize that this vsti's part isnt gonna change, and youre satifsied with it for now.

theres really no sense in having it eat ANY CPU, i dont care if its 5 or 55 percent cpu, so you decide to freeze it.

you render the mixer track and the effects, fine.

theres the audio track on the playlist.

then you have to disable the generator, but wait! If you have a generator that takes up RAM, which apparently to you is not a big deal, but since im not just creating 4/4 techno music with 5 year old vsti's, its a big deal to me, and many other composers who find FLstudio to be an ideal environment for quick and complex composing; its a big deal to me.

then you have to

save the patch

and close the generator.

then when you open the generator

you have to find import the fxp, or the .fst,

and load it.

sure, it sounds like a little thing, but its a bunch of clicks and looking around that can be easily remembered by a freeze function.

or, maybe even you could just come up with an easier way of remembering closed channels?

ad what about effects?

if freezing encompassed effects, you would have to go and disable each effect tied to that channel...

I dont know, theres alot of reasons why freezing could benefit in FL.

and its not BECAUSE OTHER SEQUENCERS have it, however, other sequencers, have shown how well it could work, well one, specifically, sure a different paradigm altogether, but SAmplitude, for 2 versions now.

Sorry if I seem like IM whining, but you really dont SEEM to listen, whether you do or not.

[Jaeson Merrill]

fact is, even the freezing i mention CAN be done easy with utilizing .fst files..the functonality is TOTALLY there right NOW.

[OzoneJunkie]

Hmm, sorry if this is just "wrong" - just brainstorming:

I wonder if an option to "only load VSTs in use" (i.e. not muted) when a project is opened would be good...

Not a full freeze workaround or anything, but gets to the heart of the RAM issue, no?

[Trancit]

Hmm, sorry if this is just "wrong" - just brainstorming:

I wonder if an option to "only load VSTs in use" (i.e. not muted) when a project is opened would be good...

Not a full freeze workaround or anything, but gets to the heart of the RAM issue, no?

So you have always render, mute vsti, close the project and open it again...not so interessting

better a real "macro" which renders the outputs of the vsti, put the rendered files into the playlist at the right position, route the rendered audiofiles to the mixertracks,unload the vsti, and save the settings in backround...


Trancit

[tony tony chopper]

I don't mean any disrespect, but it sounds like a design oversight to me.

oh because maybe you expected me to design FL back in '98 with PDC in mind, when no one knew what PDC was about

PDC CAN be done,

if you believe so, write down a detailed solution for PDC to work in every possible FL project situation

it IS useful, but are YOU willing to make it happen?

are you willing to read? Where did I write it's not useful?

[tony tony chopper]

If you have a generator that takes up RAM

the good old 'they eat RAM, it's evil!'..


Now if you read what I wrote, I want to allow freezing only parts of the song. Meaning that the generators would have to stay there anyway, to process other parts of the song.


They eat too much RAM? Professionals would just buy more RAM, it's cheap, and easy to upgrade (unlike the CPU).

[Mighty_Hero]

I would like to see only one thing added...relative grid.

Pro tools users will follow me.

[OzoneJunkie]

Hmm, sorry if this is just "wrong" - just brainstorming:

I wonder if an option to "only load VSTs in use" (i.e. not muted) when a project is opened would be good...

Not a full freeze workaround or anything, but gets to the heart of the RAM issue, no?

So you have always render, mute vsti, close the project and open it again...not so interessting

better a real "macro" which renders the outputs of the vsti, put the rendered files into the playlist at the right position, route the rendered audiofiles to the mixertracks,unload the vsti, and save the settings in backround...

Trancit

Yeah, you're right, you would have to close and re-open the project... but better than nothing?

[peejunk]

The way I see it it could be done like this:

Everything entering a channel strip gets aligned by delay to whatever is entering the same strip with highest latency. This way latencies buildup to the final master strip where sends are also compensated for.

This only leaves internal controlers, or perhaps only the peak controller since delaying others doesen't seem nessesary since they don't react to audio on their channels.

So if internal controllers are getting there late and everything sounds sloppy, user can switch PDC off in settings and deal with latency whatever way he did before.

An incomplete PDC implementation will satisfy 90% of users wanting PDC a lot more than no PDC. It would certainly give users more choice.

Inverse delay of generators is not a problem either since it only requires starting points (generators and audio tracks) to be delayed by the difference in ticks or whatever you're using. For practical uses I don't think it needs to be sample accurate.

Again this would create issues with internal controllers that maybe could even be dealt with in time and some refactoring, and having these two options would buy you a decent amount of time for to improve your PDC implementation if possible.

[tony tony chopper]

it's not as simple, you can get multiple generators with different latencies rendering in the same mixer track, or worse, a multiout plugin rendering to mixer tracks that have different latencies - and multiout plugins do that behind FL's back (I warned them not to do this but no one cared).
Then you have generators rendering voices where they want, possibly into 2 different mixer tracks (in the worst case), and they can do that before and after other generators. Then you have mixer routing automation (since you can automate the target track).
Then you say the sends are also compensated for, but FL6 has no real send anymore - routing and sending becomes the same thing, just with different levels.
You also have the fruity send that can send after a generators that has latency, and before an effect that has latency. Then you have effects that, like multiout generators, access send (the constant ones) tracks directly without asking FL first.
Then you have VSTi generators that can be inserted as effects, controlled by MIDI out channels.

Actually it's not the peak controller that'll be the problem, but more internal controller generators, and possibly automation, BUT it all depends what they control.


The way I'll do it is probably by delaying all tracks so that they all end up with the same latency BEFORE processing the effects and routing. I think it won't work in a lot of cases.

[Trancit]

But why do all the others get this thing working???

The flexibility in SX is nearly the same...


Trancit

[pummel]

GOL wrote:

it's not as simple

LOL, we should all feel honored he even stoops to try to explain this stuff. The reason FL is so great is that GOL has the gift to carefully think thru all the scenerios and exceptions; few have that talent. I find it amusing when he says something is difficult and the hordes argue. Apparently, the hordes have not attempted to write / maintain a huge software project. And no, an SE synth does not count.

Perhaps a compromise would be to offer PDC as an either/or proposition, excluding the problematic cases. It might be possible to get 80% of the value of PDC in some limited context.

Or not. I trust GOL knows what is worth spending his time implimenting, from a time / value standpoint.