New plugin demo project

The project generation is pretty stable already - it might change a bit, but probably just by adding extra build parameters rather than any big changes.

do you mean ‘directory’? If so, I’m not seeing that (?)

sorry, yes

When i try to compile the fresh generated project (without any change) it does not find the JucePluginCharacteristics.h

c:\projects\juce\extras\audio plugins\wrapper\juce_includecharacteristics.h(37) : fatal error C1083: Cannot open include file: ‘JucePluginCharacteristics.h’: No such file or directory

As Add. Include Directories are defined C:\projects\vstsdk2.4;…..\JuceLibraryCode\AppConfig.h
So i thought it must be …..\JuceLibraryCode
its only a minor issue :wink:

Is it planned that everytime you resave the project, the VS settings will be overwritten, this could be a problem when you use the jucer as gui development tool, when you only want to change some settings.

Yes. Doing a merge between changes made in the jucer and changes made externally would be an incredibly tough problem. Certainly not one that I want to tackle.

The idea is that if there are settings that people are commonly needing to change, we can add them to the jucer to keep it all in one place.

hi

i downloaded the latest juce (v1.51) and buildt the plugindemo. worked like a charm so far. but there is an issue with the xmlstate, if i change the gui-size, close and reopen the gui, its size is reset to the default values. in the pluginprocessor.cpp it looks like it messed up the setxmlstate method with the getxmlstate…

please check that out

cheers

No… the xml stuff looks fine to me. What host are you using?

i tried with vst_scanner (v1.042)

Never heard of that… Maybe try something else before assuming it’s a problem with the plugin code?

vst scanner is basicly a simple host to check vst plugins. i’ll test with cubase asap…

but the setxmlstate method looked to me as jucer implementet the getxmlstate stuff and vice versa… may i’m wrong?

The set/get thing is a bit confusing, but I think it’s correct.

here the code i mean from the PluginProcessor.cpp:

[code]void JuceDemoPluginAudioProcessor::getStateInformation (MemoryBlock& destData)
{
// You should use this method to store your parameters in the memory block.
// Here’s an example of how you can use XML to make it easy and more robust:

// Create an outer XML element..
XmlElement xml ("MYPLUGINSETTINGS");

// add some attributes to it..
xml.setAttribute ("uiWidth", lastUIWidth);
xml.setAttribute ("uiHeight", lastUIHeight);
xml.setAttribute ("gain", gain);
xml.setAttribute ("delay", delay);

// then use this helper function to stuff it into the binary blob and return it..
copyXmlToBinary (xml, destData);

}

void JuceDemoPluginAudioProcessor::setStateInformation (const void* data, int sizeInBytes)
{
// You should use this method to restore your parameters from this memory block,
// whose contents will have been created by the getStateInformation() call.

// This getXmlFromBinary() helper function retrieves our XML from the binary blob..
ScopedPointer<XmlElement> xmlState (getXmlFromBinary (data, sizeInBytes));

if (xmlState != 0)
{
    // make sure that it's actually our type of XML object..
    if (xmlState->hasTagName ("MYPLUGINSETTINGS"))
    {
        // ok, now pull out our parameters..
        lastUIWidth  = xmlState->getIntAttribute ("uiWidth", lastUIWidth);
        lastUIHeight = xmlState->getIntAttribute ("uiHeight", lastUIHeight);

        gain  = (float) xmlState->getDoubleAttribute ("gain", gain);
        delay = (float) xmlState->getDoubleAttribute ("delay", delay);
    }
}

}
[/code]

may i dont see it the right way, but in the getxmlstate method you create a xmlelement object and use xml.setattribute method… i’d say xml.setattribute should be in the setxmlstate method instead of the getxmlstate method… not?

sorry, didn’t saw your answer before… but if the plugin works well in your place, the code may be correct!

i’ll try asap with other hosts…

cheers

No, you’re misreading it - the wrapper code calls that method to ‘get’ the plugin’s state, so the plugin creates some temporary xml and uses that to create its response.

ok, i just buildt the plugin host from the juce 1.51 directory. exactly the same!
-i load the plugin
-i open the gui
-i resize the gui
-i close the gui
-i open the gui
-the gui size is default, not resized anymore…

if this is the case only in my place could i have some xml trouble with my system?

i just downloaded an old version of juce (1.46) and created its audio plugins demo. and it worked, the gui still was resized after reopening it! the set/getxmlstate code looks the same in v1.46 as in 1.51. so the problem must be somewhere else!

does it work on your system using the juce plugin host?

i tested it with juce 1.50 and it worked as well. so it’s just v1.51 which seems to make trouble.

hi jules

i tested it now on a different system (win7 x64, cubase5.1.1 x32). it behaves the same… no store of the resize. am i alone with this issue? i compile with vs2008 under win7_32.

btw. sorry for doubting your code, but it really confused me yesterday :wink:

cheers

It’s a an obvious blooper when you look through the code - although the UI uses those lastUIWidth values, it never actually sets them. I rewrote the demo recently, and obviously just forgot to add something like this:

[code]
void JuceDemoPluginAudioProcessorEditor::resized()
{
getProcessor()->lastUIWidth = getWidth();
getProcessor()->lastUIHeight = getHeight();

...[/code]

Not a big deal at all.

of course… as simple as this :smiley:

thanks for checking

cheers pascal

[quote=“jules”]I’ve just updated the plugin demo, using the new Jucer to generate the project files for it, and have beefed-up its features a bit by adding a synth and delay effect.

As the projects are all new and auto-generated, I’d be interested to hear if anyone has any problems with it…[/quote]
Using Juce 1.51, there seems to be no Linux build target.

This is what I had to do to build it as a Linux native VST:

[list]
[] In The Jucer: Add a Linux Makefile Export target
Extra linker flags: "-shared"
Extra compiler flags: “-I/usr/include/vstsdk2.4 -I…/…/JuceLibraryCode”
(I had to add the vst path to compiler flags since VST Folder setting was ignored by Jucer)[/
]
[*] After saving in the Jucer, edit the generated Makefile by hand and:
Add an additional OBJECT:

Add a build target for that object, almost at the bottom of the Makefile:

$(OBJDIR)/juce_VST_Wrapper.o: ../../../../../../juce/extras/audio\ plugins/wrapper/VST/juce_VST_Wrapper.cpp -@mkdir -p $(OBJDIR) @echo $(notdir $<) @$(CXX) $(CXXFLAGS) -o "$@" -c "$<" [/*][/list]
After make, I had to add extension “.so” to the resulting binary (shared library)

I hope that was all, it took me a while to sort out.
The plugin now works (tested in Renoise).

Would it be possible for you (Jules) to use the above to add Linux support “out of the box” in the Jucer?

– Johan

I added this to the Jucer and submitted a patch in krakens related post

– Johan