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 - 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.

cheers

2015-06-19 11:43 GMT-03:00 Hans-Christoph Steiner <hans@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@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@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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-list@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list