Hello All
Just wondering if it is possible to control the duration (on screen) of an individual WaveShape?, if so what code would need to be added to the WaveShape's config.
Regards BTT
Control of WaveShape Duration
Moderators: BTT, andy55, b.dwall, juxtiphi
as far as I know,
... works for Particle invocations only, otherwise normal WaveShape duration is handled globally. You could probably simulate it using scripting, but at the loss of automatic randomness... which at times, doesn't seem all that random anyways 
As a side note (read: totally different subject
), I have bad mouthed Sprite startup as being somewhat of a resource hog. I have been playing around with Qualitative Software [ QSoft ] RamDrive (free until 2011Apr01) and moving my Sprite Library to it (upon EVERY reboot) and setting GF to use an the external folder. It certainly has helped THAT situation, BUT at the same time manifested in timing glitches showing up at other instances.
I am hypothesising (only) that GF may be making some assumptions about the hardware environment, and may not totally be accounting for dynamic power saving elements like 'throttling', 'core parking', and 'turbo boost'. Throttling and Core Parking can be disabled, but 'turbo boost' only works on some limited subset of the total number of core (at the expense of the other resource threads). Rather than for GF automatically trying to feel out the environment, it would probably be beneficial (read: insightful) to have resource parameters available to set upon startup.
just my .02
Code: Select all
PDur="Seconds"
As a side note (read: totally different subject
), I have bad mouthed Sprite startup as being somewhat of a resource hog. I have been playing around with Qualitative Software [ QSoft ] RamDrive (free until 2011Apr01) and moving my Sprite Library to it (upon EVERY reboot) and setting GF to use an the external folder. It certainly has helped THAT situation, BUT at the same time manifested in timing glitches showing up at other instances.I am hypothesising (only) that GF may be making some assumptions about the hardware environment, and may not totally be accounting for dynamic power saving elements like 'throttling', 'core parking', and 'turbo boost'. Throttling and Core Parking can be disabled, but 'turbo boost' only works on some limited subset of the total number of core (at the expense of the other resource threads). Rather than for GF automatically trying to feel out the environment, it would probably be beneficial (read: insightful) to have resource parameters available to set upon startup.
just my .02