[PD] Line comportments.

[patko]

 This one compute remaining time for finishing a broken ramp just to make something complete


----- "Olivier Baudu" <lamouraupeuple at gmail.com> a écrit :

> Hi,
> 
> I noticed different strange comportments with [line].
> 
> 1)
> When I send, for exemple, [100 10000( to a [line] for the second time
> the line give me 100 during 10 sec.
> I expected it no to give me anything as it is said in the help-file :
> "You should also note that if you click that [bng] again a second
> time, nothing happens. This is because [line] is already at 1000, so
> sending it new instructions to ramp to 1000 is meaningless and has no
> effect."
> 
> 2)
> When I send [stop( to the line I can get the last send value in the
> [number \ I've put under. OK.
> But this last value is not use as the new beginning of the next ramp.
> It's the last ramp's beginning that is.
> Whereas if I send new taget and time during the ramp it's the current
> value which is use as the beginning value for the ramp.
> 
> 3)
> I tried to put a [sel ] under the [line ] (with sure sent value by the
> line) to reset the line, or to stop the ramp.
> But the result is different if the bang is send from the [sel] than if
> I click it manually.
> --> If I bang manually [stop( the ramp stop, an I get the last value.
> --> If the [sel ] bang [stop( the ramp stop but send me the last
> beginning value.
> I try to put a [i]--[change] under the line expecting to solve the 1)
> problem... but it doesn't work.
> 
> Is it the same for everyone ?
> I use 0.42.5-extended-rc5 on Ubuntu Lucid.
> 
> Thank you.
> 
> 01ivier.
> 
> 
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list

-- 
Patrice Colet 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linebreak.pd
Type: application/octet-stream
Size: 1913 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100730/c1d5fce3/attachment.obj>