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
RUBY Counter - this was suppose to be easy :|
36 posts
• Page 4 of 4 • 1, 2, 3, 4
Re: RUBY Counter - this was suppose to be easy :|
Spogg wrote:
[color=#FF0000]Whenever the plugin is NOT in view, the time display does not seem to update. If I display the GUI, and hit PLAY the time jumps to the real value. I'm running this using Reaper64, so the plug is BRIDGED. Do you see this on the 32-bit system?
Yes, exactly the same on my 32 bit setup. Annoying, but it kinda makes sense for Reaper not to update the display on stuff that isn’t seen.
Spogg
Hi Spogg. Maybe you know more about this minor annoyance, and a possible solution.
I'm not sure WHAT causes a GUI to refresh/update [other than being in view]. The only possible PRIMS I see related,
would be the OpenEd prim.
Is there some way we could use this to trigger a onetime redraw when the plugin is brought into view ? If this is a
possibility ... where might this 'trigger' need to aim at in the schematic.
Like you say ... it is only a minor thing, but if I could fix it ... that'd be one less 'minor annoyance' in life.
Really ... this is more an open forum question for any possible technique.
thanks GANG !
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: RUBY Counter - this was suppose to be easy :|
alrighty then ...
Just did a little TEST. It DOES WORK !!!
At the 'current value' point in the schematic, I linked the OpenED prim to a plain Trigger GROUP prim [2 trigger prims
tied together]. This trigger was then connected to the start of the data module.
I wanted to be careful NOT to introduce ANY values into the data Input [true/false, 0,-1,1] that might change the
numerics. I just wanted to send in a TRIGGER when the GUI is being Opened from a Closed state.
I'll test more ... but it is working. Open the GUI and the correct value is displayed without altering the program data.
Trigger control/management. YEAH.
Just did a little TEST. It DOES WORK !!!
At the 'current value' point in the schematic, I linked the OpenED prim to a plain Trigger GROUP prim [2 trigger prims
tied together]. This trigger was then connected to the start of the data module.
I wanted to be careful NOT to introduce ANY values into the data Input [true/false, 0,-1,1] that might change the
numerics. I just wanted to send in a TRIGGER when the GUI is being Opened from a Closed state.
I'll test more ... but it is working. Open the GUI and the correct value is displayed without altering the program data.
Trigger control/management. YEAH.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: RUBY Counter - this was suppose to be easy :|
Interesting discovery.
I was curious how the FS 'PLAY' prim would react on different tracks on a project. Here's a couple things I found.
Using REAPER[64] PC.
1. The PLAYing prim is FALSE when a track is MUTED, and goes TRUE when UN-muted.
2. Having several ITEMS on a track. ONLY the ITEM that is actually being played will set the PLAY prim to TRUE, otherwise it is FALSE.
What this means is that my PlayTime counter will only monitor when a specific TRACK or ITEM is actually being
played. This is actually a better function than I thought was going to happen.
Nice. Might be useful info to others.
I was curious how the FS 'PLAY' prim would react on different tracks on a project. Here's a couple things I found.
Using REAPER[64] PC.
1. The PLAYing prim is FALSE when a track is MUTED, and goes TRUE when UN-muted.
2. Having several ITEMS on a track. ONLY the ITEM that is actually being played will set the PLAY prim to TRUE, otherwise it is FALSE.
What this means is that my PlayTime counter will only monitor when a specific TRACK or ITEM is actually being
played. This is actually a better function than I thought was going to happen.
Nice. Might be useful info to others.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: RUBY Counter - this was suppose to be easy :|
Fascinating!
So have I got this right: If you want to time any play activity on the whole project the track with your timer plugged in would always have to be active and never muted?
Cheers
Spogg
So have I got this right: If you want to time any play activity on the whole project the track with your timer plugged in would always have to be active and never muted?
Cheers
Spogg
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: RUBY Counter - this was suppose to be easy :|
Well ... for timing a whole project ... I just put the PlayTime plugin on the MASTER BUS. The audio paths
in the plugin are just straight wire IN/OUT.
In fact ... I tested having several PlayTime plugins in different places at the same time, tracks, separate ITEMS,
and the Master. Each shows elapsed time when it was active.
in the plugin are just straight wire IN/OUT.
In fact ... I tested having several PlayTime plugins in different places at the same time, tracks, separate ITEMS,
and the Master. Each shows elapsed time when it was active.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: RUBY Counter - this was suppose to be easy :|
Oh I see!
Very flexible then!
Very flexible then!
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
36 posts
• Page 4 of 4 • 1, 2, 3, 4
Who is online
Users browsing this forum: Google [Bot] and 78 guests