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

man, this spot is dead… WHY? what happened? speak ppl!! :roll:

anyway, I’m using midimessage to handle processEvents stuff in the plugin filter template… and I noticed that midiEvents is an ownedarray of MidiMessage (which rocks btw). My question is… is it a good idea to dynamically allocate this stuff in something which will be called several times? or is it better just to allocate a fixed size (that you know it won’t exceed) in the constructor and not have it constantly resizing the ownedarray?

tips… advice… anyone?


I guess everybody is too busy coding 8)

How did you get a filter to do a VSTi, the one on the JUCE site is only a VST effect without any process events method…???

Sorry guys, I’ve been over here in the USA this week and too busy to post my new code, but have got a spare hour now, so here’s a new version:

This has got all the missing code to pass midi messages, but I’m too jetlagged and confused to remember whether it needs my latest juce version to build, so it might not work until I get that posted up there for you (which will be thursday or friday)

And dynamic memory allocation is something I do all over the place in the audio callbacks, and it all seems to work, so I guess it’s ok. If you’re adding a lot of new messages you might want to preallocate some space in the array first, but don’t think it really makes too much difference.

cool, that’s good to know regarding the allocation…

it’s crazy to see how completely different we handled the midi stuff. Actually I didn’t handle anything… I just ported that part of the delphi template over, then made a few adaptations.

in any case, I’ll post the link really soon…

thus far, it handles resizing accross hosts (for windows at least), built out the programs and parameter stuff so it’s indexed like the delphi template, can use get/set chunk to save/recall state, added the cando’s, and the midi stuff seem to be working now. w00t!

btw, I’ve slipped into the juce-zone… I like it more than delphi now! BASTARD! :wink:

Im still here. Ive been making my own little army of UI components for myself (and others soon), vertical sliders, knobs, buttons all skinnable.

I also have a few lookandfeels() I need to cleanup then hopefully I can release too

I visit the forum a few times everyday but have had little to say, everything is working fine… and Im working a lot.

look forward to trying the new audioplugin bit

well, here is the link to what I’ve done with the JucePlugin thing… it covers the stuff I mentioned above… bascially just tried adding basic functionality to it as a template (porting snippits of the delphi template)… it’s got a hack here and there which will be sorted out. :roll: :wink:

Link -

I’ve just been busy putting the finishing touches to my new and improved[1] project studio. That and a couple of big work projects that keep creeping into my own time. :roll:

Still, I’m getting on top of it all, so I’ll be able to start doing some work on the editor soon. :slight_smile:

[1] improved as in it shouldn’t ring like bastard, but I doubt I’m going to be able to do much about standing nodes. :frowning:

Mackie meeting?

[size=75]T2 news? ;)[/size]

Tell Mackie to fly you to LA and I’ll buy you a beer! :lol:

fly to Tampa, Florida and Ill buy you dinner anywhere you want and toss in a nice new pair of shoes.

Hell, I’ll even throw in a box of orange tictacs! top that… gatorback! :lol:

orange tictacs and reallllly expensive bottled water.

I just posted a new version…

cleaned up a few parts… got rid of the MAX_MIDI_EVENT stuff from the delphi port. Now it’s all dynamic like it should be. Overall it’s just a tad cleaner. Put the files in the proper folders, and also made sure I deleted my pointers in vstMainBlahBlah… :shock: :lol:

edit: it’sbeen updated again. This is cleaner. Simplified updating GUI when param is changed. No longer defaults to 0 when starting it up.

[EDITED to 006]
Link -

sorry, I just fixed something else that was bugging me… so new link is above. w00t!

Just took a look at this stuff, Mod, but I’m confused… because you’ve reformatted eveything and filled it all with tabs, I can’t diff your code against mine to see what you’ve done. Is there stuff in there that I should be using?

shit, I knew I shouldn’t have done that… I’ll fix all that and reup another one later on tonight! :shock:

why are fixed width fonts sssooo ugly? hence the reason my stuff is so all out of wack… I forgot I wasn’t using a fixed width font, so I tabbed everything.

:shock: :x :roll: :wink:

okee doke, here is revision #6

  • removed the lovely tab formating I had all over the place… oopsie!
  • parameter values are now within the 0-1 range…
  • forgot to set updateFilter to false after updating gui - fixed
  • swapped accum boolean value sent to processBlock
  • added the CanProcessReplacing, and CanMono calls

Jules… re this accum stuff… I think your original code has the process/processReplacing functions backwards when feeding processBlock.

process means accumulating is true
processreplacing means accumulating is false

okee doke, that’s about it… sorry I pulled the editor code into it’s own Jules (I would assume this is gonna effect a diff too). Having eveything in a single lump makes me a bit batty…

anyway, this is pretty complete me thinks other than testing a mac compile. I think all the bases are covered. :smiley:

Link -

Cool. I’ve got to go catch a plane now, but will go through this stuff later this week…

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???

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

  • 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.

Anyway, I’m getting another build ready, but a few points -

What do you mean by keeping parameters in the 0-1 range?

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.

Ok, new version up there soonish…