Problem with SynthMaker plugins and automation/pitchbend (fixed)

[JCJR]

If it just ain't working AT ALL then I don't see how the following idea would help, but have you tried putting a sleep(0) call after every buffer render? To give the plugin a chance at any threads it spawned or messages it may have sent to itself?

If it worked at all, but badly, I'd maybe think about trying very small render buffers to see if that made the behavior less granular.

Apologies for likely-dumb ideas you likely already thunk up.

[sagamusix]

That's basically what my "slow render" option does.

[anosci]

I could suggest that it might not be the de-zipper?

........oh.

oh!

ok, so what had happened was...I was copy and pasting all of the knobs from a tutorial synth, and that synth used a custom built de-zipper module --which included a timer.

[nix808]

OK,
It is that then. Glad u can fix ur plug!

Saga- if you want to render these cludgy plugs correctly u need to keep the tick thread open.
I guess we had already sussed that, it seems plain now. Since you are doing a slower than realtime render, it will actually work better than playback. If you want to tread this path- get the old ticker specifications from Outsim/DSP Robotics, and see what device it actually is. We have always just called it the Windows timer. I will ask at the forum, will stay out of RDSP's hair, but for sure they wouldn't mind a mail Saga.

I'm happy that it is possible to get a good render, and some solutions are available to the SM devs after clarifying.

[JCJR]

It isn't important, but I'm curious if this "slow render" mode is indeed slower than realtime. I am not being critical in any way, merely curious.

My optional "slow render" feature I added some years ago, which is rarely necessary with the synths that the customers use (I only say that because if the "slow render" mode was frequently necessary then I would have been inundated with numerous complaints)-- My slow render mode wasn't necessarily slower than real time. It was just slower than "as fast as possible", allowing the user the option to hopefully fine-tune the delay variables in order to slow it down "just enough" to avoid dropped notes, without renders becoming tediously long. Five minutes for a five minute song would be painful.

I was assuming that sagamusix's slow render is about the same-- not necessarily slower than real time. Perhaps assuming wrong.

My typical user might not use lots of pitch bends and controllers, and may not be "adventurous" in acquiring numerous synth plugins. That may be why, as far as I know, we haven't had numerous complaints about pitch bend rendering defects.

[sagamusix]

OpenMPT's "slow render" is slower than realtime - for every processed block, it does a Sleep(20) (and blocks are much smaller than 20msec ). As said before, this was introduced in the days when people were using Kontakt with DFD and slow hard drives, and OpenMPT probably didn't notify the plugin that it's rendering offine, so it was forced to render so slow that Kontakt wouldn't drop notes due to slow hard drive access time.
Regarding the "tick thread", I'm not quite sure what that is supposed to be. The only real difference between rendering and normal playback in OpenMPT is that rendering happens in the GUI thread and not a separate audio thread. So I'm not quite sure how I could change anything there to satisfy that SynthMaker module.

[JCJR]

Thanks segamusix

The "windows timer" puzzle--

There are several timer mechanisms and I'm routinely ignorant, but this one might be the "windows timer"--

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

And then there is the multimedia timer.

Just thinking out loud-- I think the multimedia timer always fires thru a callback, and do not understand how something your program is doing (or not doing) could block that.

The "windows timer" can either use a callback, or send (what the documentation describes as low priority) windows message WM_TIMER.

Dunno if the callback mode could stall if message queue processing is stalled. I'd assumed not, but who knows?

If the plugin is setting up a timer to receive a WM_TIMER message to its window, wonder if that would depend on whether your program's message queue handler is operational and passing on the messages to the window? Been a long time since studying the windows message dispatching. Just thinking out loud.

[sagamusix]

I've previously also considered that these plugins might be using WM_TIMER. OpenMPT does this while the export is running.

Code: Select all

if (::PeekMessage(&msg, m_hWnd, 0, 0, PM_REMOVE))
{
::TranslateMessage(&msg);
::DispatchMessage(&msg);
}

This should ensure that window messages arrive somewhere. Apparently they don't arrive at the plugins, though?

Also, it's saga, not sega

[sagamusix]

So, to give this thread a happy ending and potentially help other host developers: In the meantime this problem happily fixed itself without me even noticing - I guess it might work now because the "if" statement in my previous post got replaced by a "while" statement to actually dispatch the whole queue. Now OpenMPT's behaviour is identical to Reaper's (i.e. plugin automation still sounds bad during faster-than-realtime export, but not quite as bad as before).