Voxengo Premium Membership - All Voxengo Plugins For a Fixed One-Time Fee
Forums     Discussions     Announces, Releases and Discussions REAPER VST Extensions

Dandruff: For which hosts did you add the ''VST built-in refresh'' option?

It works in all VST hosts.

And what's "better"?  Enabled or disabled?

I would go with enable....  I keep checking all my Voxengo products for Friendly Show Girls ! :) ...there voted #1 at the office 4x in a row !  John J Krupinski

Dandruff: And what's ''better''?  Enabled or disabled?

Depends on your needs.  Built-in VST timer usually less frequent.  So, if you want a lively graphics, leave it disabled.  Otherwise enable it - that will also allow you to conserve some CPU resources.

Yeah, just noticed lower redraw rate in Reaper with this option enabled.  Disabled is "better" here :)


could you also please integrate that second extension:

effVendorSpecific(0xdeadbef0, parm, rangeptr, 0.0)

Queries the range of a parameter (allowing the plug-in to use more than the 0.0...1.0 range that VST defines).  The host does something like:

double range[2]={0,1};

if (effect->dispatcher(effect, effVendorSpecific, 0xdeadbef0, parm_index, range, 0.0)>=0xbeef)


// range[0]..range[1] is the range instead of 0..1


Or, to implement it on the plug-in side (in addition to responding to effCanDo/"hasCockosExtensions"):

case effVendorSpecific:

if (index == 0xdeadbef0 && ptr && value>=0 && value<NUM_PARAMS)


((double *)ptr)[0] = min_val;

((double *)ptr)[1] = max_val;

return 0xbeef;



Currently when editing envelope point values in REAPER (rightclick -> Set point value) your latest plugins still just report 0.000-1.000 range.

Would be cool to have the correct ranges in the edit field too.  Thanks!

Seems to be a "strange" extension.  Reaper could use that first extension to query extreme values.  I find it this second extension a bit unstable, because it can't represent arbitrary values like compressor ratio "1:10".

Maybe you are not quite understood this extension.  Voxengo (and most VST) plug-ins expect 0..1 automation values - while this extension seems to try to allow bigger range for some esoteric reason.  I do not think it's related to representation of extreme values.  I suggest you to ask Reaper folks to fix that 0.000 and 1.000 reading in Reaper - nothing stops them from getting real values.

Ok, I've posted that in the REAPER forums:


Let's see what they'll say ...

Here you go Aleksey:

schwa (REAPER developer): The envelope point editing requires a new addition to the extended VST calls.  It's explained here: http://www.cockos.com/reaper/sdk/vst/vst_ext.php#vst_ext, under "effString2Parameter".  The issue is that in that context, the user can enter a new value for that envelope point, so the plugin needs to be able to convert parameter values to strings, and also convert strings back to parameter values without actually setting the parameter.  This is a fairly specialized use, in fact we haven't even implemented it for all Reaper plugins.  ReaControlMIDI is the only one that comes to mind, per this issue ticket: http://forum.cockos.com/project.php?issueid=1294.

So obviously you would need to implement this:

effVendorSpecific(effString2Parameter, parm, buf, val)

Converts the user's string to a normalized parameter value, without setting the parameter.  Reaper uses this when the user is manually editing an envelope node, for example.  Calling with buf="" is a test for function availability.

Example host-side implementation:

char buf[256], retbuf[256];

sprintf(buf, "16383");

strcpy(retbuf, buf);

if (effect->dispatcher(effect,effVendorSpecific,effString2Parameter,parm_idx,retbuf,0.0)>=0xbeef && *retbuf)


double val = atof(retbuf);

printf("parm %d, string=%s is %f\n",parm_idx,buf,val);


Example plug-in-side implementation:

case effVendorSpecific:

if (index == effGetParamDisplay && ptr)


if (value>=0 && value<NUM_PARAMS)


int ival = atoi(ptr);

float normval = (ival-minval)/(maxval-minval);


return 0xbeef;



Well, there's obviously a mistake in effString2Parameter "plug-in side" implementation, because I have this implementation in "vendor specific" part already - it's for different purpose.
This topic was last updated 180 days ago, and thus it was archived.  Replying is disabled for this topic.