[PD] Update cyclone maintenance
Alexandre Torres Porres
porres at gmail.com
Sat Jun 20 14:28:55 CEST 2015
I see, now it makes sense :)
> I think it doesn't need to be perfect
You know what? Me too, haha
take care
2015-06-20 5:43 GMT-03:00 Fred Jan Kraan <fjkraan at xs4all.nl>:
>
>
> On 2015-06-19 06:37 PM, Alexandre Torres Porres wrote:
> >> But please do not work on cyclone and
> >> break the Max/MSP compatibility.
> >
> > Howdy... Of course! Agreed! But not sure about the purpose of this
> > remark considering what was being discussed with [rampsmooth~] and all -
>
> I asked Hans off-list about reorganizing the cyclone source tree in the
> svn repositry. I thought it could use some maintenance, but wasn't sure
> it was a good idea.
>
> > it was for the sake of compatibility. We're actually being very strict
> > to make it exactly like Max here. For example, I've just mentioned
> > [slide~] should have control inlets instead of audio inlets like it has.
> > The fact that it also accepts audio signal doesn't break the
> > compatibility, and might be nicer, but I guess it needs to be that way
> > for it to be a proper clone.
>
> Having signal inlets, means it works with control messages too. So it
> won't break compatibility, IMHO. I think it doesn't need to be perfect,
> as long as it close enough and usable too.
>
> >
> > cheers
>
> Greetings,
>
> Fred Jan
> >
> > 2015-06-19 11:43 GMT-03:00 Hans-Christoph Steiner <hans at at.or.at
> > <mailto:hans at at.or.at>>:
> >
> >
> > About maintaining cyclone, I think a reorg would be great, and
> further
> > maintenance as well. If you want to do whatever you want with it,
> > then just
> > make a fork and work on it as a new
> > name. If you want to stick to cyclone's central goal of Max/MSP
> > compatibility, then keep working on it as cyclone. But please do
> > not work on
> > cyclone and break the Max/MSP compatibility.
> >
> > .hc
> >
> > Alexandre Torres Porres:
> > > 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.
> > >
> > > cheers
> > >
> > > 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
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> N �n�r����)em�h�yhiם�w^��
> >
> > _______________________________________________
> > 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
> >
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150620/f70847fe/attachment-0001.html>
More information about the Pd-list
mailing list