VST Parameter Issue

5 replies [Last post]

Wed, 11/30/2011 - 19:33

TopTension

Joined: 11/30/2011

Hi there,

new forum user here, but I have been using Mulch for quite a while now. I use Mulch mostly as a test bed for VST development (using the Steinberg VST 2.4 SDK) and love it!

The issue I have is most likely related to my home cooked VSTs, not to Mulch, but maybe someone can help with an explanation of what's going on behind the scenes in Mulch. The problem is, that sometimes, when I save a project, all VST parameters seem to be stored as either 0.0 or 1.0, not their real values. At least that's how they come back when I reopen the project until I set them again manually and save the project again.

I suspect, that I need to implement some more functions from the VST 2 interface. I have implemented setParameter and getParameter (which returns the parameters exactly as they were sent with setParameter). The set/getParameter interface is taken straight from the Steinberg AGain sample. I do not have an editor in my plugin, I am using the Mulch provided default sliders-for-all-parameters interface, since my only interest is in developing the audio processing code.

Another hint is, that whenever one of my plugins is loaded and I save a modified project, the asterisk in the Mulch title bar comes back immediately, indicating an unsaved project, until I save the project a second time.

Unfortunately I can't test most of my plugins in a Steinberg host, since they are all 12 in / 12 out for 10.2 audio and I don't have Nuendo, which is the only program i am aware of with 12 channel busses. My stereo plugins work fine in Cubase or Wavelab, but show this occasional problem in Mulch.

Hopefully this behaviour rings a bell with someone. I must be doing something wrong, but I don't know what. Any help would be much appreciated, thanks for listening.

TopTension

P.S. I hope this is the right forum section for this...

Mon, 12/05/2011 - 16:21

Ross B.

Joined: 04/10/2009

I havn't heard of this before. Do you change the values of any parameters within the plugin? If so you need to issue audioMasterAutomate messages to notify the host that the values have changed.

If you'd like to email me one of your plugins with an explanation of how to reproduce the problem I can take a look here. Feel free to get in touch --

You could also try looking in the .amh file (it's XML) to see whether the parameter values are being saved as 0/1.

As for the * displaying -- this can be caused by a number of things.

Wed, 12/07/2011 - 03:37

TopTension

Joined: 11/30/2011

Thanks Ross, I wasn't aware of the XML nature of the Mulch files, sounds like a good place to start.

No, I am not modifying any parameters in my code. They go into a float array as they come in, then I calculate some derived variables for internal use. getParameter simply returns the appropriate array member.

I'll have a look at the XML and if that doesn't get me forward, I might take you up on your offer to try it out yourself I'd need to strip some customer functionality from the plugins first, since I am working under an NDA, hopefully I can still reproduce the behaviour then (if not, there might be a clue=)).

Thanks!
TopTension

Fri, 12/09/2011 - 03:09

TopTension

Joined: 11/30/2011

Finally it happened again.

The parameters in the XML are correct, but I am getting just 0.0 and 1.0 in my setParameter() function. Every time. A MGain-Block and a TestGen are also affected.

I am just wrapping everything up and you will have mail soon. Your support is much appreciated.

TopTension

Fri, 12/23/2011 - 21:47

TopTension

Joined: 11/30/2011

In the meantime I found out that sometimes I can load the files in question, if I open another file first and load it then. I assume it may be a Mulch issue or an unfortunate interplay between my VSTs and Mulch. Anyway, I can live with that for now since there is a workaround.

TopTension

Thu, 12/29/2011 - 17:43

Ross B.

Joined: 04/10/2009

In the meantime by email we worked out it's something to do with computers that use comma "," as the decimal place. This was causing numbers to be written to the .amh in an unexpected format. The fix is still being worked on.