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@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.or.at mailto:hans@at.or.at>:
About maintaining cyclone, I think a reorg would be great, andfurther
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 <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 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 itshould 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> >>>> <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> <>>>> robotcowboy.com <http://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 needto
>>>>> download etxernals for that. I was just wondering ifextended
>>>>> 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. 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 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 <mailto: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 <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list