Closed GoogleCodeExporter closed 8 years ago
First: very odd that VSTGUI (as I understand it) sends beginEdit and endEdit
for controls that have nothing to do with parameters. This sounds like bad
design to my ears. I'd like to say bug even, but can't really, cause as we all
know, there isn't anything like a proper spec of allowed parameter ranges in
the VST SDK.
Before I continue investigate, could you please confirm that the problem is
still there with the latest version of Symbiosis that is in the SVN trunk here
(it can't be the same, cause the line numbers you mention doesn't match)?
Also, I must ask, is 3.6 the latest and final VSTGUI v3.x version? (I've never
actually used VSTGUI myself.)
Original comment by malstro...@gmail.com
on 16 Apr 2013 at 8:57
Actually VST 2.x documentation on beginEdit() says:
"To be called before setParameterAutomated (on Mouse Down). This will be used
by the Host for specific Automation Recording."
Is VSTGUI actually calling setParameterAutomated() for the extra controls as
well? If not, I am leaning towards considering this as a bug in VSTGUI and
ought to be patched there. E.g. check "index < cEffect.numParams" before
calling beginEdit.
Original comment by malstro...@gmail.com
on 16 Apr 2013 at 9:03
[deleted comment]
[deleted comment]
You can't really trust Steinberg's comments in the VST and VSTGUI SDKs. They're
in garbled Germanglish.
All VSTGUI 3.6 controls call BeginEdit and EndEdit. I assume the host knows not
to automate them because your control has an index that's > numParams.
(Automation is actually done by your implementation of
AEffGUIEditor::valueChanged which calls setParameterAutomated on appropriate
controls. In my implementation I test that the index is < numParams before
passing to setParameterAutomated.)
And no, VSTGUI 3.6 is not the final version but it's the end of that line.
VSTGUI 4 is completely unrelated, and by reports I'm seeing, not exactly stable
or well tested yet. At any rate, I'm married to it. I'm using the latest VSTGUI
3.6 RC2, from here
http://sourceforge.net/projects/vstgui/files/vstgui/VSTGUI%203.6/
There are a huge number of VSTGUI 3.x implementations that will work like this.
And again, obviously we need to have controls that aren't also parameters for a
number of reasons.
(Sorry for submitting this 3 times, fixing typos.)
Original comment by AdmiralQuality@gmail.com
on 18 Apr 2013 at 12:43
Oh and the Symbiosis version I'm using was the one I got here...
https://code.google.com/p/symbiosis-au-vst/downloads/list
1.29b Feb 2011
Says 1.29b in the head of the Symbiosis.mm file
Original comment by AdmiralQuality@gmail.com
on 18 Apr 2013 at 12:47
Checked the VSTGUI code now, and yes it does look like VSTGUI always invokes
the host's beginEdit and endEdit, regardless of who is actually using and
listening to the control. IMHO this is very poor OO-design as there are already
controlBeginEdit and controlEndEdit in the listener interface. I would assume,
since the listener is responsible for calling setParameterAutomated, the
listeners ought to be responsible for calling beginEdit and endEdit. But noo.
Without deeper insight into VSTGUI it looks like a hack. Perhaps for historical
reasons.
Anyhow, since you are right in that very many existing implementations will end
up calling beginEdit and endEdit outside the parameter range I will change the
assert to a check. Although it hurts me to do so. Not very
design-by-contractish.
Original comment by malstro...@gmail.com
on 22 Apr 2013 at 10:20
Made the change in r22. Could you please verify that it works as you requested
now and I'll close this?
Original comment by malstro...@gmail.com
on 22 Apr 2013 at 11:33
Thanks. Might take me a few days to get to it, will let you know when I do.
Original comment by AdmiralQuality@gmail.com
on 22 Apr 2013 at 3:39
Thanks! No rush. My plan is to smack a "stable" label on this version in maybe
a couple of weeks when Microtonic 3.1 goes to release candidate stage.
Original comment by malstro...@gmail.com
on 22 Apr 2013 at 3:41
r22 seems to have fixed this. VSTGUI 3.6 controls with IDs (tags) greater than
the number of VST controls are working as they should now.
Original comment by AdmiralQuality@gmail.com
on 11 Jun 2013 at 2:49
Original issue reported on code.google.com by
AdmiralQuality@gmail.com
on 4 Apr 2013 at 12:31