Problem with SynthMaker plugins and automation/pitchbend (fixed)

[sagamusix]

I (or rather the users of my software, OpenMPT) am having problems with some plugins behaving dodgy, and it seems to boil down to them being SynthMaker plugins. The problem definitely doesn't exist with all SynthMaker plugins and it differs between the plugins that I've tried, but maybe someone has encountered this problem before and can shed some light on what's happening here?

The symptoms are: All plugins process parameter automation and MIDI pitch bend messages as expected when playing some song file that uses these plugins. However, When using my WAV renderer, automation and / or pitch bend stops working, depending on the plugin. I cannot really see any difference between realtime playback and WAV rendering, except that WAV rendering happens in the GUI thread and not a separate audio thread - but this shouldn't matter if the GUI isn't doing anything at this point anyway, right?

So the plugins that show problems are:
SynthSchool Odyssey - automation + pitch bend not working during rendering
NES VST 1.1 - automation works, pitch bend doesn't
AM Freehand - automation + pitch bend not working. (note: The free version doesn't appear to support pitch bends anyway, but I also tested the full version).

I was in contact with the Freehand author at some point but he couldn't help me either, so it's probably a problem deep down in SynthMaker. Does anyone here have an idea what the problem could be?

[nix808]

It may be to with the green timing system in Flowstone/SM.
SM uses the windows timers for graphics,
if devs have used a windows timer to trigger audio events,
this will work in playback, but not rendering.
I would try rendering the plugs in Reaper,
and see if the result is the same as with your host.
If they do not render properly in Reaper,
it is an issue specific to the plug devs-
and it's not your problem.
Cheers

[RunBeerRun]

No idea about pitch bend not rendering, but many Synthmaker synths did not have it at all, even something that basic raised the CPU.

[sagamusix]

No idea about pitch bend not rendering, but many Synthmaker synths did not have it at all, even something that basic raised the CPU.

As said before, the plugins behave as expected in realtime mode, i.e. pitch bend does work.

However, nix808 might be onto something - I created a project in Reaper using the Odyssey VSTi, and while it *does* apply pitch bend and automation on the rendered WAV file, it only happens in very... coarse steps. I created a smooth envelope, but in the WAV file, I only get irregular steps that last a fraction of a second.

It doesn't quite explain why it still doesn't work in our own "slower than realtime" export mode, but I guess it's really a plugin issue then.

[nix808]

hmm,
I will do some tests on my own plugs,
I have been using the environment since 2005.
If I can get rendering automation and pitch bend flawless,
I can advise the devs u r testing.

For a workaround-
use a plugin audio recorder like IL Edison on the master
during playback.

I suspect it has something to do with the interaction of 'stream',
which does render flawless-
and the green pins(float,int etc.)
The green stuff doesn't run at samplerate.

[sagamusix]

hmm,
I will do some tests on my own plugs,
I have been using the environment since 2005.
If I can get rendering automation and pitch bend flawless,
I can advise the devs u r testing.

That would be apprciated!

For a workaround-
use a plugin audio recorder like IL Edison on the master
during playback.

Yup, that's what I've written into my FAQ about dodgy plugins as well.

[JCJR]

Maybe this is inapplicable, but in the past I had troubles rendering some synths to disk, though they would playback fine in my program. It was a very rare problem.

When rendering to disk, I would follow the exact same track reading, plugin calling, mixer topology as in playback, with the only difference being that I would run the process "as fast as it would go". Crank a buffer's worth of audio thru the entire shebang, write it to disk, then immediately crank another buffer's worth of audio thru the whole shebang, as fast as possible until done.

It seems to make sense, because who wants to wait for a render-to-disk to take LONGER than the required minimum?

So one synth plugin would have occasional dropouts on render, and especially dropouts after program changes.

I believe the plugin did two things which made it incompatible with "as fast as possible" rendering. Now an ordinary complicated synth plugin that eats lots of CPU cycles would render flawlessly no matter how long it takes, as long as the buffer is completely finished when the plugin returns from its render call.

But this plugin was streaming samples from disk, and I'm guessing it was also doing some of its rendering in threads it spawned. So when receiving a program change, apparently it would render what it could "immediately" supply, and spawn a thread or other process to load all the "note starts" from disk for the new program. Called "as fast as possible", the new note starts would not be loaded from disk and so it would play silent for many bars of rendering until the disk load could catch up and put the samples into memory. And similarly, I think some of the ordinary note-playing relied on threads, and the threads were not keeping up with the "fast as possible" rendering, so the plugin was just returning occasional empty buffers.

I solved it by adding a user-selectable feature to "slow down" the rendering, to add a certain amount of idle time between render cycles, and a certain amount of idle time after program changes.

Just saying, if you are rendering "as fast as possible", you could try adding some idle time between render buffer cycles, to see if that allows the misbehaving plugins to do their job better.

Also, do you call VSTIdle routinely while you are rendering to disk?

I'm very ignorant of this topic, as with most topics, so maybe the advice is useless.

[sagamusix]

I solved it by adding a user-selectable feature to "slow down" the rendering, to add a certain amount of idle time between render cycles, and a certain amount of idle time after program changes.

Yeah, we have that too, though that is still from the old times of Kontakt 2 - I think back then our host didn't properly report that it it would render offline (through audioMasterGetCurrentProcessLevel), so Kontakt was dropping DFD samples because it couldn't keep up. I think most (properly implemented) DFD synths would usually query the process level and just take as much time as they need during rendering. However, as mentioned before, extra slow rendering (slower than realtime) doesn't change anything here, and these plugins are not streaming samples.

Also, do you call VSTIdle routinely while you are rendering to disk?

Good idea, but unfortunately I already tried this and it didn't help either...

[nix808]

I tried for about 2 hours today to look at this problem.

Your tracker is cool, but I'm happy with my composer, Orion.
I can't be bothered for now learning how to use it.
Anyway my VSTi opens in it.
I'm no Reaper afficiando either-
it actually looks like on default, it does render steps of automation when drawing automations, I guess I could record it, but I'd have to learn that too.
So reaper actually uses some 125ms steps anyway.
If someone knows how to draw automation properly in Reaper,
we would appreciate the test- to see if stepped on a straight spline.

I have however tried automating pitch bend and filter cut in Orion.
I used a straight line upwards, so stepping would have been audible.
This plugin renders these automations correctly in Orion,
I didn't have to change anything->
http://www.sendspace.com/pro/dl/j67w53

Does this one work in OpenMPT?
It is possible for a host to render it correctly, as I say it works in Orion.

If works, we can investigate why, if not- I'm open for dialog to fix it.

edit-updated link with current revision

[sagamusix]

Good news - Entrancer works as expected in OpenMPT.
I've created some test cases in both Reaper and OpenMPT, for those who want to try - they all use smooth parameter automation and some pitchbend events. To register the plugins in OpenMPT, simply drag the plugin DLLs on the main window or add them through the plugin manager.
test cases

[nix808]

Good stuff!
Yeah, I got the GUI to open,
just failed to sequence it.
I will have another go on a rainy day.
Nice work there.

If any of the devs wants to talk to me about the 2 issues,
I can try and modify their schematics,
or send code snippets. Maybe your users could try and organize that,
if they are keen on the SM plugs.

I haven't done anything that I am sure is different from them.
They need to implement these 2 things properly:
1. Here is pitch bend->

2. It is crucial to name the preset parameters correctly, all must have a unique name, and have 'store in presets' and 'enable automation' set to true with a bool.

The devs need to test and make sure it works.

Cheers, Nick 8D

Oh yeah- I found the spline automation lanes in Reaper

edit- another thing that may differ is which version they are compiled in-
I am using the current Flowstone: Raindrop

Hmm, I recommend a testing session on these partially functioning plugs.
There is no reason to use a windows timer(tick) on the audio really. However,
if you need to, generate it with Ruby, and it will render AFAIK.
I have built a MIDI sequencer that renders with Ruby codeboxes

[sagamusix]

Just for the fun of it, I tried hooking GetTickCount and timeGetTime, but it seems like neither is called by the plugin, at least during rendering. That Odyssey plugin imports some other time functions, though (e.g. timeSetEvent from WinMM), so if it uses some more fancy Windows timing mechanism, tricking the plugin through custom hooks will probably not work. Oh well, it was worth a try.

[anosci]

(or rather the users of my software, OpenMPT)

that's me! hi!

by chance I was making my very own first ever plugin using flowstone, just as this thread was started...and I encountered exactly this problem.

after a lot of digging around and rearranging and testing everything....

I suspect it has something to do with the interaction of 'stream',
which does render flawless-
and the green pins(float,int etc.)
The green stuff doesn't run at samplerate.

..you are correct!

specifically, the de-zipper module seems to be the problem.

I'm....not sure what to do about that, but it's not super critical to the operations of my synth, so routing around it works sufficiently for now.

any advice for alternatives?

[sagamusix]

Right now I'm a bit undecided whether it would be okay to keep OpenMPT's obviously completely broken sounding behaviour (no automation at all) or if I should try to find out what other disk renderers (e.g. Reaper) do differently so that they can at least do very coarse (depending on the render speed) automation steps. In the latter case, it might not be apparent to the user that something doesn't sound as intended. And I'm still not sure what the difference between my and Reaper's implementation is, since calling effIdle and effEditIdle didn't motivate the plugins enough to update their timers.

[nix808]

Hi 8D
Welcome to Flowstone, it's more fun than Sudoku IMO !

I could suggest that it might not be the de-zipper?
If you look at the image of the pitch bend implementation,
it has a de-zipper.
However if your 100% sure with your tests-
there are other ways to de-zip,
essentially you need a low pass filter with low values for cut and res.
This works as a de-zip->
http://www.sendspace.com/pro/dl/t68daz
I just checked and I have a dezip on the link between filter cut and the filter too, which is the parameter I have been using to test. It has been working correctly.

I'm not sure what to do with the rendering to keep the timers going,
something must change in the environment the plug is running in when rendering.
The timer is not really fancy- it is max 100hz and may not even send the event,
I'm not sure where the documentation for it is on the web, had a quick google but didn't turn it up. If you can keep the timer threads open, I think it will work rendering the same as playback coz u r slower than realtime.

However- the best thing is to get the plug devs to look at rendering automation and pitchbend, as it is their plugs which are broken, not your rendering mechanism. With what I thinks happening around these 100 and 25 hz timers, they have 2 options- do it with stream(sample accurate), or if they need to do a data type conversion, do it with Ruby(higher frequency and precision anyway).