Okay, first thing i’ve found is that the resizer has a bit of a troublesome time in energyXT. Try resizing in the example filter. The actual editor window can sometimes end up a different size to the editor component at the end of the drag, depending on how fast you’re dragging the mouse.
If you were shrinking it, you can see that the current component size is painted over a snapshot of the previous size.
If you were enlarging the window, then the final component size is larger than the window, and you can lose the resizable corner tab.
Closing and reopening the window sets it back to the correct size.
strange - I did test it in energyxt… The resizing is a real pain, as whatever you do seems to go wrong on at least one host. I’ll take another look at that.
i thought that might be the case ;). It’s not quite so obvious with the demo plugin, as it’s got a plain white background, but you can at least see that the ResizableCornerComponent can end up in the wrong place if you’re moving the mouse too quickly.
I’ve seen this in Tracktion too. At one point, I saw drop shadows that were completely different size then the window itself which was quite bizarre. Ben
One thing i’ve discovered that’s actually quite serious for me for a project i’m working on… it concerns MIDI generating plugins in TRACKTION
I made a plugin yesterday that works fine, generating MIDI CC data from mousewheel movements. This morning, before making an interface tweak, i decided to alter it so that it was compliant with the new JuceAudioPlugin model. Hardly any of the actual code has changed, and certainly not the midi generation code. Now it still works fine, but there is a very serious yet initially invisible problem.
Hooking up MidiOX to the midi output port, i discovered that the new version of the plugin does NOT generate any MIDI at the plug’s midi output if it has just been instantiated by itself on a track. Once another VST plugin has been put after it, it works as normal, even if you then remove that plugin from the chain.
This may not seem important, but when making a plugin designed to send MIDI data to external hardware, this is a very serious problem.
[EDIT] in case it isn’t clear, i’ve also tried several other little plugin ideas generating simple midi messages in various ways. the same thing happens, and i need to add another plugin to the track before it will generate midi, despite the interface seeming to be functioning properly. If it’s any help, this is the type of thing i’m doing when generating my midi…
(in filter class)...
private:
...
OwnedArray<MidiMessage> generatedMidi;
...
public:
...
generateMidiMessage()
{
generatedMidi.add( new MidiMessage::controllerEvent(1,0,value) );
}
the contents of generatedMidi get added to midiMessages (and then cleared) in the processBlock() section
Are you sure you’re not deleting objects twice? If you put them in an OwnedArray and then add them to another OwnedArray in the process callback, they’ll get deleted by both arrays…
ignoring the bug in the example code i put there ( i was away from the code at the time oops! ), no that’s not an issue. the messages are added along the lines of…
midiMessages.add( new generatedMidi[i] );
… in the processBlock call. of course, from you saying that i see it’s probably a better idea to new them into a normal array in the first place…
however that’s not the problem. as i’ve said, the code that generates the midi and adds it to the outgoing messages works. in fact, it all works, but with minimal changes in code from the old version to the new version (of the wrapper) there is this bug which makes the plugin not output midi until another plugin has been put after it.
I think it’s actually that the processBlock function just isn’t getting called until some kind of ‘major track activity’.
I just tried some tests with the unedited demo vst (the demo project included with the latest juce audio plugin framework), and hopefully this should perhaps reveal the problem i’m experiencing.
Try this test:
1- Create a new edit in Tracktion.
2- Add an instance of the demo vst plugin to a new empty track.
3- Lock the plugin’s GUI.
4- Try to move the playhead cursor, or press play.
Notice that nothing is changing on the plugin, where it should be showing info about the last note, current position, etc…
Now, if you put another plugin (say a synth, or an Aux Return) on the same track, the plugin UI will begin to show the changes. Similarly, if you connect an input to the track, the plugin will begin to act as normal. Until this kind of activity though, the plugin is not carrying out its actions, which is a real problem if the plugin is designed to sit by itself on a track talking to external devices.
I would perhaps have considered that it were a bug in tracktion, or a simple vst spec issue, were it not for the fact that only yesterday i was able to compile a plugin that worked fine! Maybe it’s something to do with the new callback system you’ve implemented? (that’s a blind guess as i’ve not even looked at that yet) I’m scratching my head to think of what it might be that has caused this to happen in this new version.
could be the silenceInProducesSilenceOut property of the plugin? That’s used to call the VST noTail() method and tell the host whether it should be played when there’s no input.
nope just tried setting it to ‘true’ just in case it was the wrong way round, but still the same effect. starting to drive me a little bonkers now, but i guess i’ll just have to keep looking to figure it out.
well i’ve spent i have no idea how many hours trying to figure this out, and i’m not getting anywhere. for now i can just set it up as isSynth = true, and then the processBlock gets called from the beginning, but this is not ideal as it pops up a “this track has a synth but does not output to an audio track” bubble every time. it’s obviously not a danger or anything but it’s very nearly as annoying as needing to jigger around with things anyway. it seems very unprofessional to have a warning popup appear when you use something potentially in every project.
i really need to figure this one out i know it’s possible for an ‘effect’ to begin with processing from the off, as the old wrapper could do it fine!
Ok, how about setting the plugin’s wantsMidiInput flag to true? I’ve a feeling that in the old wrapper code that would always have returned true because of a bug in the canDo code.
Sounds like it’s a tracktion problem rather than a wrapper bug, really. Tracktion avoids processing a filter unless it’s flagged as a synth, but if you mark it as wanting midi input I think it’ll also use that as a hint that it might make a noise.
no, sadly. that’s been set to true the whole time. even tried setting it to false but no. never mind, i’ll make do for now, i’m wasting time trying to figure this one out! thanks for your help
me too! i’ve been trying to compare them but didn’t manage to achieve anything. unless it’s a juce 1.15 thing, because the old one would only work with 1.13… but i doubt that and certainly can’t waste any more time! :hihi: no worries. i’ll look into that stuff again after i’ve finished this project.
right, i’ve been playing around a lot with the wonderful Plugin Consultant, and monitoring the stuff that’s going on in the various versions. Up until now i’ve been determined to find a problem with the new juceaudioplugin thing, but i think it’s just some crazy bug in the old version that was causing the behaviour i wanted .
In all my tests, the conclusion is that the original juce audio plugin framework would somehow cause Tracktion to send an effMainsChanged when the editor window appears, causing it to begin the process cycle immediately.
Plugs compiled with the new version can be seen to NOT cause this; Tracktion doesn’t send an effMainsChanged til ‘something’ happens (connecting an input, or putting a synth on the track,etc). This is true even of just simple effects plugins- monitoring the activity of any effects plugins put alone on a track shows that effMainsChanged doesn’t get called until something is explicitly connected to it.
In energyXT, however, effMainsChanged happens right away for all plugins, so things just start working right away.
I think i’d kindof prefer that Tracktion didn’t hold back like this, as i’d prefer to be able to have my plugin as an effect (seeing as it isn’t a synth). I don’t know if you’d view this as a ‘bug’ in tracktion, as it is a very specific case. To me it kindof feels like a bug, but i could understand if there were reasons for it to be doing this.
i thought that might be the case ;). It’s not quite so obvious with the demo plugin, as it’s got a plain white background, but you can at least see that the ResizableCornerComponent can end up in the wrong place if you’re moving the mouse too quickly.
just tried setting it to ‘true’ just in case it was the wrong way round, but still the same effect. starting to drive me a little bonkers now, but i guess i’ll just have to keep looking to figure it out. 
but no. never mind, i’ll make do for now, i’m wasting time trying to figure this one out! thanks for your help
