18 Jun
2015
18 Jun
'15
10:32 p.m.
A quick check with Max5 revealed they are control, not signal inlets.
that's still true in Max7, and slide~ also has control inlets in both Max5 and 7, so perhaps you should set it to control inlets to make them perfect clones. Although I like the idea of signal inlets for both of them :)
2015-06-18 4:25 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
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 <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
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 codefor
now, but could make the change possible at run-time, as it wasintended.
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, butit
>> doesn't. Instead, it generates a logarithmic curve just like [slide~]. I >> have attached a picture that shows how both are operating in thesame
>> way, where they shouldn't. >> >> In MAX, [rampsmooth~] does in fact generate a perfectly linearramp,
>> unlike [slide~]. >> >> I was actually able to implement [slide~] only with [fexpr~], making it >> 100% compatible to vanilla. If there's a filter formula thtgenerates
>> perfectly linear ramps I can implement it I guess, but it shouldbe
>> 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> >> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >> >> [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> <>> >>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres >>> <porres@gmail.com <mailto:porres@gmail.com> <mailto: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 anice
>>> 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. Lasttime
>>> 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> >>> <mailto: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> <http://danomatika.com/> >>> robotcowboy.com <http://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> >>>> <mailto: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> >>>> <mailto: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> >>>> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>> >>>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>" >>>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto: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 firstis
>>>> 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. Seemslike
>>>> very simple externals to make and I could go ahead andcode
>>>> 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 <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >