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 <h...@at.or.at > <mailto: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 > <mailto: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> > >>>> <mailto:danomat...@gmail.com <mailto:danomat...@gmail.com>>>: > >>>> > >>>> [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 > >>>>> <por...@gmail.com <mailto:por...@gmail.com> > <mailto: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> > >>>>> <mailto: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> > <http://danomatika.com/> > >>>>> robotcowboy.com <http://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> > >>>>>> <mailto: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> > >>>>>> <mailto: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> > >>>>>> <mailto:fjkr...@xs4all.nl <mailto:fjkr...@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