If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Primitive EdOPEN not working as expected
18 posts
• Page 2 of 2 • 1, 2
Re: Primitive EdOPEN not working as expected
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
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
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: Primitive EdOPEN not working as expected
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.
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: Primitive EdOPEN not working as expected
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
I've not yet found the 'secret' solution and I've tried some crazy ideas to boot
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: Primitive EdOPEN not working as expected
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 ?
- Code: Select all
if @status = true
output 0 #,@tick
end
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 ?
Last edited by RJHollins on Sat Mar 26, 2016 7:36 pm, edited 1 time in total.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: Primitive EdOPEN not working as expected
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.)
(EDIT: Your above code is wrong. It needs to have a check for equality, which is "==" not "=". The latter is an assignment.)
- Attachments
-
- EdOpen Test.fsm
- (646 Bytes) Downloaded 875 times
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: Primitive EdOPEN not working as expected
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 ... 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:
- Code: Select all
def init
@status = false
end
if @status == true
output 0 #,@tick
output 1, true
end
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
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: Primitive EdOPEN not working as expected
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]
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]
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: Primitive EdOPEN not working as expected
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
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
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
18 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 52 guests