VST Plug-In's life cycle

[LemonLime]

Quick question.
Is there any way to control a VST plug-in's life cycle? It varies between hosts, and I find it a little annoying when an instance of a plug-in is destroyed as soon as (offline) processing is done since it doesn't save the current state of the parameters.

Audacity is good in that it switches a plug-in into suspend state and doesn't destroy it until the program is closed. Soundforge, however, destroys a plug-in after it's done processing, so it always opens to the default "init" state. I searched through the VST2.4 sdk for any clues, but I came up empty. Any way to stop Soundforge from doing this?

Thanks!

[AdmiralQuality]

The solution is to not use shitty hosts like Audacity and SoundForge.

Also, keep in mind VST plug-ins aren't really designed for offline processing. (Though of course they can be coaxed to do it.) And why save the state of a process you already ran? And why would you expect that state to be different after it has ran, than before? It's OFFLINE. Non-interactive. Non-real-time. And once you run it, it's work here is done.

[wiwatti]

Quick question.
Is there any way to control a VST plug-in's life cycle? It varies between hosts, and I find it a little annoying when an instance of a plug-in is destroyed as soon as (offline) processing is done since it doesn't save the current state of the parameters.

Audacity is good in that it switches a plug-in into suspend state and doesn't destroy it until the program is closed. Soundforge, however, destroys a plug-in after it's done processing, so it always opens to the default "init" state. I searched through the VST2.4 sdk for any clues, but I came up empty. Any way to stop Soundforge from doing this?

Thanks!

There is absolutely no problem with this. Sound Forge is an Audio Editor , not a sequencer. If you need to restore the previous state then just save it in the Destructor and recall it in the Constructor, maybe if the time ellapsed between two instances is very short or I don't know what...

[LemonLime]

Also, keep in mind VST plug-ins aren't really designed for offline processing. (Though of course they can be coaxed to do it.) And why save the state of a process you already ran? And why would you expect that state to be different after it has ran, than before? It's OFFLINE. Non-interactive. Non-real-time. And once you run it, it's work here is done.

Very true. Unfortunately I didn't know that VST plug-in's aren't really designed for offline processing, and also that their offline processes that are offered are not widely supported by hosts. I've learned tons through doing this though, so it's all been good!

[AdmiralQuality]

Also, keep in mind VST plug-ins aren't really designed for offline processing. (Though of course they can be coaxed to do it.) And why save the state of a process you already ran? And why would you expect that state to be different after it has ran, than before? It's OFFLINE. Non-interactive. Non-real-time. And once you run it, it's work here is done.

Very true. Unfortunately I didn't know that VST plug-in's aren't really designed for offline processing, and also that their offline processes that are offered are not widely supported by hosts. I've learned tons through doing this though, so it's all been good!

Well, the VST doesn't know what time it is. It just sees samples passed to it by the host, and processes them as fast as it can. So whether that's "real time" or offline, the VST is quite unaware and it makes virtually no difference to its implementation.

But again, in offline there's no need to save settings, because you're APPLYING settings. One time. In a destructive editing process. Yuck!

[LemonLime]

Also, keep in mind VST plug-ins aren't really designed for offline processing. (Though of course they can be coaxed to do it.) And why save the state of a process you already ran? And why would you expect that state to be different after it has ran, than before? It's OFFLINE. Non-interactive. Non-real-time. And once you run it, it's work here is done.

Very true. Unfortunately I didn't know that VST plug-in's aren't really designed for offline processing, and also that their offline processes that are offered are not widely supported by hosts. I've learned tons through doing this though, so it's all been good!

Well, the VST doesn't know what time it is. It just sees samples passed to it by the host, and processes them as fast as it can. So whether that's "real time" or offline, the VST is quite unaware and it makes virtually no difference to its implementation.

But again, in offline there's no need to save settings, because you're APPLYING settings. One time. In a destructive editing process. Yuck!

I'm totally a fan of non-destructive editing as well, but with some processes this is almost impossible to do. My plug-in that I've developed is a Match Enveloper. So not only do I need to scan the selected audio stream in its entirety to acquire the amplitude data prior to processing, I need to separate it into window sizes/durations specified by the user.

It is possible this could be done through lookahead in real-time, but I'm using cubic interpolation and this requires 4 windows in order to work, and if the window sizes are big I'm not sure how that would affect processing given the indeterminate 'sampleFrames' provided by the host.

In any case, I've managed to get it working pretty well. I've had to make some compromises in the UI department (splitting the plug-in into two "halves" so-to-speak, and they communicate between one another through a binary file that contains the extracted data), but the processing itself works well.

Here's a little demo of some of its features:

[AdmiralQuality]

I'm totally a fan of non-destructive editing as well, but with some processes this is almost impossible to do. My plug-in that I've developed is a Match Enveloper. So not only do I need to scan the selected audio stream in its entirety to acquire the amplitude data prior to processing, I need to separate it into window sizes/durations specified by the user.

It is possible this could be done through lookahead in real-time, but I'm using cubic interpolation and this requires 4 windows in order to work, and if the window sizes are big I'm not sure how that would affect processing given the indeterminate 'sampleFrames' provided by the host.

In any case, I've managed to get it working pretty well. I've had to make some compromises in the UI department (splitting the plug-in into two "halves" so-to-speak, and they communicate between one another through a binary file that contains the extracted data), but the processing itself works well.

Here's a little demo of some of its features:

You can't rely on the host's buffer size (sampleFrames) for your own buffering needs. If you need a particular window size, its up to you to establish your own delay buffer to hold that many samples until you're ready to process/analyze them.

Also be aware of the VST function setInitialDelay(), which informs the host about the size of any plugin-imposed buffer, so it can delay everything else to match (plug-in delay compensation).

And sorry, but I'm not really understanding why you need to split the GUI into "halves".

Frankly, I think offline processes should be command-line apps.

[LemonLime]

You can't rely on the host's buffer size (sampleFrames) for your own buffering needs. If you need a particular window size, its up to you to establish your own delay buffer to hold that many samples until you're ready to process/analyze them.

Also be aware of the VST function setInitialDelay(), which informs the host about the size of any plugin-imposed buffer, so it can delay everything else to match (plug-in delay compensation).

Yes, I did implement my own buffer delay that holds the required samples I need for analyzing/processing.

And sorry, but I'm not really understanding why you need to split the GUI into "halves".

Frankly, I think offline processes should be command-line apps.

Absolutely! In fact, before writing the actual VST code I wrote a prototype command-line program to test all of the functions and processing. It was much more efficient and more intuitive to implement and to use because I had control of just about everything.

I split the GUI into "halves" for two reasons. One, because many of the parameters have no effect or application towards the extraction of the envelope data. This could be fixed with a custom GUI, where I could disable the parameters that are not tied to a particular process, but I'm no longer planning to do a custom GUI on this plug-in for the many reasons you've stated (and that I've become aware of along its development).

Two, processReplacing() was becoming a huge network of switch statements in order to determine what process the user was invoking (extract source envelope? destination envelope? or process?), so I figured this would speed up processing a little more by avoiding so many conditional statements in the function.

I'm glad I charged ahead with all this though, because I learned a ton doing it. I have a pretty strong background in programming, but only earlier this year got into the audio side of things (my other background being a musician/composer).