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 hans@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 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 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@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>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@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 wayor
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>>: 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@lists.iem.at > mailto:pd-list-request@lists.iem.at wrote: > > *From:*Alexandre Torres Porres <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> > *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