VSTFX: La Ride

[lalalandsynth]

I would definitely do this with asm , I will look and see if I have something suitable.

[wlangfor@uoguelph.ca]

Thanks fellas, yes i had been wondering about the ticks. And I will create a custom schematic with something that loads samples after a tick and give it a per 100 count basis so that We can test these ticks as well.

I'm just wondering how far they're off.

And BTW, I was doing some testing and Here is the track I was able to come up with using this plugin as it satnds so far (the last version did not have primary sound driver appointed lol)

I would definitely do this with asm , I will look and see if I have something suitable.

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.

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]

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]

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

Yes , I had just performed My own as well. I'd utilized the acrobat mini synth, set on and off to the same tick, then set a tick to go off every 100 times. However, I was able to get this version working which is fast enough, however the speed has a variance.

And I'm not sure if variance is ok. I can set it so the number is infinite. here's the schematic (now free of tick 100's and up to speed. Albeit different speed between realtime and render, but still fast "enough")

it's the equivelant of a tick1000 realtime, so it would be roughly a tick100. But roughly is the word:


[newest version on last post]

[wlangfor@uoguelph.ca]

And BTW, after doing some testing. My new methods gets beyond 100 ticks. But it`s erratic. I can change the way in which it speeds up and slows down but it will merely take some testing.

I also wanted to do some testing with the playing prim boolean in tandem with editor open. I want to see if those are still detected when the file is being outputted faster than realtime.

Obviously, If I can use these I can bring the speed down to My ultimate goal so that I can try to match the speed on output.But it will take a lot of going back and forth, furthermore I will have to test using all sample rates. But that's all good, hopefully I can make a logarithm or percentile with which that process can be streamlined.

I'm happy that this project has come so far, but like I had mentioned to lalaland; 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.

It's simply be a matter of multiplying by 0.01 or something like that, and then changing the degree in percentile based upon the faster than realtime sample rate and position of sample in the track. When you really think about it; It's elementary school level. Kind of surprising.

Anyways, I was realizing that something like an ASM to dB would be difficult, if not impossible without ticks and I figured I'd had to find something extraordinary to solve My dilemma. I'd investigated the ppq prim, which seemd to have great promise. I was actually able to make a perfect match with the timing - But it would be FL Studio dependent, and the timing of it still is reliant on the pulse per quarter setting found within the project's general settings.

So, I mean while it seemed like there were solutions there really weren't. but on the other hand; If I can get this new system up to par, it'd be really useful for synths especially. Ticks can be very handy to use.

[trogluddite]

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]

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.)

Yes, true. I was curious, Does Your slide run at the correct time even when rendering?



Because I've decided to write an asm/code version of the mean averaging and then conversion to linear db so as to use a mono multiplier. But that obviously belies My ability to make this output soft gain. Would the time from this slide be My respite. And if not; Does anyone know anything about the track sample position prim? I could use that if I knew anything about it.

I'll do some research because in the way of using ASM / code it would obviously have a great advantage in the manner of timing exactly what You wish to achieve.

But, I mean realtime isn't so bad. Thanks to bot Trog and Lala for getting me onboard this brave new well timed world. Sigh, I liked the idea of slide prims but they're too inaccurate; they'd probably sound nice though.

[lalalandsynth]

[trogluddite]

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.

[wlangfor@uoguelph.ca]

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.

Hmm, excellent. Well then it might be possible to use Your slide almost like an envelope in release then. Thanks. It's a good example.