Possible JAP buggsie..[Solved]


#1

I was done with the gui for the plug I’m working on and decided to test it with a few other hosts (other than toby’s minihost) and I encountered a few problems.
So, I unzipped the JAP file for a fresh copy and compiled the demo, but it exhibited the same behaviours. Behaviours that I shall now describe.

**
In Toby’s minihost, everything is fine.

In Tracktion (1.x) GUI does not display, but I could not coax out any errors messages.

In VSTHost (Opensource thingy) Plug in loads and appears to work, but it doesn’t try to show the gui before asked…at which point I get an application crash and an error message about unexpected termination from the Visual C++ Runtime.

In Christian Budde’s VST Analyser, which also does not load the gui untill asked, I sometimes get a crash when closing the gui window. Same error as above.

In SVH (FXpansion mini host thing) its the same deal as with VSTHost. Plug loads and works, but the app crashes when asked to display the gui. Same error as above.
**

So, it is related to the gui thread. It is present in the demo and my plug where I do not as yet have any interactions between the classes. No getting or setting or locking.

Things I’ve done that may play a part:

Removed 2 odbc references in the plug in project settings because I cant find the damn libs and they do not appear to be used.

Replaced the windows.h inclusion section in JuceVSTWrapper with the one suggested by Haydxn. Simply changing the order of the includes does not fix that problem.

I added the source dir to the compiler paths to allow JuceVSTWrapper to find JucePluginCharacteristics. But I think that’s kosher?

So, whats going on.


#2

Very interesting stuff. Thanks for the bug-hunting!

I just tried SVH, (which I’d never heard of before) - it’s a very very subtle problem, not entirely my fault. Seems like my code was accidentally letting the host repaint its windows during idle calls, and SVH must have been doing something naughty during its repaint routine, which was causing some bad things to happen. I’ve got a fix for that now.

Tried VSTHost, but that seems to work with no probs here.

The VST analyser seems fine too, though it does a feeble job of handling UI resizing.

No idea how those obdc references got in there, BTW! Must have been VC++ sticking them in without asking.

Just got a copy of Logic today, so I’m going to do a bit of AU debugging and post a new version of the wrapper soon…


#3

The VST analyser seems fine too, though it does a feeble job of handling UI resizing.

Truly. Upon futher experimenting, it seems clear to me that the app craps out when I load a plug, show its gui, close it and load a different one, and then show that gui. (Hence the “sometimes”.) I’m going to try it with some known-to-be-good plugs, but chances are it a bug in the app, not in JAP. Sorry for leading you astray with this one.

And there is still the issue with the gui no showing at all in tracktion.

But I suppose it could depend on the issue you already found?

Cheers.


#4

Biazarrely, I can’t find an older copy of tracktion 1.x to try… but yes, it could be the same issue.

I’m going to post a new version of juce + JAP this afternoon, so probably best to get that before doing any more experimentation, as it’ll certainly fix a bunch of problems.


#5


#6

Congratulations!! Nice!! :):o:D


#7

always nice to have a nice shiny new juce and jap to tinker with :slight_smile:


#8

I am sorry to report, no great improvments after update. Tracktion problem persists with both the demo and my plug.
Tobys host does well with the demo, but my plugs gui is now one pixel wide and very very tall. I’ll look into that.
Also tested with EnergyXT demo. Big fuxxxor with both demo and my plug. It also seems related to opening and closing the gui.

Perhaps its a problem with my compile. If someone else has a nice demo dll laying about, I’d like to test with it.


#9

Ok, one problem solved. I forgot to clean out the obj files so my plug was a mixed breed for a while. Another problem may have been that I didn’t do a delete all children on the editor so a custom component of mine never got properly destroyed.
So its a mixed bag I’m dealing with. I also get a warning on compiling now:

PS:
A c++ noob question here (I’ve only done this for a few months you know):
If I make an array like so int myArray[52];
Do I need to release it explicitly? I suppose not, huh? They dont do it in the examples.
Thats a little bit confusing since if I go like this: int* myArray; and then allocate using ‘sizeof(int) * 52’ I have to release it…


#10

you’re right. if you ever say

type variableName;

whether it’s an array or a single entity, it’s created on the stack. Because you’re saying “I WANT THIS HERE NOW!”, the compiler knows for sure that it’s going to be there, and it also knows that when the scope is left (i.e. the program leaves the function it was created in, or the program terminates) the object will be destroyed.

If you make a pointer and create a ‘new’ object, the compiler doesn’t know for sure what’s needed with regards to its existence; you can make a new one in a function that can exist anywhere as long as a pointer to it has been handed out. For example, you could have a loop with a ‘new’ operation to create a bunch of objects; the compiler won’t always know how many objects will have been created by the end of that loop (if the user got to choose how many times it would run) so it can’t put in automatic destruction.

If you ‘new’ something, you have to ‘delete’ it. If you create it just on the stack (i.e. make something without the new keyword) then it will automatically die.


#11

Thanks! You are invaluable to my JUCEy success. :smiley:

('Cept right now I seem to be stuck. :cry: Tracktion still wont show gui, EnergyXT and SVH still have fatal exeptions when closing the gui )


#12

Weird. I ran with SVH in the debugger and had no problems at all. Haven’t tried EnergyXT for a while, I’ll have another go of that.


#13

Hmm, well, it might be something in my build environment. Another win platform sdk thing maybe. Or something with XP version or ASIO drivers.

If you have the time… would you mind putting a compiled demo dll up somewhere where I can grab it, so we can rule out something being wrong with my environment.


#14

Try the latest ppmulator:

http://www.rawmaterialsoftware.com/shop/downloads/PPMulator1.6.zip

It’s built with the latest stuff…


#15

Works fine, so its something in my build. :frowning:

Its likely to be the win platform sdk version. I guess I have to bite the bullet and get a hold of the older version.

Or, possibly it could be Haydn’s fix? (Have you built any vst’s lately Haydn?)


#16

Ahhhhrrrrgg my head a spolde!!! :frowning: :evil: :frowning:

I installed the old sdk as referenced in another thread. Rebuilt JUCE and the JAP demo. (Both build without alterations. Some minor warnings.)

But the deal is the same. No joy.

What else could it be? Compiler flags? Runtime versions (VC Toolkit 2003)? Karma?Maybe I should get mingw and give that a shot…

EDIT_
Now here is a big [color=red]WTF[/color] to wallow in: If I compile with debugging symbols, Its fine!
Demo is fine! My plug is fine! In tracktion, SVH and EnergyXT! How about that.
Is it supposed to be that way… am I the sex crazed moron in this comedy?
Anyway, Its good enough to allow me contiue working in any case.

EDIT_
[color=red]WTF[/color] [color=red]WTF[/color] [color=red]WTF[/color] Now it works without the debugging too!! I swear on my mothers virginity that that was the only compiler option I changed!!!
The only thing I can think of is that something from the older JUCE/JAP still lingered in the form of an OBJ file somewhere that got included despite me clicking clean, and rebuild.
Or maybe something from the “old” sdk (which is to say the new sdk that I had before I replaced it with the old one) hung around for a compile or two just out of spite? (Its MS stuff after all, their SDKs are spiteful)

So I suppose this is case closed.

But I am still in WTF mode.


#17