Hi Alexandre,
another bug, now in [slide~], it needs a ramp up value that is small, so the ramp down works. On the other hand, ramp down value can be zero and ramp up will still work. Check attached file.
Fixed this one too. I will try to fix cycle~ too before updating all binary packages.
I was able to implement slide~ with vanilla objects only and with [fexpr~], it works fine without this bug, but I found that the formula needs to have at least a value of "1" to work, so [max~ 1] does the job. but when it receives a "0", the audio will actually become constant, so it's not related to the bug in the slide~ object, where the ramp just doesn't happen.
The slide~ object will effectively use 1 for up and down values smaller than 1. Which is sensible as it represents the number of samples of the slide.
cheers
Thank you & greetings,
Fred Jan
2015-06-06 17:26 GMT-03:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:
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