[PD] Rampsmooth~. Was: Update cyclone maintenance
Fred Jan Kraan
fjkraan at xs4all.nl
Thu Jun 18 09:25:54 CEST 2015
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 at xs4all.nl
> <mailto:fjkraan at 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 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 at gmail.com
> <mailto:danomatika at gmail.com>
> >> <mailto:danomatika at gmail.com <mailto:danomatika at 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> <http://robotcowboy.com>
> >>
> >>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres
> >>> <porres at gmail.com <mailto:porres at gmail.com>
> <mailto:porres at gmail.com <mailto:porres at 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 at gmail.com
> <mailto:danomatika at gmail.com>
> >>> <mailto:danomatika at gmail.com <mailto:danomatika at 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 at lists.iem.at <mailto:pd-list-request at lists.iem.at>
> >>>> <mailto:pd-list-request at lists.iem.at
> <mailto:pd-list-request at lists.iem.at>> wrote:
> >>>>
> >>>> *From:*Alexandre Torres Porres <porres at gmail.com
> <mailto:porres at gmail.com>
> >>>> <mailto:porres at gmail.com <mailto:porres at gmail.com>>>
> >>>> *Subject:**Re: [PD] Update cyclone maintenance*
> >>>> *Date:*June 5, 2015 at 4:34:55 PM EDT
> >>>> *To:*Fred Jan Kraan <fjkraan at xs4all.nl
> <mailto:fjkraan at xs4all.nl>
> >>>> <mailto:fjkraan at xs4all.nl <mailto:fjkraan at xs4all.nl>>>
> >>>> *Cc:*"pd-list at lists.iem.at
> <mailto:pd-list at lists.iem.at> <mailto:pd-list at lists.iem.at
> <mailto:pd-list at lists.iem.at>>"
> >>>> <pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>
> <mailto:pd-list at lists.iem.at <mailto:pd-list at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >
>
>
More information about the Pd-list
mailing list