RUBY Counter - this was suppose to be easy :|

[Spogg]

Hi RJ

I checked this out in Reaper 32 bit on Win 7 and it seems to work fine. Saved the project, reloaded it and the counter value was maintained.

I really like the idea of automatically saving a variable using the preset manager system. Simple but very effective.

I can't imagine what else you plan for this, since it seems to do all you desired!

However, if this is to be used in a commercial way, to time an engineer's work, I would suggest a code should be entered before the reset button works. But if it's just for personal use that wouldn't be necessary.

Well done!

Spogg

[RJHollins]

Hi Spogg.

Hey man, thanks for checking it out.

No plan to do commercial for it, but I do have an addition or two I might add in.

1. One thing thinking ... a TIMESTAMP displayed for the start of the project. I think I had put a routine together
that would only trigger one time.

Open to other ideas.

I wanted to avoid having a user [me] fiddle to much with picking directories to save/recall from. Often times, I start
a project and after some time do the first save into a dedicated folder. Starting that just for this PlayTime monitor
would be a hassle.

The RESET button was an idea I put in. I'm not really sure why beside the obvious reset to zero.

What do you mean by CODE before the RESET button. I'm interested in what you thinking.

2. There is an issue saw happen ... I need to verify.

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 ?

The PreSet Manager. I still haven't found where that data is storing [gotta be somewhere]. But yeah ... I think I was
following one of your threads with this idea [or somebody who was storing large data in the Manager].

To that ... the best of my understanding [questionable], the Manager can handle data lengths of up to 255 characters.
For my data, that would be SECONDS that would extend that many places. I've not calculated just how many seconds
I can actually store this way. Guess I should get a figure on that.

The COOL part. I've now dropped this plugin into several commercial projects I'm currently mastering. Having a clock
for JUST the amount of time I'm actually playing a track has been quite interesting. When I don't have a client in
session with me, I like to work for a time on one track, then move to another ... kinda bounce around. Keeps me
from getting use to a track. I get to hear them in a 1st impression more times in a sense.

One thing I've still got to try.

If I have an album laid out as ITEMS on a single track ... will this TIMER work ONLY on the ITEM I'm working on [basically
a PlayTimer in each ITEM. I got to test that. That would be very nice. If so ... guess I could have one on the master bus
too and get the overall project playtime. This could be wishful thinking, as I'm using the PLAY prim to start/stop
the timer. It may be that all plugin react together ... I don't know.

I'm just glad I got something working. I'm also very surprised that no one has written this type of plugin specific to this.
Believe me, I looked. There was a whole REAPER thread of people asking about something like this. Actually, to build
it into Reaper ... or for one of the 'scripters' to do it. One guy posted a running clock, as did HOFA release a similar.

That is what so cool of FS.

anyway ... wrapping up for the evening. Any ideas, suggestions, bug reports, are always welcomed. As is the appreciation
from the Members who help !

thanks again.

[Spogg]

What do you mean by CODE before the RESET button. I'm interested in what you thinking.
- You click the reset button then you have to enter a secret verification string. You don’t need this but somebody might!

The Preset Manager. I still haven't found where that data is storing [gotta be somewhere].
-Your song project will save the VST state, in the project file. When you reload the song, any settings made will be restored. That’s the really clever bit about your solution.

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.

The best of my understanding [questionable], the Manager can handle data lengths of up to 255 characters.
- Your time preset value is stored as a String I see. That’s where the 255 limit is but you will surely never reach that…?

I'm using the PLAY prim to start/stop
the timer. It may be that all plugin react together ... I don't know.
- Yeah, it’s either the DAW is playing or not, AFAIK.

Cheers

Spogg

[tulamide]

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.

This actually is not a Reaper decision, it's Flowstone, or better said the system. Since it doesn't make sense to update graphics that nobody will see, the processor time is saved and used for other tasks. Unfortunately there's only a "VST Editor Open" prim, which tells you if the plugin window within the host is opened or closed. I couldn't find anything that tells us, wether our plugin window is in foreground.

[RJHollins]

Spogg , T

Thanks to both of you for the replies and information. Very helpful.

As to PreSetManager. This is the first time I've used it this way. [different than the 'normal' knob, button we've used].
This opens a nice option

EDOPEN prim. I saw that one. Even parked it inside the schematic. Was hoping I could re-trigger a [REDRAW] or
GUI update with it. I've not gotten that to work, unfortunately.

The other idea was to use the EDOPEN to trigger on momentary TRUE->false on the play STATUS trigger ... but man,
that was getting tricky. If the DAW was playing or not, that type of updating messed things up.

I know if I open the GUI, and just hit PLAY for a moment, the display is corrected. But that's a lame solution. Gotta
figure a better way.

The RESET button is a little bit of concern. Accidentally hitting that ... not good. I should probably add a confirmation
Message box to that.

Another possible idea to add: Allowing the display time to be Edited/Changed.

But the first thing ... put a DATE stamp into the display, marking the start of the project.

NOW A QUESTION to the EXPERTS.

If I need to add more data to the PreSet Manager. I want to avoid messing up the data from previously saved projects.
We're talking having a 'reserved pool' of preset entities. They'd all be blank [un-used], but available for any new
assignment. Again, without messing up earlier projects.

How best to do this? if possible.

thanks

[DaveyBoy]

tulamide wrote:

save state / load state are convenient methods for RubyEdits to maintain their status automatically while working on the schematic. So, when saving the schematic, save state is executed, and when loading a schematic, load state is executed.

It has nothing to do with an exported plugin or app. The only way to save data between sessions of those is to write them to disc.

I wasn't aware of that. All my projects so far are schematics, I haven't tried exporting yet.

Thanks for the detailed explanation tulamide ...... you learn something new every day as they say!

[RJHollins]

A couple updates going in.

1. I've added a 'message box' to the RESET routine. Now we have a user confirmation BEFORE resetting to 0.

2. I've added a Time/Date stamp. Lots of looking up on RUBY sites to get a string FORMAT that I wanted to see. Some of the Guys here had already posted some of this stuff. It's how I got the idea to even look for it. It's actually rather straightforward ... IF you know the format codes:

Code: Select all

t=Time.now.strftime("%a %b %d, %Y %l:%M:%S %p")

It even coverts the 24hr clock to civilian 12hr [thank-you very much]

3. Now dealing with the PRESET aspect of the Timestamp. So far, that is NOT going well

I'm trying to re-engineer KG's work from his RUBY Counter code, with the 'elapsed time' re-insert. Unbelievable what a mess I can make of that. [... when I met Spock, he called me 'Kcops - the anti-thesis of logic'. Or maybe he was just calling the cops ... i don't know. ].

I'll have a bit of time later tonite, so I hope to get this part of the PreSet working. I'll also post the latest version here on the board for whomever interested.

Now to some Mastering

[FlowStoner]

Code: Select all

def event (i,v,t)
   case i
   when "runState" # input
      @runState ? tick : clearEvents
   when "set" # input      
      output 0, @count = v  if @count != v
   when "step" # input
   
   when "reset" # input
      messageBox 0, "Reset the job elapsed time?", "Job Elapsed Time", "yesnowarning"   
   end
end

def tick
   @count ||= 0.0
   @step ||= 1.0
   output 0, @count+=@step
   ###
   scheduleMethod "tick", time+@step
end

def messageBoxFinished id, result
   if id==0 && result=="yes"
      @count = 0
      output 0, @count
   end
end

def saveState
   [@count,@runState,@step]
end

def loadState(v)
   @count,@runState,@step=v
   tick if @runState
end

EDIT: added safe set and output only if changed

Code: Select all

if @count != v

EDIT: added the warning message box before reset the job elapsed time

[FlowStoner]

some update in the preview code snippet....

[RJHollins]

Thanks Guys !

ok ... had a bit of time for bug fix and new features.

1. Added option to create the Date/Time stamp to mark a project start.

2. Editable play time counter, should a time need to be modified. [via a toggle multiplex window]

3. Message Boxes added when changes are being asked for [cancel for no change].

4. All in interaction with the PreSet Manager, so all data saved in DAW project file

Been running several sessions to test function/reliability. Good so far. More testing to follow.

Again ... THANKS to the FS GANG.