> 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 <h...@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 <fjkr...@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 <danomat...@gmail.com > >>>> <mailto:danomat...@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 > >>>>> <por...@gmail.com <mailto:por...@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 <danomat...@gmail.com > >>>>> <mailto:danomat...@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-requ...@lists.iem.at > >>>>>> <mailto:pd-list-requ...@lists.iem.at> wrote: > >>>>>> > >>>>>> *From:*Alexandre Torres Porres <por...@gmail.com > >>>>>> <mailto:por...@gmail.com>> > >>>>>> *Subject:**Re: [PD] Update cyclone maintenance* > >>>>>> *Date:*June 5, 2015 at 4:34:55 PM EDT > >>>>>> *To:*Fred Jan Kraan <fjkr...@xs4all.nl > >>>>>> <mailto:fjkr...@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 >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list