Re: Win10 help, please!
Posted: Wed Aug 30, 2023 1:23 pm((( triggers ))) triggers me... 
Managing triggers propagating through green schematics became quite a prio in my newbie plugin... to prevent trigger storms. The "Flowstone crashing" type of trigger storm
I usually stop triggers in their tracks as close to the source as possible. If I need a particular trigger further down the line, I usually end up routing that trigger separately.
Yes... I use tickers for my LFO's. Not for Step LFO, but for disconnecting mono and poly but still having them exchange values. Where I wasn't able to connect them directly... Due to ASM/DSP's synchronous nature causing issues I think. Maybe I'll be able to do without my MacGyver solution for this in the future... when I learn and understand a bit more how FS executes ASM/DSP
You're killing me!
I've had my suspicions but when you drop a bomb like this I figured the tickers were just variants of the same output... passed from same source based of system clock 
Well... seems I have to go through my schematics
regarding this
My current assumption is that they are the same speed, or well... poly/mono is of course executed faster since it's ASM. Ruby (and greens) in contrary is a high level language execution (using own threads), but they are all still code. Poly/Mono is however the most prioritized since they have to fill the audiobuffert at realtime, otherwise any audio breaks up. I guess. But, I expect tulamide or other FS-ninjas to correct any flaws in my logic surrounding this
Deeper down regarding any memory handling and execution stack that Maik might have written/employed... that's way beyond even trying to wrap my pea brain around.
Managing triggers propagating through green schematics became quite a prio in my newbie plugin... to prevent trigger storms. The "Flowstone crashing" type of trigger storm
I usually stop triggers in their tracks as close to the source as possible. If I need a particular trigger further down the line, I usually end up routing that trigger separately.
k brown wrote:Good to know.
What sorts of modules are likely to contain those tickers? Step LFOs I'd imagine - what else?
Yes... I use tickers for my LFO's. Not for Step LFO, but for disconnecting mono and poly but still having them exchange values. Where I wasn't able to connect them directly... Due to ASM/DSP's synchronous nature causing issues I think. Maybe I'll be able to do without my MacGyver solution for this in the future... when I learn and understand a bit more how FS executes ASM/DSP
tulamide wrote:But each of those prims create a new timer ticking.
You're killing me!
I've had my suspicions but when you drop a bomb like this
I figured the tickers were just variants of the same output... passed from same source based of system clock Well... seems I have to go through my schematicsregarding this
Duckett wrote:"stream= fast, green= slow"- this much I also know, when it come to data types and speeds.
My current assumption is that they are the same speed, or well... poly/mono is of course executed faster since it's ASM. Ruby (and greens) in contrary is a high level language execution (using own threads), but they are all still code. Poly/Mono is however the most prioritized since they have to fill the audiobuffert at realtime, otherwise any audio breaks up. I guess. But, I expect tulamide or other FS-ninjas to correct any flaws in my logic surrounding this
Deeper down regarding any memory handling and execution stack that Maik might have written/employed... that's way beyond even trying to wrap my pea brain around.