This project has moved. For the latest updates, please go here.

Brand new to VST.NET, question about the delay example

Sep 20, 2009 at 6:07 PM

Although I am not a programmer, my co-conspirator and I began using VST.NET last night,

He is a professional coder and was quite excited by the idea of being able to use .net to make plug-ins.

I myself am responsible for the design, DSP and such.

 

To begin we assembled the "sample delay" project.

Oddly, it appeared in VST Host just fine, noticbly altered .wavs in Audacity without audibly being an echo effect,

and worked some, but not all, of the time in SynthEdit.

 

We were a little baffled by the fact that normally VSTs expect a parameter range from 0 to 1, but the sample code was set to "500" by default, and could have gone to a max of 1000 except that in SE turning the knob would cause the parameter to be constrained to a maximum of 1.  But even without touching the knob, and reloading the program, a delay time value of 500 didn't cause an audible echo.

We were able to create an audible delay effect by changing the code to this:

 

private void _delayTimeMgr_ValueChanged(object sender, System.EventArgs e)

{

VstParameterManager paramMgr = (VstParameterManager)sender;

_bufferLength = (int)(paramMgr.CurrentValue * _sampleRate); // / 1000);

}



public float SampleRate

{

get { return _sampleRate; }

set

{

_sampleRate = value;

// allocate buffer for max delay time

int bufferLength = (int)(_delayTimeMgr.ParameterInfo.MaxInteger * _sampleRate); // / 1000);

_delayBuffer = new float[bufferLength];

}

}

I, myself, partially understand the above so I hope I can discuss it cogently.  Do the changes we've made make sense?  Or are we missing some underlying reasoning behind the original code and have created in inapt workaround?

Coordinator
Sep 21, 2009 at 9:54 AM

Welcome to VST.NET :-)

The Vst Parameter is a known problem area. The VST specs allow for non [0,1] parameter values, if you implement the parameter 'properties'. VST.NET does this and the Delay sample initializes these properties for all its parameters. Look at the VstParameterInfo objects being created in the Delay class' .ctor. So the problem is not that VST does only support parameter values of [0,1] range, it is that some (okay, most) host hard-code this. I tested all samples with the vst host made by hermann seib (is that the same VST host you speak of?) and it handles these parameter values correctly.

So all the 'faulty hosts' freak out over these other values and will not produce the correct result.

I still want to look into this and see if I can transparently fix this problem in the VST.NET framework. But I do not have the time right now to do this.

So, to recap: yes, the sample is correct, you can have parameter values that go beyond the [0,1] range and yes it does not work for most hosts :-(

Hope it helps.

 

Sep 21, 2009 at 7:54 PM

This does indeed help.

Yes, I was referring to herman seib's VST host.

I understand what you're saying but I don't see why the default value 500 for the delay time at instantiation so long as the UI wasn't disturbed wouldn't cause an audible delay in any of the hosts it was tested in.  It did cause an audible delay when we entered the code above.  Looking through an oscilloscope in SE it was obvious that a delayed signal was changing the phase of the waveform, and the wet level and dry level did indeed change the amplitude, but the delay was so short it didn't even cause comb filtering.  I would certainly be able to hear if the delay caused was over 25 ms.

But, like I said, I guess we are just starting out and are quite glad to have VST.NET  to work with,  Now I'm reading about your universal sysex thing on KVR.

Coordinator
Sep 21, 2009 at 8:08 PM
Edited Sep 21, 2009 at 8:52 PM

No that 500 value is a mistery to me too. The default value is 200 and is set to the DefaultValue property of the VstParameterInfo class in the ctor of the Delay class...

I'm currently looking into a way to transparently solve this issue. Will probably checkin some code soon. Just finished the initial impl. now testing.

PS: What do you think about the Midi Device Schema? Good or bad idea?

http://www.kvraudio.com/forum/viewtopic.php?t=263950&sid=fd7174df77e8724cdb1a36f3d5e29963

Sep 21, 2009 at 8:35 PM

What do I think of it?

1)  It'd be super-useful for those who understand what it means.  Which will be few, and fewer will be able to use it.  I personally own a CME VX5 which has NO patch editor/librarian a la M-Audio's Enigma and, being that it's a very complicated and deep (and flawed) device I've tried to "packet sniff" it to learn how I could send sysex.  This is far beyond my abilities.  I also have seen a physical teardown of my AKAI EWI midi horn and an analysis of the midi it is sent to configure it - I'd like to create my own "fingerings" beyond the 4 supplied with the unit - but Garritan says they don't have access to that data, and AKAI simply never responded to my queries.  Again, despite understanding what I need I'd not be able to use the info myself.

Which leads to

2)  You, like me, apparently have the saintly impulse to put endless hours into creating things to help people.  Given the above, from someone who is relatively technically knowledgable, is it worth your time?  I don't know; I can't fathom how you managed the .NET port!

The number of people who understand the hardware, the software code, and the MIDI standard (let alone sysex) is very small.  With the tool you envision that handful of people would most likely be able to create very powerful tools to improve on the short-sighted hardware companies' sysex implementations.  Again, this scenario relies on people thanklessly donating their time and expertise.

Coordinator
Sep 21, 2009 at 8:58 PM

Thanx for the kind words. Yeah, I have had some bad experiences too with companies not willing to assist you when using their sysex!

Ultimately it should be possible for anyone with a device manual to create a device schema. Obviously this would have to be a little more user friendly than xml schema! ;-) I was thinking a graphic DSL designer might do the job...

Anyway back on topic: I've just checked in a possible solution for transparently normalizing parameter values for a plugin. Internally you still work with what ever values you specify in the VstParameterInfo but externally the paremeter value is normalized to [0.0, 1.0]. Also fixed a bug in the delay sample and it now uses the default value for the delay time parameter during sample processing.

 

Sep 23, 2009 at 4:26 AM

Thanks, Jacobi!  You're incredible.

I can confirm that it all works great now.

Sep 27, 2009 at 8:43 PM

I have a new question.

When loading our VSTs into Sensomusic's Usine host the parameter's names don't display, and no parameter value information is displayed.

Whereas all seems fine in SynthEdit and VST Host.  Have you any idea why this is?  They are all labeled "p-0" "p-1" etc.

Coordinator
Sep 28, 2009 at 5:47 AM

I never heard of that host, so I can only say how I (try to) solve these type of problems in general:

- Hook a debugger (visual studio) to the exe of the running host.

- Put break points in the code area's of interest (in your case, I would put break points in all parameter-related methods in the StdPluginCommandStub).

- Load the plugin and follow the click-path to reproduce the problem (in your case probably just open the plugin editor).

- Follow the code flow until you see the problem (hmmm, the hard part ;-)

 

Good luck!

Oct 2, 2009 at 4:58 PM

Well, I've completely forgotten that previous minor nuisance as I now have a working alpha version of my design, in VST form!

Thanks, jacobi.  You pretty much just made my year.

I guess I should go load it up in Usine, as it's of most use in modular DAWs like Usine or energyXT.

Now, to design a GUI with little or no previous experience... my brain is overstuffed with new info this last month.

I'll keep you updated, though.  It's all working great at the moment.

Coordinator
Oct 2, 2009 at 6:50 PM

That's great to hear!

Good luck on the UI.