DSP Robotics Support

I do ... but still trying to figure this out.

I think I can confirm that EdOPEN does NOT send a trigger ... so that is the issue I need to solve.

Somehow, I need to send a single trigger only if EdOP is TRUE ... and importantly ... only the very first time the VST gets loaded/opened in the DAW. It's like a one-time status to check if TRUE, do a trigger. After that, any open/closes are ignored ... till the next time the session is load. Then again, a one-time status check ... trigger if TRUE.

kind of a tricky situation

There are the boolean to true and boolean to false prims. They send a trigger only when the status changes (to true or to false). Combine that with a variable that's set to 1 after the change was done and only react if boolean to true triggers AND the variable is still 0.

Hi T .... that's exactly the PRIMs I've been trying to integrate.

I've not yet found the 'secret' solution and I've tried some crazy ideas to boot

so far, the only progress has happened through a bit of RUBY code.

Basically monitoring the EdOP status, if TRUE, output a 'tick'.

I do get 2 triggers on the RUBY output ... really, I only want one.

Not sure if this is a solid idea to pursue, but its the first 'experiment' that actually gave a trigger

If so ... how to knock this down to a single trigger ?

Try this one. It worked for me in Reaper.

(EDIT: Your above code is wrong. It needs to have a check for equality, which is "==" not "=". The latter is an assignment.)

Hi T,

ok ... I will test the code you posted. In particular, I'm looking at the GUI link you included into RUBY.

I'll compare to the code I'm current at:

This 'works' in the FS editor, giving me a single trigger. However, as with all things, I need to test this as a VST export into a DAW to see what happens.

Onto the real world.

Scary

ok ... 1st test results.

My design and 'T's design both trigger as an exported VST .... HOWEVER ...

MY miserable design FAILS in that everytime the VST is opened .... it triggers the TIMER. Booooooo.

Conclusion .... The GURUS once again come to the rescue, saving this miserable wretch from even further abuse of that last remaining brain cell.

Quoting from the Black Knight of Monte Python ... 'Onward to further conquests.'

I'm not sure He actually said that ... but ya gotta admire his gumption.

note:
For those playing along at home, and wondering, WHY the heck do I need this function.

Well ... either I'm trying to put out 'self inflicted' fires of my programs design logic ... or its something else. But what I'm dealing with is interaction of PRESETs within a DAW.

My VST plugin works in conjunction with a variable list of 3rd party plugins within the chainer PlogueBIDULE. These BIDULE plugins are basically 'samplers', and it takes time for their sample libraries to load. All parameters of these samplers are controlled via my VST, therefore, I've needed to wait for all samples to load BEFORE activating my VST's MIDI controls.

Prior to this 'new solution' attempt, I've been using a User defined Delayed TIMER that can be user customized [based on sample library size, and CPU system speed/power, etc].

My HOPE is that I can find a better, or more automatic solution ... such as this new design that 'T' has outlined.

Now that the 1st test is done ... we now move to the true proving grounds. Testing with actual session loadings.

[Have FlowStone .... now ... dangerous]

OK ... Real World testing is going well ... happy to report

From the looks of it, I think I can significantly reduce the 'User defined delay' significantly. More important, it cuts down on the guess work of how many seconds delay are needed. And, BIDULE seems happy letting the 8 samplers [VSTs in this test] load their respective Preset library.

Test need to continue ... but so far so good !

Thanks for helping me make improvements