Re: VSTFX: La Ride
Posted: Wed May 29, 2019 6:03 pm
I would definitely do this with asm , I will look and see if I have something suitable.
DSP Robotics and FlowStone Graphical Programming Software Support and Forums
http://www.dsprobotics.com/support/
http://www.dsprobotics.com/support/viewtopic.php?f=3&t=18239
lalalandsynth wrote:I would definitely do this with asm , I will look and see if I have something suitable.
trogluddite wrote:wlangfor@uoguelph.ca wrote:I'd merely assumed that it would speed up. But now... How do I test if that's true?
This was worked out many years ago, in the days of the ancient SM guru's who are no longer part of our little club. The tickers have been part of SynthMaker/FlowStone right from the beginning. In fact, in a way, they're even older than that...
The limitations of tickers arise because they are actually a (very old) component of Windows. All FlowStone does is to request the time interval and set them running, and Windows then calls back to FlowStone when each tick is due. Unfortunately for us, Windows timers have a fundamental limitation; 10ms between ticks is the shortest interval that is allowed. This is why Tick100 is the fastest one that we have. Even the general purpose Timer primitive works the same way; so duration values less than 10ms will be rounded up. There is nothing that FlowStone can do to make them go any faster, as Windows simply won't let them.
Windows timers also have a relatively low CPU priority, so the duration of a tick can be longer than requested if the CPU is very busy with other things. So when you're running a busy mix, a Tick100 might run substantially slower than 100Hz and with lots of jitter.
To confirm this, what you could do is set up a simple synth, then have a Ticker connected to a MIDI Note primitive to produce a very short pulse from the synth each time the Ticker ticks. Export this as a VST, and plonk it into your sequencer. Then, assuming your DAW allows it, do both a real-time render and an offline (faster than real-time) render, and compare the two. You should see that the pulses are further apart in the offline render than in the real-time one.wlangfor@uoguelph.ca wrote:I think there's a blue linear db someone made with dsp code I could use I guess. Maybe it'd require asm.
I'm pretty sure that someone did make an ASM optimised version of this years ago - I'll have a rummage when I get back to my Windows PC to see if I can find it.
lalalandsynth wrote:I have done a few tests with schems driven by ticks , suffice to say that it was wayyyy off for me when doing faster then realtime renders. But by all means do a test , I am curious as to the specifics
wlangfor@uoguelph.ca wrote:I was rather surprized about the math surrounding the ticks. Given the fact that there are current sample location prims utilizing stream, one would assume that math at its most basic level could be utilized to make a scalable tick.
trogluddite wrote:wlangfor@uoguelph.ca wrote:I was rather surprized about the math surrounding the ticks. Given the fact that there are current sample location prims utilizing stream, one would assume that math at its most basic level could be utilized to make a scalable tick.
Indeed. And, in fact, FlowStone already has an example of such a system - when audio is running, the event timers for Ruby do work this way, and so they have more accurate timing (though with the downside of Ruby's slower processing speed.)
wlangfor@uoguelph.ca wrote:I was curious, Does Your slide run at the correct time even when rendering?
trogluddite wrote:wlangfor@uoguelph.ca wrote:I was curious, Does Your slide run at the correct time even when rendering?
Yes: anything which is entirely mono/mono4/poly audio streams or driven by sequenced MIDI from the VST host will render correctly, even "hopped" code/ASM.