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 <[email protected]>: > > > 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 <[email protected] > > <mailto:[email protected]>>: > > > > > > 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 <[email protected] > > <mailto:[email protected]>>: > > > > > >> 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 <[email protected] > > <mailto:[email protected]> > > >>>> <mailto:[email protected] <mailto:[email protected]>>>: > > >>>> > > >>>> [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 > > >>>>> <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > <[email protected] <mailto:[email protected]> > > >>>>> <mailto:[email protected] <mailto:[email protected] > >>>: > > >>>>> > > >>>>> 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, > > [email protected] <mailto:[email protected]> > > >>>>>> <mailto:[email protected] > > <mailto:[email protected]>> wrote: > > >>>>>> > > >>>>>> *From:*Alexandre Torres Porres <[email protected] > > <mailto:[email protected]> > > >>>>>> <mailto:[email protected] <mailto:[email protected]>>> > > >>>>>> *Subject:**Re: [PD] Update cyclone maintenance* > > >>>>>> *Date:*June 5, 2015 at 4:34:55 PM EDT > > >>>>>> *To:*Fred Jan Kraan <[email protected] > > <mailto:[email protected]> > > >>>>>> <mailto:[email protected] <mailto:[email protected] > >>> > > >>>>>> *Cc:*"[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>" > > >>>>>> <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > >>>>>> > > >>>>>> > > >>>>>> 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 > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> [email protected] <mailto:[email protected]> mailing list > > >>>> UNSUBSCRIBE and account-management -> > > >>>> http://lists.puredata.info/listinfo/pd-list > > >>>> > > >>> > > >> > > >> > > >> > > >> N �n�r����)em�h�yhiם�w^�� > > > > _______________________________________________ > > [email protected] <mailto:[email protected]> mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
