Allocating memory in a for loop... good idea?

[ModuLR]

[quote=“jules”]Ok Mod, I’ve had another look at your stuff.

Here’s a few comments on your c++ homework:

• Why are there plugin-specific hacks in your JuceVstMain file???[/quote]

Bithead explained to me why this isn’t a good idea via IM. JuceVstMain should be a thin layer that connects the two. I kinda understand that now. I wrote another version which pulled all of that stuff out. Bad Mod! BAD!

- And why on earth is your filter also an editor??? :shock: Believe me, that ain’t good practice!

Bithead got me for this one too! kindred spirits or something… you guys are scaring me more than my code scares you. :lol:

- The updateFilter variable is a Very Bad Idea. If you need a callback to trigger an asynchronous update, derive your plugin from the AsyncUpdater class and use that instead.

Okee doke, I’ll take a look at that class… thanks!

[quote]What do you mean by keeping parameters in the 0-1 range?[/quote] it really has nothing to do with juce. It’s just that in the example, the gain was being fed a number like 2… which should be scaled between 0…1 so it will be reflected in automation properly.

I’ve got the window resizing to work now in cubase, but am a bit worried about having to move the parent window sizes around - we’ll need to test this in all the other hosts too, might need to do some host-specific hacks.

I did it that way, because I believe that is how vstgui handles it.

Ok, new version up there soonish…

w00t! BTW, I commited yet another act of evil and made a template version which is strictly VST. :twisted:

[jules]

Ok, I think you’ve learned your lessons there.

We’ll have to look at the parameter 0-1 thing later on. Some VSTs actually do use bigger values - I remember having trouble with this when getting them to work in tracktion. We’ll have to see how AudioUnits + DX handle the ranges and find a good generic method to use.