Hi all,
I’m making a lullaby patch that stops playing after a certain amount of time, designated by the user. That all works nicely but I’m wondering, is there is a module that can access the function to close the VCV Rack application? That way my computer could go to sleep once the patch finishes playing.
It’s certainly feasible to make such a module (it just needs to find the main window and call it’s close()). I don’t know of one offhand. I can imagine a module that offers a knob to set a timeout, an input to trigger the timer to start, and a trigger input/button to close the app.
Yeah that’s what I was thinking, or that I could send a trigger from DanT’s Timelord to the Close function input.
It may be a while before I update pachde1, but this would be fun to add, especially if there are other interesting scenarios to cover. I’m interested in the oddball but useful or even useless but funny functions (a crash Rack trigger, a reboot your computer trigger …).
There once was a “Feed the Cat” module (from JW), if you did not feed it fast enough it started to remove cables from your patch. Andrew B was not pleased and asked for it to be removed.
EDIT : it’s still there but it leaves your cables alone.
What, no Tamogochi? I forget what decade those were popular…
Seriously, though. At some point I’ll be looking for some unfilled corners to address.
Mine is still alive and kicking 
The main window is already in APP. Here’s what the quit menu does.
menu->addChild(createMenuItem("Quit", RACK_MOD_CTRL_NAME "+Q", []() {
APP->window->close();
}));
So yeah super easy API. Adding a module which calls that on a trigger is super easy I agree! Just one of us has to do it I guess!
There you go. You can press that button exactly once!
Release Nightly · baconpaul/BaconPlugs · GitHub there’s the nightly with the module (called “PleaseQuit”) in it.
I submitted it to the library also.
Oh and if you save a patch with a high gate attached to that input, you will have a hard time re-opening it. I ignore the first quarter second or so of triggers but you know. Beware. Turns out this is fine.
It might be worth putting some startup code such that it ignores any high gate on startup (the startup gate would have to go low before it recognizes the transition to high)
Yeah I just put in a timeout but that’s a good idea. First upswing not first high.
Does the schmidt trigger let you do that?
Yeah - I was thinking a Schmitt trigger would do the trick if you initialize it to high at the start.
Reading the Schmidt Trigger code it seems to do that already by initializing to uninit.
Yeah it does. The timeout handles ‘process before hookup’ and the schmidt trigger does the right thing.
So saving with a high gate is actually fine.
Amazing work, that really didn’t take long!
The only reason it took more than 10 minutes was my first version would restart if connected with a gate! Anyway enjoy!
