Hi Jan,
Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed.
Greetings,
Fred Jan
On 2015-06-07 11:33 AM, Jan Baumgart wrote:
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list