<div dir="ltr">Great & Awesome, Thanks!<br><br>But please allow me to make a suggestion and start a discussion.<br><div><br></div><div>If backwards compability is really considered that important, perhaps we could just create a second signal outlet, it'd keep the current functionality and add the original signal design.</div><div><br></div><div>I suggest that because I consider a priority the focus on a faithful object relationship between max and pd. I consider this to be the one great purpose of it. so I think it's weird to have an object with a different name, that doesn't exist in max, to behave as such, whilst the object that was supposed to have that same functionality doesn't.  </div><div><br></div><div>If keeping two objects, why not give the old one a new name? But one way or another, two objects sounds bad to me. I'd go further as to discuss if this functionality is necessary, we can achieve it with other objects in Pd, such as another object from cyclone, which is [cyclone/avg~], and also env~ and [zexy/avg~] or [zexy/tavg~]...<br><br>Moreover, instead of just using other objects, you could just use [cyclone/snapshot~] to convert the audio output to control if needed. It's a simple fix. I don't believe there are that many patches out there that depend on this, and if they exist, again, it's a simple fix, and it seems healthier to fix them than to maintain it just because we had it wrong to begin with...</div><div><br></div><div>I'm fine in having some flexibility and not having the exact same functionality as in max, we could have other functionalities/features, so having two outlets could be meeting halfway - I just tend to criticize this need to maintain features and behaviours that emerged from mistakes and then adding other stuff around it and making it more complicating than just fixing it.</div><div><br></div><div>Anyway, those are my thoughts on it, anybody else?</div><div><br></div><div>cheers</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-06 19:27 GMT-02:00 Fred Jan Kraan <span dir="ltr"><<a href="mailto:fjkraan@xs4all.nl" target="_blank">fjkraan@xs4all.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi List,<br>
<br>
Finally a set of changes made it to a workable state:<br>
<br>
- average~:<br>
  Created an average2~ to support a signal outlet for Max compatibility<br>
and retain backward cyclone compatibility in average~.<br>
- frameaccum~:<br>
  Added a wrap option.<br>
- coll:<br>
  Added threaded load/save option from L2ork by Ivica Ico Bukvic.<br>
- Scope~:<br>
  Improved resize behaviour. Added a resize message to support pixel<br>
accurate resize.<br>
- all signal objects:<br>
  Prevent crash Pd with [dsp( message.<br>
<br>
The intention is to test this on multiple platforms and create deken<br>
compliant binary distributions as version 0.2 beta1. The current state<br>
of the code can be found at: <a href="https://github.com/electrickery/pd-cyclone" rel="noreferrer" target="_blank">https://github.com/electrickery/pd-cyclone</a>.<br>
Note the coll and average2~ code are currently in topic specific branches.<br>
<br>
Fred Jan<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div><br></div>