Hi Alexandre, > About the [rampsmooth~], I see the new object is corrected, great! One > thing though, I just realized how it has no audio signal inlets for the > arguments!!! It was supposed to have them, just like [slide~] does. > It would be logical to expect this, but the Max5 and Max7 documentation does not mention the inlets. They are visible, but not used in the example. A quick check with Max5 revealed they are control, not signal inlets.
> cheers Greetings, Fred Jan > > 2015-06-07 7:28 GMT-03:00 Fred Jan Kraan <[email protected] > <mailto:[email protected]>>: > > 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 <[email protected] > <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>>>: > >> > >> [m_scale] is an abstraction ... > >> > >> -------- > >> Dan Wilcox > >> @danomatika <https://twitter.com/danomatika> > >> danomatika.com <http://danomatika.com> <http://danomatika.com> > >> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com> > >> > >>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres > >>> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] > <mailto:[email protected]> > >>> <mailto:[email protected] <mailto:[email protected]>>>: > >>> > >>> 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> > <http://danomatika.com/> > >>> robotcowboy.com <http://robotcowboy.com> > <http://robotcowboy.com/> > >>> > >>>> On Jun 5, 2015, at 4:35 PM, > [email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] > <mailto:[email protected]>> wrote: > >>>> > >>>> *From:*Alexandre Torres Porres <[email protected] > <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>>> > >>>> *Subject:**Re: [PD] Update cyclone maintenance* > >>>> *Date:*June 5, 2015 at 4:34:55 PM EDT > >>>> *To:*Fred Jan Kraan <[email protected] > <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>>> > >>>> *Cc:*"[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>" > >>>> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > >>>> > >>>> > >>>> 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 > >>> > >>> > >> > >> > >> > >> > >> _______________________________________________ > >> [email protected] <mailto:[email protected]> mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
