Redraw Limiter not quite working

[aliasant]

According to the description of the redraw limiter it should limit trigger to the redraw rate.
That isnt happening.

I started another thread, http://synthmaker.co.uk/forum/viewtopic.php?f=12&t=8851&p=62390#p62390 to see if others could verify or help me understand...

This simple test shows that there is no difference between the non limited 100 tick and the limited one.
The Redraw LImit works in a host. At least it stops trigger from coming thru when the plugin is closed.

Redraw Limiter Tests 1b.osm

(6.7 KiB) Downloaded 88 times

2 other oddities in this test osm are these:

The 100 tick seems to be quite off. I would expect it to be of 10ticks up or down but it seems to be more then that.
The test shows that it takes about 1570 milliseconds for it to count to 100. On my computer that is, but someone else mentioned a similar number.

The last little odd thing in this is the Timer.
Anything under 16ms as Duration input will act as a 10ms but if you use 16 you will see a clear difference.


This seems to mean that our plugins are using way to many triggers and wasting valuable cpu.

And again I want to ask for another timer then the built in windows one.
SM and its offsprings should use the soundcards clock for timing
Anything else is madness.

[rl]

And again I want to ask for another timer then the built in windows one.

In my opinion this should be the #1 feature of the next SM version.

With that shaky current timer It's not even possible to build a halfway solid arpegiator.

[infuzion]

And again I want to ask for another timer then the built in windows one.

In my opinion this should be the #1 feature of the next SM version. With that shaky current timer It's not even possible to build a halfway solid arpegiator.

Sounds like we're back into the MIDI timer request again...

[malc]

You're right of course. For accurate timing it's the only way and the timers we have at the moment were never intended for this purpose. The timing inaccuracies are just the nature of the Windows timer mechanism and we can't do anything to change them.

The request for sample accurate timing via a different mechanism is long standing, I do appreciate that. Hopefully we can resolve this in 2010.

The Redraw Limiter issue I replied about on the other thread. The Redraw Limiter only kicks in during automation, MIDI CC or preset changes. Also when the window is closed in a host. Outside of such events it does exactly what you're seeing...ie nothing at all

[aliasant]

You're right of course. For accurate timing it's the only way and the timers we have at the moment were never intended for this purpose. The timing inaccuracies are just the nature of the Windows timer mechanism and we can't do anything to change them.

The request for sample accurate timing via a different mechanism is long standing, I do appreciate that. Hopefully we can resolve this in 2010.

The Redraw Limiter issue I replied about on the other thread. The Redraw Limiter only kicks in during automation, MIDI CC or preset changes. Also when the window is closed in a host. Outside of such events it does exactly what you're seeing...ie nothing at all

Thanx for the clarification Malc
The triggers seems to be fairly ok up to about 50/sec but then it gets worse the higher we go. Windows sux... some times... a lot ..

I know I and others have been screaming about using the clock on the soundcard for this and to be honest I dont really know how but using a sample accurate counter and take triggers from that? Maybe built into the SM engine so we only need that one counter and code to get accurate triggers? Then it nees to be baked into the exe/vst of course but this is your job Wel. Damnit. All of this is your job. Just playing with ideas. It shouldnt be so hard or?

[MegaHurtz]

I think it`s a bit of a paradox to want accurate green timing.
It`s always off by it`s resolution in comparrison to actual time.
My guess is it would always require secondary data to go along with it,
at the speeds given it`s yust more data.
Maybe a function call setting at clock speeds would cut the bill ?.

[malc]

Jorge has had the accurate timing thought through for some time now so we know how to do it. The problem has been that to introduce it fully was always going to need a complete overhaul of the software. By "fully", I mean a complete new events system for all the triggered data, including MIDI (basically everything but the audio code).

Whilst it would be great to have the full package, the main thing accurate timing is needed for is sequencers and such like. Introducing this system to handle just MIDI is much more achievable and can be done without the need for a re-write.

[aliasant]

Jorge has had the accurate timing thought through for some time now so we know how to do it. The problem has been that to introduce it fully was always going to need a complete overhaul of the software. By "fully", I mean a complete new events system for all the triggered data, including MIDI (basically everything but the audio code).

Whilst it would be great to have the full package, the main thing accurate timing is needed for is sequencers and such like. Introducing this system to handle just MIDI is much more achievable and can be done without the need for a re-write.

Sounds like the way to go maybe?

[MegaHurtz]

These things do require a rewrite of the entire program

[MegaHurtz]

If you`d be able to dump array`s.. say as a list or pcm.
You could use an array together with a ramp. in an all green environment.
Maybe even utilise an object to request data from the conventional wave output`s.
So that you can use the current syntax to declare an output for the array.

[Tzarls]

Malc, is it possible to generate green triggers from the stream world? I mean, instead of doing some major surgery to install a new event system, couldn´t you just begin by creating a primitive that receives streams and sends green triggers? Me and some guys requested this kind of solution for the timing issues, and I really think that, if it is possible to do such a thing, then it would allow for some nice and interesting stuff while we wait for the major overhaul.

[trogluddite]

is it possible to generate green triggers from the stream world?

Second that - even just a simple streambool to trigger on true/false transitions would have a thousand and one uses

[infuzion]

Malc, is it possible to generate green triggers from the stream world? I mean, instead of doing some major surgery to install a new event system, couldn´t you just begin by creating a primitive that receives streams and sends green triggers?

I guess one could figure out a way to send a float value every _x_ samples, but I still don't think it will be sample-accurate. The green system seems to use a heart-beat, just like Adobe Flash uses "frames" & Max/MSP uses packets. So even if the Stream to Float could have a value ready every 1000 samples, the green system might not be ready on the 1000th sample to pick it up. (I hope I'm not misrepresenting SM Malc?)

I do like the idea of auto-sending a value every 500+ samples though (which can be used for triggers, better meters, etc). It will eat CPU if your not careful, but I like the idea better than having to use a Trigger + Mono To Float.

[malc]

@Tzarls:

That is possible yes. In fact that's pretty much how the events system works. So yes you could go as far as generating the event but then convert it to a trigger for use with the current system instead of introducing a new system where the events flow from component to component. This way you would get the timing aspect of the new system at least.

As infuzion points out you'd have to be careful not to do too much processing or cpu will be compromised. Might be better for us to pass the trigger across threads so that the audio thread can continue while the trigger flurry processes.

[rl]

Maybe this article could be helpful: http://msdn.microsoft.com/en-us/magazine/cc163996.aspx .
(Creating an accurate timer is a major headache on windows)

When deriving triggers from stream processing, bear in mind that the VST hosts does the sample processing _before_ the buffer will be sent to the soundcard. E.g. when generating a midi event from that trigger audio and midi might be not in sync (dependent on the soundcard's latency)