DanT: Time Lord

Plugins & Modules
1

Here is the next new module I am developing, which you can try out in the DanTModules v2.4.40_beta01 release:

Time Lord

This module is designed to generate time based events over long periods, to make the control of evolving patch elements easier.

image
image1523Ă—1049 167 KB

The top-centre readout is the time elapsed, in my testing this seems to be fairly accurate, but I am not guaranteeing this module will stay in sync with other modules or time keeping devices/software external to VCV Rack. (The accuracy may also be slightly dependant on the sample rate you have VCV set to).

To the left is the run/stop button with CV input (trigger toggle) and a running gate and stop trigger output.

To the right is the reset button with CV input (trigger) and a reset trigger output.

The rest of the panel contains 6 identical event rows that consist of:

  • The event number
  • enable/disable CV input (trigger toggle)
  • enable/disable button
  • repeat/oneshot button (lit is repeat)
  • Event Start knobs for hours, minutes and seconds
  • Event Start trigger output
  • Event length knobs for hours, minutes and seconds (00:00:00 means infinite length)
  • Event End trigger output
  • Event gate output
  • Inverse Event Gate output

There are a few additional options in the context menu:

  • Reset on Stop - automatically triggers reset when the the state changes from running to stopped
  • Reset at Time Limit - When active, the reset will be triggered at the time limit and the module will continue running, when not active the module will stop when the time limit is reached
  • Set Limit - sliders to set when the Time Limit should be (note that the milliseconds will not be exact, it is dependant on the sample time)
  • Reset to Enabled Snapshot - If this option is active, when the reset is triggered, the enabled/disabled state of each event will be set according to their state when the last snapshot was made, the default snapshot is all events disabled
  • Save Enabled Snapshot - Overwrites the snapshot to the current state
  • Set Time - Allows you to set the module to a specific time, this is mainly for testing, I have tried to ensure that the state of the events will be accurately updated, but this is an area that I haven’t fully tested yet

If you have an event set to repeat, it should re-trigger at multiples of the Event Start time. If the length is either 00:00:00 or greater than the Start time, then the event gate will remain high until a reset.

Although it is possible to use this module as a Clock with a repeating event, currently I have not tagged it as "Clock generator", rather I am using "Sequencer" & "Utility". Should I reconsider this?

I hope you enjoy the new module, please do let me know if you find any bugs or have any suggestions for improvements.

:timer_clock: :robot:

17 Likes
2

Nice concept.

I have a couple suggestions (wishes):

  1. Independent fade in and fade out knobs for the gate outputs. It could be global, which takes much less space. But if you can squeeze in knobs for each event row, that would be the ultimate.

  2. It is likely that the timed events will typically not sync properly with the clock that is driving the patch. You can use something like the Sickozell bToggler modules, where your event arms the event that is delayed until the start of the next clock event. But it might be nice to incorporate that functionality into your module. The Sickozell modules use the same clock for start and stop. I’m not sure if there is any advantage to providing for independent start/stop clocks. There might also be benefit for allowing different sync clocks for the different events. Either of those enhancements could benefit from normalled inputs.

1 Like
3

Looks really useful for my needs!

I’d put it under clock generator though.

3 Likes
4

Request:
Optionally in measures.beats
( In 4/4, there are four beats in each measure, and each beat corresponds to a quarter note.)

(maybe even measures.beats.samples)

2 Likes
5

Uh, oh! Now you need a “conductor track” to let the time signature change, right?

6

I was originally intending to implement something like this, but my issue was how to specify the slew length; maybe something simple like 0% to 50% in and out, but what if you want it to fully slew in and then just stop normally?

So you kinda do need two knobs and for them to be explicit lengths, but then I’d need to think about how to handle a situation where the total slew is longer than the event length and a bunch of other edge cases…

So, for now, I have just bypassed this issue by not adding this feature, and personally I would just use a separate slew module, Bogaudio Slew is my go to, although it can’t do massive slews, but it does have the exp/log control, which is nice.

I may still add this feature, just need to think abit deeper about it, possibly an expander…

To be totally honest, I didn’t design this module to be used with a clock, hence why I didn’t tag it as such. That is not to say don’t use a clock in your patch, but rather, I am not trying to make this sync with any sort of beat or rhythm.

I created this for my more generative and ambient patches, where typically I want slowly evolving changes. Such a patch may use a clock (for ratchets and other effects) but it is a peripheral element, and I wouldn’t use it to effect changes over time.

One of the most common ways I currently use Time Lord, is to control mixer channels or VCAs with the gates (and of course this is why a slew of the gates is useful).

For me, it is a sort of anti pattern to try to use time to control patch changes if you want them “on beat”, it would be much easier to do that using a clock counter. Especially if the beat is not regular, or you like to change the BPM.

If there is demand for some sort of beat counting module, that can perform similar tasks to this, or if I have my own need for such a module, then I just may well create that too. But I think I am unlikely to add any sort of beat or clock sync to Time Lord, sorry.

3 Likes
7

I totally get that. I too often want to bring in/out voices after some amount of time, having nothing to do with the main clock. But it can also be good to say, start voice 2 at the first beat 1 that occurs 5 minutes after the piece starts. For really ambient pieces the timing typically doesn’t matter, but if there is a rhythmic component, the timing might matter. Combining your module with one of the bTogglers definitely gets the job done. It just seems like a natural fit to combine with yours. If you are familiar with what bToggler does, and don’t want that feature, well that is just fine - your module is still very useful. But if you are not familiar with it, then I encourage you to explore what it does a bit before you write off the feature entirely.

I was thinking all along it would be specific fade times to go from 0% to 100%, or 100% to 0%. I was thinking up to 30 seconds - unlikely that it would be longer than the event length. But if it is, then simply begin the fade out at the current level. So if the event is 15 seconds long, and both fade in and out are 30 seconds long, then at event stop the fade in will be at 50% (assuming linear). It should then take 15 seconds to fade out from 50% to 0%. Obviously that is a simple case, but the math should not be hard regardless.

But just as with the bToggler armed clocked event concept, this certainly can be done with an additional module. So I can see how you might not want to do it. It would just be a convenience.

1 Like
8

I will give it a go, I can see how it might be useful so I might change my mind if I make some patches with it. Probably as an expander, that just feels nicer to me as it keeps the original module vision intact.

Hmmm, this doesn’t feel right to me, an actual event can be up to 24 hours long, ok most people wont use events that long, but personally I would want to maybe make events that are an hour and if the slew was a feature I would want to be able to have the entire event either slew in or out, or some combination, say fade in for 30 mins and fade out for 1 minute…

Also, if I add the slews in an expander, then probably i would want to have CV inputs, so then i’d need to test all the edge cases where the slews are being modulated as the event length knobs are being twiddled…

Still need to think about it a bit more… (I do have the Bogaudio src as reference though, so I might just implement the same algo)… I can see this happening at some point

9

Ahhh - we are thinking of two different things.

I am thinking of fading in or out so that a voice entrance or exit is not jarring. No need in my mind for the fade to last the length of the event. For my use case I want the fade and event times to be totally independent.

10

That’s what unit tests are for.

11

@dan.tilley Time Lord is great. I wish there was a slimmer version with an option to choose between just minutes or seconds, and excluding the gate/inverse gate outputs. I likely won’t ever need the hourly option.

So, maybe Time Baron? :slight_smile:

Also, it’s nice to have time keeper for patches.

1 Like
12

One very slight issue I’ve found is that the last three zeroes span outside of the time field when zoomed out at a certain point. gergggeegg

13

Hmm that’s strange, i tested that extensively to make sure it didn’t do that, can you let me know what OS and the exact zoom level please, so i can try to reproduce it, thanks.

14

Windows 10, 119% zoomed in.

15

egregrergergergr

Another tiiiiiiny issue is the somewhat jagged edges on the knobs when using the park panel.

17

OK, so I can definitely see that the font scales at a different rate to the graphics, but it must be dependant on the screen resolution and window size.

I am windows 11 and 3440 x 1440 my 119% looks like this

image
image1144Ă—1027 285 KB

The worst view I can get is 114%

image
image1159Ă—1009 285 KB

I don’t think there is anything I can do about the different scaling of the font, so I will just have to increase the size of the black background box.

Again I think this is resolution dependant and I can only reproduce this at full zoom, but I can see some artefacts, so I will try to improve that graphic…

image
image1034Ă—602 53.1 KB

18

I’m using 1920x1080 on Win 10.

Again, it’s absolutely nothing major, just what caught my eye.

19

There can be subtle artifacts if your SVGs aren’t using whole pixel coordinates (e.g. when using mm, or positioning at fractional pixels).

20

Actually the jagged edges were caused by the png background metal texture, I was using NanoVG to crop this image to the knob circle.

I have fixed this by moving the crop to the png so that it has transparent edges around the texture

image

image

image

3 Likes
21

Just a quick note to say, I found some bugs with the Set Time and Time Limit functions where the times were not accurate (due to some improper handling of float <-> double <-> int types), these are now fixed locally and will be part of the next Beta and release…

As a result of the bug fix the time limit must now be set by clicking in the context menu rather than simply changing the sliders, and now works the same as the Set Time function

image
image617Ă—652 45.3 KB