Topic: Pianoteq standalone on windows wakes up sleeping display

Hi,

How can I prevent that Pianoteq 6.3 wakes up the monitor when it is turned off after the timeout defined in the windows power saving settings?

I verified that this is a behavior of Pianoteq as standalone and that doesn't happen when Pianoteq is running as vst3 in a vst host nor with kontakt with other software pianos.

Thanks,
Luis

Last edited by lqferreira (11-11-2018 19:35)

Re: Pianoteq standalone on windows wakes up sleeping display

Hi Luis,

sorry if I misunderstand, but it's unclear to me from your question. I'm not sure 'what exactly' it is that wakes your screen - for example, is it just happening randomly when using Pianoteq in standalone mode? OR some other thing which might help understand better - such as "when I hit a note on DP keyboard".

IF your system is set up in a fairly straightforward way, maybe look for something further in:

'Advanced Power Options' via control panel, like:

'Sleep/Allow Wake Timers/Disable' for both Battery and Plugged In. (chance this might do it).

In general, I avoid power settings issues by only running audio applications in high perf mode - no sleep/hibernation, sys or screen. With audio I will always (until a system does this flawlessly) recommend no power saving settings and all maximal power options. (if wanting to be green, use the PC less and head outside more - it's nice out

IF I don't want to see the screen, I leave all my power settings in high performance (for audio purposes) and just set a blank screen saver for say, 15 minutes.

This means, when working in a DAW, we're highly likely to edit something (moving mouse or inputting) within 15 mins and the screen rarely goes down unexpectedly.

IF it does, there's no loss to me - no power glitch etc. Kind of fail safe.

When I just want to play piano and not have a screen glowing in my face, I have one computer away from the keyboard, with a HDMI connected monitor with the DP, with wireless mouse and keyboard on top of DP keyboard.  The screen(s) goes blank after I've decided on a piano/preset and have played for 10 or 15 mins.

Lastly, IF I don't want the big monitor in front of me to bug me at any time, even in the first few seconds of playing Pianoteq, I can physically switch it off (no power hit or glitching). Total control, no power issues.

Just some ideas - hoping some helpful.

Pianoteq Studio Bundle (Pro plus all instruments)  - Kawai MP11 digital piano - Yamaha HS8 monitors

Re: Pianoteq standalone on windows wakes up sleeping display

Qexl, thanks for your detailed and complete answer and practical suggestions!

Please understand that if I don't care about the sound glitch that might happen at the moment  the screen is turned off by power settings, it's not possible to keep the monitor sleeping until I move the mouse or press a key because pianoteq wakes up the monitor as soon as it receives input from the midi keyboard.

In my understanding there should be some way (registry key or configuration in the UI) that controls this behaviour.

How can I ask for this feature to the development team?

Thanks!

Re: Pianoteq standalone on windows wakes up sleeping display

Hey lqferreira,

you can contact support at:

Pianoteq support page

You could try this - I'd be interested if it's your fix:

In Pianoteq settings/general tab, try un-checking the boxes "Highlight pressed keys" and/or "Display chords". Maybe something about these throws messages to wake your video card but in VST mode, these signals are likely depreciated or made more 'nice' or dropped.

In the meantime, some BIOS settings which might be changed:

# "Resume from S3 by USB device" to Disabled. (S3 is typical sleep level - this should kill any usb's ability to wake. You may have separate listings to leave enabled, like "Resume from S3 by keyboard" and same for mouse, which is nice - but not a given).

# "ACPI Suspend type" set to? D3 (or S3?) OR if you've got something else in your system settings via device manager etc.. match this up.

# "PME Event Wake Up" to Disabled.


Hoping these types of settings might provide your fix for this kind of issue.

In a worst case scenario, you may have a Windows mobile-related OS version (esp. if on a made-by-Windows RT device or maybe a mini PC box using a specific version of Win 8 or so) with a thing called "modern standby". These might have a different way of operating sleep functionality - no experience with this sorry to say. Just worth checking - if not then most other suggestions may be relevant.

More info about your rig could rule such things in or out.

Assuming fairly standard Windows/machine combo, in control panel, open "Device Manager", view the listings under "Human Interface Devices" and look for your DPiano keyboard there, right click, choose "Properties". Then in the box that pops up, choose the "Power Management" tab and make sure that you un-check "Allow this device to wake the computer".

If your DPiano keyboard can't be seen, maybe it's folded into a generic looking USB listing - try disabling sleep on each one on the list until you find it. (to do it as timely as poss, you might benefit from noting numbers you see, to be sure you're not just re-enabline and disabling the same one or two) You could otherwise find its device name (number like 00000084) and go into regedit to see what settings are given. Or disable wake on the USB hubs including root hubs also in device manager but listed under USB devices IIRC.

None of this bothers my machine, nor my workflow but always take care to be able to undo things you attempt (adequate notes recommended) - and you may need to reboot Win.

If it's a really rare issue, there might be way more odd ways to fix it - maybe if you still have trouble with this, add some extra info here like:

# version of Win
# OS and version like 'Home'
# PC/laptop brand, model, numbers
# info about sound sys - using onboard or external devices, model names numbers etc.
# DPiano keyboard brand model numbers
# maybe explain your cable and other setup data in some detail (like midi out via modern USB square end, to PC USB rectangle end).


Anyways.. here's some other notes - helpful or otherwise??, YMMV. Reader beware, words..


~~~


You might also try doing this device manager routine for USB hubs (root hubs also maybe) also nearby in device man - see if that works.

I prefer wrapping the machine in a lead blanket and tossing it into an active volcano, leaving for ~60000 years and forgetting about it until I re-emerge as a reasonably sapient sentient being in a sufficiently modernised civilisation as to allow me to track it down and fix it because I always bring along with me, a computer technician named Ralph who just loves antique machines. By this time, the volcano has most likely cooled enough that simple plant equipment will be enough to dig it out for Ralph to have a look. Unfortunately, Ralph chose to solidify her timeline for eternity but since then, has died in another dimension. The brashness of youth! I can always see Ralph again in the future because of this, but it does mean that she can no longer travel back to times before she was born. And other stories..

Probably should have numbered things above better for discerning fact from fiction.. so beginning here with:

3.
Still in Win Control Panel, "Device Manager", look under "Software Devices" for something like:

USB MIDI Interface [0] (Out)
USB MIDI Interface [1] (In)

Right click, choose "Properties" and in "details" tab, scroll "Property" to "Current power state" and view PDCAP_D0_SUPPORTED etc.. should be D3 maybe as well for these.. these bit flags describe capability. D0, D1, D2 & D3 are sleep/wake numbers.. higher ones D4 and D5 may describe deeper sleep (slower to wake etc. more about hibernation routines if I'm not absolutely behind the times).

Anyway, maybe from these numbers, you can interpret whether your DPiano is actually set up to understand your "normal" power settings.. it might turn out that you only see D0, or maybe you only see D5 here? It can tell a story - then you might want to go searching in Regedit for various numbers such as "Physical Device Object Name" (looks like 00000084).

Maybe some users who use Pianoteq in a "headless" config may know of some tricks here (but assume most would be doing this with *nix or i variant).

Knowing your device brand, model number etc. would help best - because, maybe you're using a particular Windows OEM device with a version of "modern standby" (horribly only a re-install OS can change that back to more typical sleep/hibernate functions - if hardware conforms) or some other thing like "Connected Standby" each of which may also have some kind of specific OEM driver setup with no way (or different way) of changing anything from BIOS through to regedit - because they're recent and possibly also now defunct versions of Win and limited to few-ish devices - making all other assumptions wrong-ish. I actually have no experience with such a device, so can't say what changes are available to make - time permitting, it's a thing for research (far down my list atm to be frank).

Maybe it should be said before anything else though (not assigning a number to this), follow that cab! I mean check those drivers! Your DPiano keyboard might have some 'nice' drivers which are friendly (or ignorant) to some system things when your DPiano is plugged in - OR remove those to go back to standard system ones (if any of this applies). Reboot each time.

Note also, although we might set our power settings logically, there can still be strange behaviours (incrementally increasingly mundane reasons explicit to maybe just one application) and it can sometimes feel like we're in a bus without brakes heading down a stupidly narrow dirt mountain track on the edge of a dangerously steep ravine, being driven all too carelessly by a cartoon baboon being attacked by bees whilst avoiding rock falls and landslides - our machines seem broken - nothing we do seems to help until the "aha" moment. Many reg key options exist like you mention.. esp. if you've poked around in there, it's possible to have triggered just such a conflict so would recommend keeping thorough record of what changes you make, in case you need to step back in exact increments (years later esp.).

Failing the above ... a reset to defaults and begin again to tweak power settings.

Or

3.
NOTE this one may become really outdated advice after time of writing (due to V-VVM-sys updates, std V-Origin-Englyph translation mod etc) but I'm amazed we're still seeing this in the wild. For V-Englyph & V-LangTrans enabled readers of the future, welcome. I highly advise noting in which epoch this item was V-BDumped (the Putrescene era of Sol-0), and what V-OS V-emulation blob-hulk is running in which V-Multiversal V-Transmutation pod core and which quasi frequency it is carried to the V-0rb catchment via, whether it is scavenging or dumping (any current standard DPiano midi out data-mix read okay's this when plugged into a Sentient-Vi9er+ V-Skull post version V-48617070792048656C6D6574) and finally to what V-terminal cryptology impact disentanglement vector it is assigned by V-EthaSec before it re-enters the temporal V-plane, oh and whether it's working via simple atomic probe or piggybacking off of one of the natural V-IntraTerrestrial framework infrastructure orbiting nodes around the rim of consciousness of course (Blue or old Pine1nterAscii2 nyuknyuk) and yeah, lastly of course, whether it's meant only for V-Home, BizSkiller or EMPIRE version (should mention some V-VVMWare from certain sectors vary in random scale clustering efficiencies so can cause ZED-Mode Fail-End statements to occur mostly in V-Home installs, even before any [hold - user changing O2 resource allocation - RXNzZW50aWFs - replenishing function digestion - Tk9OLUVzc2VudGlhbA== - return] UStat-Sec-Var verified Uni-V-PrimeCore time flow statement reaches around the V-Wormhole back-through processes (as opposed to through-back) - check logs regularly to iron that out easily by adding an external V-Shoe%26.725n crumb type V-Drain adaptor module with at least one V-Ssslice on the old hole in the wall - works just as expected here in sub orbit c2 world 53617475726E (yeah, maybe that won't work everywhere but seem to remember having this everywhere in the last 17 stages of trans during my NextSol tasks, that's mostly been on a GigaPass level plan in case it matters there) - yeah I like the view here what can I say) - also of note, your V-OS and neuro kit may have pretty buggy handshakes in transit if you're outside the damned Kuiper belt (yeah, little known but still they haven't solved that one, in this day and age! Ptah - thinking of moving out to Makemake after a while because of this - lots of contracts). If you're outside this solar system, sorry I can't give more help without inflicting VLOSS on my HumCred line - unless you pass some XCred via the LossLess bit farm on our 6th moon here, you know the one Ping QWNjb3VudE5hbWVBbmROdW1iZXI= for the tip.

Back to our timeframe - Registry changes I tend to avoid (until last resort) and don't like advising anyone what to do in there unless I know exectly what's happening on your system. You could check in here (or your sys equivalent or near equiv) but I strictly do not say it will work and don't recommend anyone making changes without adequate research:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\User\PowerSchemes

You might see below, "(Default)" and "ActivePowerScheme". Maybe your default is blank - it doesn't seem to matter but maybe you could look into doing something like 'modify' default by copying in the ActivePowerScheme value data. I can't honestly say this would/should work - but it's a small poss.

Reboot for any such change (in this day and age, again ptah).

There may be some code/call looking to read that default data and returning a blank - then waking the monitor because "Hey, the default is not defined". In all seriousness, a million such things are possible depending on what's been altered or added to the system and some installs and drivers have very different requirements. Pianoteq itself is one of the 'nice'-est programs so unless the fix is #1 above, I can't see it being at issue in reg etc (though possible).


4.
USB selective suspend settings - change disabled to enable (or reverse - reboot - do again). Keep digging for example in 'Device Manager' for advanced USB and other power check-box logic and illogic. If none of this works, I'll have a more thorough trawl into reg keys for you.

I've... gone for lunch, returned and liked what I wrote so decided not to edit anything out ;0)

5.
Is your midi going from your DP into your PC (or outboard audio box) via a USB cable? (USB at both ends - was a driver installed for this by system or via your DPiano's supplied software disc or download?) If you have mixed USB ports (USB USB2 - and look for port(s) with a symbol like lightning etc) maybe plugging into a different USB port could fix it. I have some specific slots I use over and again because, when I change them, it just can send some system processes into pearl clutching panic.. "Oh no, user has moved a device from one slot to another - better run WMI Provider Host" at 99% for ten minutes! Or system can alert "unrecognised USB device". Avoid. (it was worse in ye olden days, in fairness - editing multiple text files, balancing variables like IRQ ahh ahh ahh, rebooting and re-rebooting which took 20 minutes per time etc - or before that, having to sit at a real piano with a wax cylinder and a bull-horn pointed in your direction - make one mistake and have to reboot, I mean, re-melt the wax, reset it and start again, a whole 4 hours at a time etc - so yesteryear OMG).

6.
Consider a different midi cable, the OLD type (Chews on corn cob pipe - "Kids these days - yuknuchnmph" eye-roll etc). For some reason, the newer USB cable type is unusable on my otherwise supposedly normal machine after a system update years ago (gives different problems - my fixes are now redundant - quite forgettable audio related USB issues between 8 and 8.1) but now when I use a standard Midi cable out from the keyboard to a USB converter (~$15) into PC USB, it's basic and flawless (and less latency). This seems to bypass unnecessarily tetchy junk-laden layers of abstraction in system - so may be a fix for your issue too. After all, midi signals are light and fast and should be direct - no current need to have that signal wrapped in a blanket of proprietary kludge (maybe a good reason exists of which I am unaware, but certainly do not require that right now - eg. with a particular feature set in an outboard audio device etc - but irrelevant today).

7.
Or carry an interesting mix of aged animal sacrifices (for examples, goat, pigeon and marmoset would suffice) backwards to the closest volcano, to arrive exactly at dawn on winter solstice, face East and ... build the animals a comfortable shelter with plenty of water and food for them to live out their days as if in an hilarious post modern sit-com (please don't skimp or this won't work, cheapskates!), click your ruby slippers whilst whistling the theme tune from your most despised TV series. Now jump into the volcano. This should return the system to default settings (or if it doesn't, apart from Schrödinger, who cares am I right?) but depending on the way you lived your life, everything else might also be fixed along with the USB issue (lights! choir!) Jury is out on all this, as it's completely made up as I type and the least recommended piece of advice I've probably ever given.

8.
If you don't believe in the afterlife, reincarnation or other, and you have higher levels of respect for your own life as it is, disregard #7 and focus on being a better human being. This will help regardless.

9.
If however you don't believe in being a better human being, you can safely disregard #8 but I would recommend giving #7 more thought haha

10.
A nice cup of tea. Ah. Hmm.

11.
As is solid tradition (as arbitrarily defined at whim or whenever I dern'd well thank it's time to add this here rule which was made famous by Monty Python all those years ago, m'kay), there is no rule #6, I mean #11 in this case.

12.
Fix your screen sleep issue with this one simple trick! Click NOW for more! Blinky banners!

Heh does seem I've run out of real ideas - anyway hoping something at top works - and hoping to hear from those who might have successfully dealt with this issue.

All the best for now, lqferreira.

Pianoteq Studio Bundle (Pro plus all instruments)  - Kawai MP11 digital piano - Yamaha HS8 monitors

Re: Pianoteq standalone on windows wakes up sleeping display

I am having similar problem with OP. I am using Windows 10 Home 64 bit on a laptop. I set the screen sleep after few minutes. However it never sleep when I was using Pianoteq standalone with usb wired keyboard. I guess the signal from USB disturb the sleeping process. Maybe it is the Problem from Windows, I am not sure, though.

Re: Pianoteq standalone on windows wakes up sleeping display

Hi Snowpine,

I'd love it if there was a single fix we could all do for this - let us know if you find a cure that works on your machine.

Is that USB (square end) out from DPiano keyboard into PC USB (rectangle end?).

IF Yes, then consider:

Qexl wrote:

plugging into a different USB port could fix it

Qexl wrote:

Consider a different midi cable, the OLD type

Maybe your DPkeyboard has old style midi outs - get an adapter to USB for like $15 - works for me. Something about this 'seems' to bypass 'something' which doesn't 'hook' into sleep/suspend routines.

I'd be interested to know if you've tried any of the things listed above?

The ones I'm probably most interested in would be:

Qexl wrote:

BIOS settings which might be changed:

# "Resume from S3 by USB device" to Disabled. (S3 is typical sleep level - this should kill any usb's ability to wake. You may have separate listings to leave enabled, like "Resume from S3 by keyboard" and same for mouse, which is nice - but not a given).

# "ACPI Suspend type" set to? D3 (or S3?) OR if you've got something else in your system settings via device manager etc.. match this up.

# "PME Event Wake Up" to Disabled.

Just to be as helpful as possible, I'd suggest taking time to try a few things like that - and some other things like:

Qexl wrote:

USB selective suspend settings - change disabled to enable (or reverse - reboot - do again). Keep digging for example in 'Device Manager' for advanced USB and other power check-box logic and illogic.

(disregard of course the paragraphs of bad comedy routines which sometimes help like therapy for coping with Win settings).

Like mentioned also above, your PC details and OS (there are differences for touch-screens manufactured under Windows banner like RT devices etc. which will be different - you may have to rule that out before taking the generic advice above.).

Sleep and suspend has been a great idea but a nightmare to get right. Linux machines (maybe Macs too?) seem WAY better at this, than Windows to this day. My Win PC is ok but it takes digging like all that info above and hair pulling sometimes to get rid of what should be so simple.

Good luck - maybe post some more info if none of the above works.

Pianoteq Studio Bundle (Pro plus all instruments)  - Kawai MP11 digital piano - Yamaha HS8 monitors

Re: Pianoteq standalone on windows wakes up sleeping display

First of all, thank you Qexl for your very detailed help.
I tried almost every methods I could think of including your advice.
Unfortunately, all the methods failed, so I contacted Pianoteq support.

Suprisingly, preventing the display from falling asleep was a feature of Pianoteq ifself.
And the feature was the user request.

They say that in the upcoming update, this feature could be optional.
So, now I feel fine and will wait for update.

Re: Pianoteq standalone on windows wakes up sleeping display

Ah interesting, thanks Snowpine. Great to know!

Pianoteq Studio Bundle (Pro plus all instruments)  - Kawai MP11 digital piano - Yamaha HS8 monitors

Re: Pianoteq standalone on windows wakes up sleeping display

lqferreira wrote:

How can I prevent that Pianoteq 6.3 wakes up the monitor when it is turned off after the timeout defined in the windows power saving settings?

A command-line option has been added for this in Pianoteq 6.4, it is '--do-not-block-screensaver'