Premium Membership - All Voxengo Plugins at a Fixed One-Time Fee - Click Here For More Info
Summer 2018 Discount at Voxengo
Forums     Discussions     Announces, Releases and Discussions REAPER VST Extensions


Last

Next

Previous

First



Aleksey,

any chance to implement some VST extensions to your new framework to get the VST values displayed properly formatted on Reaper's envelopes?

http://www.reaper.fm/sdk/vst

effVendorSpecific(effGetParamDisplay, parm, buf, val)

Gets the formatted display of a particular value for a parameter.  This REAPER uses for example when displaying the value of a VST's automated parameter on an envelope tooltip.  Example implementation on host:

char buf[256]="";

if (effect->dispatcher(effect,effVendorSpecific,effGetParamDisplay,parm_idx,buf,val)>=0xbeef && *buf)

{

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

}

Example implementation on plug-in:

case effVendorSpecific:

if (index == effGetParamDisplay && ptr)

{

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

{

sprintf(ptr,"%f",opt);

return 0xbeef;

}

}

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;

}


Thanks for the idea, but currently I'm not interested in supporting these extensions.  Such extensions are most probably in abundance among VST hosts, supporting all of them is a bit tedious and does not offer much benefit to all users.

Beside that "rangeptr" is an obvious Reaper's quirk, not required in VST protocol at all - it simply does not add anything useful, only makes things look complicated.


From the VST development perspective all these extensions will end nowhere, because VST standard is controlled by Steinberg who obviously even not interested in a further VST2.4 development.  It's a dead end, it's better to spend time and will on a totally new standard than to beat that "dead horse", so to say.

Mhh, I still would love to get this working in Reaper.  The developers just don't know a way to get the values from the plugins without moving knobs on them.

Maybe you can join this thread: http://forum.cockos.com/showthread.php?t=27424 (schwa = developer)?


This is missing functionality in VST 2.4, there's no argument about that.  We've offered a way for plugins to work around it, but unless other hosts also support our extensions I can appreciate that it would seem like a low-reward feature for a plugin developer to add.

"it's better to spend time and will on a totally new standard"

... any suggestions? :)


Aleksey,

I agree a new plug-in standard would be great, the problem is that no new standard has been developed and nobody seems to be actively pursuing this.

Regarding our extensions, if other hosts have published similar extensions, I'd like to hear about this -- I haven't seen any and if we did we would be happy to support these.  So from your perspective the only ones really available are ours..

If more plug-ins support our extensions, then that will give host makers (other than steiny no doubt) incentive to support them as well, giving plug-in authors more incentive as well.

You don't have to implement the rangeptr[]] functionality.  Simply adding the formatting extension would make a lot of your users who also use REAPER happy, and would put pressure on other hosts to add support for it as well.

Please reconsider...

-Justin

Edit: BTW, the comment "From the VST development perspective all these extensions will end nowhere, because VST standard is controlled by Steinberg who obviously even not interested in a further VST2.4 development.  It's a dead end, it's better to spend time and will on a totally new standard than to beat that "dead horse", so to say."

There's doesn't seem to be anything that prevents others from extending VST..  Other than having the extended-VST still being encumbered the way VST is...


....Intellectual property.. now that is a very big horse! an the follow up is.... not dead, likes new places to go... likes kids,old people an if ya got some sugar cubes ..Look out ! ... stuff like that :) my idea would be find a good book keeper the U.K. fuss'es with words all the time, intell-prop books will be in very good shape an they some kind of reputation to actively pursue!,,, if there is any Queen's English in the document there a very good chance for some ''hear,hear an there, there an all that mot'' respectively... then the ' new standard' will free up more time for everyone to work on some very cool plug-ins !  John J Krupinski

Schwa and Justin, thanks for visiting.

Orion Platinum devs have some proprietary extensions to my knowledge.

The reason I'm against adding these bits of "spaghetti code" is that it calms down a will to work on a new open plug-in specs.  Well, of course, it's like 5 minutes of work, but this opens a can of worms giving a carte blanche to every host developer out there to contact me directly asking for supporting one more "exclusive feature".

I agree that automation requires "off-line" parameter readout which VST is lacking.  But automation also requires versioning system and VST is also lacking this feature.

You may call me an "ass" or something like that, but it won't resolve plug-in spec problems our pro audio "scene" experiences currently.


Hi Aleksey.  How about this: if you add a your own extended VST call to your plugins to get the formatted value of a plugin knob without moving the knob, we'll support it on our side.

This particular VST shortcoming is easy to fix, I'd much rather spend a few minutes fixing it (even if it's just an incremental fix for a few plugins) than worry about precedents or wait for some new standard.

Completely apart from that, we're always happy to talk about a new standard, too.  There's obviously enough interest among plugin developers (FXPansion always comes up in conversations like this, etc).


OK, I will try to implement this feature.

However, I think Reaper's development team is a good candidate for new plug-in spec development core team.  You have a growing market share, and you are responsive enough.  If not you, I doubt anybody else can become a solid core team for the open plug-in spec.

This topic was last updated 180 days ago, and thus it was archived.  Replying is disabled for this topic.

Last

Next

Previous

First