After some more thought, maybe the Duration property for an Activator is
not the best way to deal with the issue.
Maybe the Duration property should be on the Keyer element. That way
some of the complications go away, and multiple concurrent attempts to
activate an unreleased keyer could simply be ignored.
Lynn
-----------------------------------------------------
Lynn Walls wrote:
> A few technical questions come to mind when the "Duration" concept for
> an Activator is contemplated: Like, what if an activator gets triggered
> WHILE it is waiting in its "duration" period? Would you ignore the
> attempted activation? Or would you stack it, and perform the activation
> AFTER the currently waiting instance ends? Or would you run multiple
> instances of the same activator concurrently in real time?
>
> Ignoring could be bad if the activator is keying a "toggle". The toggle
> might be missed and the state of the toggle would be opposite of what
> was expected.
>
> Stacking could be bad, especially if the "Duration" was more than a few
> milliseconds because sounds that might be keyed by the activator would
> come much later than expected -- not good when playing music.
>
> Multiple, overlapping concurrent activation of the same activator is
> probably best. If that activator keys something that a previous
> instance is holding down, then the redundant keying of that held element
> could simply be ignored, while other elements being activated by the
> activator could be triggered if not of a hold-time-release nature.
>
> Lynn
> --------------------------
>
> Lynn Walls wrote:
>> That's a good question. I never thought of it before. Instantly off is
>> obviously too short -- but so is "infinity", which is what it is now.
>>
>> How about having something like a new property of an activator element
>> named something like "Duration" whose value would be in milliseconds.
>> Then the Combination pistons could reference the activator, and the
>> activator would activate the referenced keyer for as long as the
>> duration specifies. If the value of Duration is 0, then the activator
>> would behave as is does now.
>>
>> Lynn
>> ---------------------------------------------------------------
>>
>> Sven Meier wrote:
>>> Hello Lynn,
>>>
>>> the 'locking' property does only influence an element if it is directly
>>> operated via mouse:
>>>
>>> http://jorgan.sourceforge.net/doku.php/disposition:keyer
>>>
>>> If you operate the keyer by piston, how should jOrgan know how *long* it
>>> should lock down the element?
>>>
>>> Sven
>>>
>>> Lynn Walls schrieb:
>>>> I give up!
>>>>
>>>> I've read Bruce's doc cover-to-cover...twice! But I can't figure out
>>>> how to get pistons to key a "Thunk" sound.
>>>>
>>>> I have a "Thunk" sample in my traps sf. I have created a "rank" element
>>>> for the Traps. I have created a hidden "stop" element named "Thunk"
>>>> which references the "rank". I have created a "keyer" element also
>>>> named "THUNK" which references the Thunk stop with a "Locking" property
>>>> value of "False".
>>>>
>>>> When I place this keyer on the console, and click on it I get the
>>>> "thunk" sound just fine. The keyer returns to the "off" state and I can
>>>> click on it over and over, and each time I makes the "thunk" sound
>>>> exactly as expected.
>>>>
>>>> Now I want my pistons to activate the "thunk". So I make each piston
>>>> reference the Thunk keyer.
>>>>
>>>> But now, when I click on a piston, it activates the thunk keyer JUST
>>>> ONCE, and the thunk keyer STAYS ON, even though its Locking property is
>>>> False.
>>>>
>>>> If I manually click the Thunk keyer, it goes off. Then I can click
>>>> another piston, and it dutifully activates the Thunk keyer which causes
>>>> the Thunk to sound. However, as before, the Thunk keyer stays ON, and
>>>> will not key the sound again until it is manually turned (clicked) off.
>>>>
>>>> I have also tried to use an Activator element, having the activator
>>>> reference the keyer and the pistons reference the Activator. But no
>>>> dice. The Thunk keyer, which behaves like a momentary on then off
>>>> button when it is clicked by the mouse, persists in staying on if
>>>> activated by a piston...it stays on until manually clicked OFF by the mouse.
>>>>
>>>> Any ideas? anybody?
>>>>
>>>> Lynn
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> jOrgan-user mailing list
>>>> jOrgan-user@...
>>>> https://lists.sourceforge.net/lists/listinfo/jorgan-user
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> jOrgan-user mailing list
>>> jOrgan-user@...
>>> https://lists.sourceforge.net/lists/listinfo/jorgan-user
>>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> jOrgan-user mailing list
>> jOrgan-user@...
>> https://lists.sourceforge.net/lists/listinfo/jorgan-user
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> jOrgan-user mailing list
> jOrgan-user@...
> https://lists.sourceforge.net/lists/listinfo/jorgan-user
>
|