Win10 help, please!

[k brown]

Bloody he**!

I noticed a microphone icon in the bottom bar, so I clicked on it. Pop up said Flowstone is accessing my microphone, and gave me option of turning it off. After doing so, now I get these popups before a schem opens, then there's no sound.

Getting this with 3.0.6 and FS4.

I can't for the life of me figure out to get that window back to turn the mic back on.

I know, I know I should be using ASIO, but every single schem I've ever made has the DS prim in it; if I can't fix this I'd have to replace it with the ASIO every time I went to work on one.

DSERR.jpg (8.01 KiB) Viewed 20490 times

DS2.jpg (15.12 KiB) Viewed 20490 times

And I'm not running any apps using ASIO! Why does it think I am?

[tulamide]

Go to start menu, settings, select privacy (lock icon).

On that page select microphone on the left. On the microphone page, makes sure, all microphone options for accessing are on. The first is a general access on this device, the other is "allow desktop apps to access your microphone". Underneath that option, you will see a list of apps currently allowed to access the microphone. Flowstone might already be among them, but it needs allowance first.

[k brown]

Yep, that did it - thanks tons!

Any idea why that needs to be on for Direct Sound to function?

[deraudrl]

Any idea why that needs to be on for Direct Sound to function?

Wonder if it's related to something I saw/heard shortly after installing FS. Initially, I was getting horrible noise from FS: turns out it doesn't like an open mic input. Had to plug in a cheap earbud/mic widget from an old phone. This was on my previous desktop computer, haven't tested to see if it's still required but the laptop never had that issue.

[Duckett]

I'm still on Win 7, but good to know about the mic input/DS thing. I use DS almost always, simply because in order to have a relatively flat response from my headphones, I've had Sonarworks Reference, which by its nature cannot use ASIO. Honestly, I ended up here from forum-crawling; one of the process issues I seem to have is:

"new schematic works fine, add a bunch of stuff, works fine, add some more stuff- audio prim auto-disconnects (OH NO, I'VE GONE TOO FAR), revert/delete recent changes, audio prim still auto-disconnects after a slightly longer pause, prowl through .fsm to find any bad values/connections- but- unless the audio prim is connected, there's no processing, so cannot find the culprit, and increasing frustration as to why backstepping does not eliminate the issue".

While I'm pondering things I should've learned the answers to a long time ago: the "triggers per sec." stat, like the CPU gauge, is useful- yet, I'll watch it rise and fall while hovering over any individual green node in the fsm will show zero triggers being sent. I may only be known for never releasing anything and asking RTFM questions, but since this is a program designed to appeal to those who prefer pictures to code, maybe I'm a good idiot for the idiot-proofing process... I'll ask the questions Real Programmers are too knowledgeable to even think of!

PS Yes, there's the Discord, but methinks my dumbness is not an FS4-specific form of dumbness.

Thanks for tolerating me all this time- sorry your foreheads are probably callused from smacking them so often...

[k brown]

Yes, I too have never been clear on how to keep unnecessary triggers to a minimum.

My big Synclavier-inspired project I'm now working on will probably need to have that done.

[tulamide]

Regarding the question: Don't take the suggestion as a fact! What happens is the following. To protect you from malicious programs, that could take over the mic for invading privacy purposes, the system asks you for every program that wants to access the mic, if it should be allowed. You say yes, and that's it. But, to notify you of mic access, everytime an icon is displayed on the taskbar (which after some time switches to the hidden symbols tab). This is a protection measure. At any time, you can click the icon to prevent access. Which you did. From now on, when an app tries to utilize the mic, it gets an error code from the system. It's a generic code, and instead of showing you the code, Flowstone tries "to help", by assuming things and suggesting possible help. This message was created by Jorge, long before any microphone privacy settings in the OS existed. Today, such a message would read different. From the description, it should also have become clear, that this ia a protection that works without exception. No different to ASIO. Or any other driver you might want to use. You have to allow access once.

Regarding triggers: One trap, a lot of people fall into, is in using pre-made modules without adaptation. For example, there are quite some modules using the ticker25 or similar prim. But each of those prims create a new timer ticking. The better way would be to have one global ticker25 prim, wirelessly connected to all those modules that make use of it.

[k brown]

Good to know.

What sorts of modules are likely to contain those tickers? Step LFOs I'd imagine - what else?

[tulamide]

Good to know.

What sorts of modules are likely to contain those tickers? Step LFOs I'd imagine - what else?

Hard to tell. You have to inspect each module you use. Usual suspects are prims that grab parts of a signal on a green trigger (for example, MonoToFloat, MonoToGraph, etc.). That is often combined with a ticker to auto-grab them. But basically every prim that accepts a green trigger could be combined with a ticker prim.

[Duckett]

Yes, looking for duplicate tickers is a good suggestion. Still don't know what causes an auto-disconnect of the audio prim (that isn't recoverable by reversion).. sometimes when things get intensive and sluggish, there'll be longish pauses interspersed with bursts of sound, almost as if several buffers' worth of audio was all trying to crowd in the same space... sometimes it seems like the aspects of FS code that's hardest to modernize are the GUI/file/toolbox stuff.. FS still likes to turn the mouse invisible sometimes, is extremely sluggish in letting the file dialog box sort by any other way than filename (Explorer can take its sweet time already with populating large drives; 1997-era slow, I don't need).
A recent discovery was that the toolbox zoom, at its minimum, will get rid of its thumbnails, and only list by text name- until I do some long-overdue toolbox housekeeping, it's one way to speed up loading and searching.

I have read through enough of the manual (and forum, lol) to understand why a gazillion triggers is bad- but, even after reading through some older discussions and fiddling around with knobs, green counters (ramps), etc. I'm still not really sure what the best practices are for trigger management/trigger blockers. Then again, it was a surprise for me to realize that, with multiple inputs to a single input, the order of connection matters- my initial assumption was that FS was agnostic that way, and simply summed the inputs.

"stream= fast, green= slow"- this much I also know, when it come to data types and speeds. A key insight for me may be having to re-think my love affair with the step lfo; it does seem to require the most coaxing to play nicely with the other children. Well, off to figure out what obvious thing I've overlooked this time (it's almost always a PEBKAC issue in my case, isn't it?)...

PS Where's K-9 when you need a very smart tin dog around, anyway?
(For a Gen Xer like me, Tom Baker IS Doctor Who, and always will be. Jelly baby?)