Cannot open source file


#1

Cannot open source file: ‘e:\essentials\vstsdk2.3\source\common\audioeffectx.cpp’

I get this when I try to compile the juce_vst project, probably because the above file doesn’t exist. So how do I change where it looks for it?


#2

this is where Jules put the VST SDK files on his system, just remove the file from the project and put it again but now point the VC++ to the same file but now tell it where it is on your machine (assuming you downloaded the VST SDK). Do the same for all the VST SDK files in the project


#3

Thanx, that fixed it, but now I have another problem… It works fine in Tracktion but in eXT it adjusts the left and right channels at different rates :?


#4

cheers - this helped me too. in VC++express you can just click the file in the solutions panel and then go to the properties panel (at the right hand side) and just edit the ‘relative path’ field.


#5

i can confirm the energyXT channel bug with this. they scale at different amounts. i’ve not looked at the code yet of course, but this is definitely something


#6

i’ve fixed it!

not sure if this has been covered before, but i’ve found the problem with this. it’s in the function void DemoJuceFilter::processBlock(…);

i don’t really know anything about the VST spec yet, but i imagine that - because T and eXT both exhibit different behaviours, and this function has two possible processes, eXT uses the ‘not accumulating’ style for processing (whatever that means!)

anyway, the problem lies in that section of the conditional statement:

AS IT STANDS:

for (int channel = 0; channel < input.getNumChannels(); ++channel) { output.copyFrom (channel, 0, input, channel, 0, input.getNumSamples()); output.applyGain (0, output.getNumSamples(), gain); }

this steps thru the channels, copys the input buffer and then applies the gain.

HOWEVER, checking thru the JUCE docs, the ‘applyGain’ function as used in this call applies the gain to ALL channels. there is an alternative version that takes an additional parameter first (channel number). the way this is coded is (as above) is working as if it should apply the gain to each channel in the loop.

however, because it uses the ‘all channels’ version of apply gain, we get the problem. if you think about this, it will copy the first channel’s buffer, and then apply the gain to both channels. then, it will copy the second channel’s buffer, and again apply the gain to both channels! this means that the first channel has been 'gain’ed twice, and thus they are out of scale with each other.

the simple solution? take the applyGain(…) call out of the loop; the gain will be applied to both channels in one pass!

for (int channel = 0; channel < input.getNumChannels(); ++channel) { output.copyFrom (channel, 0, input, channel, 0, input.getNumSamples()); } output.applyGain (0, output.getNumSamples(), gain);

compiled and ran fine! :smiley:


#7

ah yes, silly me! Thanks for that.

I made a few improvements to the plugin code, and started on AudioUnits, but then got a bit sidetracked. I’ll post a new version of it soon.


#8

Jules, did you have time to look at the changes I did to the VST wrapper code?

thanks


#9

[quote=“ost12666”]Jules, did you have time to look at the changes I did to the VST wrapper code?

thanks[/quote]

I did have a quick look, but because you reformatted everything I couldn’t diff it - and I don’t have time to go through it line-by-line looking for changes. It looked like all you did was move the inline class into a header + cpp file?

I’d rather keep it all inline, to be honest, as I want to keep all the VST-specific code hidden away and focus on the cross-platform bits. Was there anything in particular you added that I might not have noticed?


#10

I did much more than just reformatted, the most important thing is that now it works with all hosts and not only with tracktion. I avoided publishing it since I thought it would be better if you look at it and merge the code. here are the details from my email about it:

  • Didn’t touch anything in audiofilterbase so converting to the new
    wrapper is easy

  • Now you can write multiple plugs using one VST wrapper library since
    I removed the CreateJuceFilter thing and hide all the DllMain stuff
    like I learned from you application class

  • Added a JuceVSTEditor class for consistency and better managed code.
    Also made it possible to use the editor wrapper without the VST
    wrapper in my native VST plugs (but didn’t test it yet this way)

  • Fixed many bugs

  • Formatted the code

  • Improved the way the VST API is used according to tests with many
    hosts. Most important issues where EffEditorClose/Open and the
    SizeWindow since some host don’t do SizeWindow

  • I tested it (with your demo and my plug) on: VSTHost, MiniHost,
    Tracktion, energyXT, Cubase SE 1.06, FLStudio 5, Live 4, Orion, Sonar
    4 and Project 5 (via DXi to VST wrapper). It works well now in all
    hosts

What I didn’t do:

  • Didn’t add new stuff to AudioFilterBase but I know I will need to in
    the future (unless you add them first)
  • Didn’t test on MAC although I put the code where I think it should
    be, except for new code that need to be done for MAC in the sizeWindow
    thing
  • I didn’t test programs, parameters and the chunck function but kept
    it all in the code

#11

Sure - but I’d also fixed a load of bugs (including the window size stuff) since the code that you branched off from, so it was hard to see what you’d done. When I release the next version, you can have a quick look and see if there’s anything important that I missed.


#12

OK, I will try, I don’t care so much about my code (since I learned a lot from it), I will just test it with all the hosts and see if it works…

The only design issue that I care about is the way the GUI is created, so I will look for it in the code and see if it is improved


#13

I’ve made it much stricter about the GUI in the next version. I noticed in the code that I’d given the filter a pointer to the current editor component, which is very very sloppy programming, so in future that’ll have to go, and the filters will all need to use proper listener/broadcaster patterns for updating the UI when their properties change. I’ve also updated the demo to show how it should be done in a thread-safe way. Will post the code soon.


#14