[PD] Update cyclone maintenance
Jan Baumgart
raga.raga at gmx.de
Sun Jun 7 11:33:28 CEST 2015
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>>:
>
> [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 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>>:
>>
>> 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 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>>
>>> *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>>
>>> *Cc:*"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>>
>>>
>>>
>>> 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 mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
--
Jan Baumgart
Technischer Mitarbeiter
Hochschule für Musik und Darstellende Kunst
Eschersheimer Landstr. 29-39
60322 Frankfurt am Main
More information about the Pd-list
mailing list