Dear all, in order to make vline~ work for me as i would expect it to work, i made a pure-PD implementation called upp.vline~ .
It sits on github as part of the UPP framework, along with a few helper abstractions and a help file: https://github.com/grrrr/upp/ It is more or less a drop-in replacement, with three exceptions: - time units are samples in my version - there is a limit for the number of ramp segments within one DSP block. This number can be given as an argument, and, using 64, this would more or less be unlimited. By default it is 2. - The DSP block size must be specified if it is non-standard, either as a command line argument, or via inlet. By default it is 64. The whole thing is quite involved, using message scheduling and dynamically created voices for the synthesis of the ramp segments. I tried my best to make it as resource-conserving as possible, but it is certainly not a lightweight object. Please give it a try, bugs may still be lurking. best, Thomas -- Thomas Grill http://grrrr.org > Am 17.05.2016 um 05:21 schrieb Alexandre Torres Porres <[email protected]>: > > > > 2016-05-16 14:01 GMT-03:00 Miller Puckette <[email protected]>: > > It does this, but the endpoints of the segment are places at the end > of the previous block > > it may do things by "thinking" that the start point was the last sample of > the last block, but it doesn't place this value there, so in practice we > never see and get this starting point - and this is what seems wrong for us > here. > > [vline~] can also start lines anywhere inside a block, so I can send the > message "0, 64 1.45125" with a delay period of 32 samples by clicking in a > bang connected to [delay 0.725624]. If i do this, I never get "0" as a > starting point, but the last value, so if I keep clicking at it I get > > "64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 > 1 2 3 4 5 6 7 8 > 9 10 11 12 13 14 15 16 > 17 18 19 20 21 22 23 24 > 25 26 27 28 29 30 31 32 " > > > anyway, it'd make more sense to me if the print was > > "64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 > 0 1 2 3 4 5 6 7 > 8 9 10 11 12 13 14 15 > 16 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 31" > > and so, giving it a delay of "1" doesn't fix this > > check patch attached > > cheers > <vline.pd> _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
