Slide Module

trogluddite · 3 Jul 2012

willzz32 wrote: It seems that the system is slowing to deal with the data

Yes, that is exactly right. All of the 'Green' primitives that deal with timing 'sub-contract' their workload to the timers built into Windows, and with a relatively low thread priority. The 'Tick' and 'Timer' modules also work in this way. This has several consequences... - The time durations are never accurate. - They get less accurate, and usually longer, as the CPU load increases. - Because they are not truly native to SM, there is not a lot we can do to improve 'Green' timing.

Also, the way that 'Green' triggers work puts limits on how fast they can process things. All 'Green' (and GUI etc.) parts sit there doing nothing until a trigger wakes them up and makes them process some data. For stuff that happens slowly, this is cool, because no CPU is used when the data is static. However, if there is a lot of data, it takes up quite a lot of CPU to keep track of all the triggers that are flying about - especially if it means re-drawing controls on the user interface. This ultimately limits the speed that 'Green' data can be processed (for example, even on my big quad-core PC, a 'Tick100' rarely manages more than 60 ticks per second).

So optimising the plugin to reduce CPU load will help a bit... ...in isolation. Once you have your plugin inside a VST host, alongside many other plugins, audio tracks etc., the load from those will also affect the timers. Incoming MIDI events are generally processed with pretty accurate timing, and I have seen this used as a workaround - using another plugin or MIDI track to send timing pulses. But that is also far from ideal, as it can be a pain to set up.

Truly accurate timing is only possible using streams, code and/or assembly - as these are all sync'ed to the audio sample rate. If you are using the 'Slider' output to control any kind of audio signal, using streams instead will also work more smoothly, without needing any de-zipping etc. You can still create displays etc. by reading values from the stream using an 'M2F - the timing of such reads will also be rather jittery - but at least the overall timing of the 'slope' will remain accurate.

I have such a module knocking about in one of my old projects somewhere - I'll pop back and post it up later when I'm back home at my music machine.

willzz32 · 3 Jul 2012

Hi trogluddite

Thanks for the in-depth answer to my question. Is it possible to create a timer/slide from an oscillator .

Eg :- Use a sine wave that outputs a trigger when the value goes above x (x= 0.9) trig and then use this to trigger a counter that will output when it reaches a set value( x= 50 trig) then an external trigger that sets counter to the start . I f this were possible could this be more accurate as the sine wave is working from the sample rate reference and not green timings.

Hope this makes sense and thanks for the help.

trogluddite · 3 Jul 2012

Hi again,

willzz32 wrote: Is it possible to create a timer/slide from an oscillator

The trouble is that the only way to read the oscillator value is by using an 'M2F' primitive (to convert stream to green) - and the M2F needs a trigger to tell it when to grab the value. So at the very moment that the trigger happens, you will receive the correct oscillator value for that moment in time - but you still can't make those 'snapshots' happen with precise timing. Depending on the application this can still be a useful technique though - for example for a low resolution MIDI 'LFO' that needs to stay in sync with the VST tempo. The exact timing of output values will always 'jitter', but at least there is no long-term drifting of the value itself. Sadly, this issue has always been one of SM's fundamental limitations - many people have attempted a better system, and it is probably the update most often requested by SM users. (if you search the forum for 'Green Timing' you'll see what I mean!)

Anyhow - here are the modules that I promised I'd dig out for you...

..two versions - one slows the rate at which values can change; the other sets a precise length of time to reach a new value (the notes and tooltips should explain that better). Although the inputs are stream type, they'll work perfectly fine with a float input - and there is a choice of stream or float outputs (the float output uses the 'jittery' snapshot method like your suggestion above). Note that even if used only with floats, you must have an active audio output to make them work - the code and assembly boxes won't run otherwise.

Hop they are some help - if not, give us an idea what it is you are trying to achieve with your plugin - that might help us to find a more suitable solution.

willzz32 · 3 Jul 2012

Hi trogluddite

Thats brilliant, The help is really welcome . Ill check the module now. I am looking at building a standalone controller for some video software. Its a bit like a lighting board.

Cheers

cyto · 6 Jul 2012

This may be an even simpler solution...

-cyto

trogluddite · 6 Jul 2012

Ah yes, good spot Cyto. 🙂 Using the de-zipper behaves identically to the 'Time Based Slider' from my post (the 'Slew Rate' works differently - it will reach the target faster for smaller input changes). After scratching my head for a while, I remembered why it was that I wrote my own 'Slider' code - it was because I had a plugin that needed the 'time' input to be a stream. In fact, unless a stream 'time' input really is needed (rare!), using a dezipper uses much less CPU, and would be much more appropriate in most circumstances. So I was completely wasting my time when I added the green time calculations to my module to 'tidy it up' for posting - what a fool! 😊

willzz32 · 6 Jul 2012

Thanks all for the input.

Trying it now.