<div dir="ltr">Hi, I'm coming back from summer vacations and I wish a great 2016 for everyone. By the way, as I believe, this year marks the 20th anniversary of Pd, when and where's the party?<br><div> <br></div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="color:rgb(0,0,0);font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><div class="h5">A signal outlet, at the right of a message outlet, is not very common for Pd.</div></div></blockquote><div><br></div><div>true, I can think only of sampstoms~ and mstosamps~</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="color:rgb(0,0,0);font-family:HelveticaNeue,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif"><div class="h5">it would not be my first choice. But not many objects are expected to have a fix like this, so just for once...<br clear="none"></div></div></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Exactly, that's how I feel, this is hopefully an one and only exception case. I've been extensively checking all objects and this is the only one I found an issue with backwards compatibility.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I still owe to the Pd list what I've listed as relevant regarding future developments in cyclone (making it more up to date with newer Max versions). It's not that much as I've said. I'll start a new thread soon about it.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I was recruiting help in the development of cyclone as well and some people showed interest, lets see how that goes.</div><div class="gmail_extra"><br></div><div class="gmail_extra">thanks and a happy new year.</div><div class="gmail_extra">Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-30 16:16 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">Here my opinion on the situation. There is no license or law to guide or steer us, but past experiences can help decide which opinion leads to the best solution.<br>
<br>
On 2015-12-25 08:28 PM, Alexandre Torres Porres wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2015-12-23 18:36 GMT-02:00 katja <<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a><br>
<mailto:<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Summarizing, the discussion in this thread has so far rendered three<br>
practical and simple solutions to improve MaxMSP compatibility in<br>
Cyclone without breaking Pd patches (with average~ as an example):<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- MaxMSP compatibility through an extra inlet / outlet<br>
</blockquote></blockquote>
<br>
> I still think that introducing an extra outlet is the least<br>
> complicated and least intrusive.<br>
<br>
A signal outlet, at the right of a message outlet, is not very common for Pd. And it leads to an object doing two things. Because of POLA*, added complexity and work, it would not be my first choice. But not many objects are expected to have a fix like this, so just for once...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- MaxMSP compatibility available through an extra operational mode<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not sure how an "extra operational mode" would work, but seems a little complicated.<br>
</blockquote>
<br>
It would mean using an argument or message to switch behaviour. As average~<br>
already has two (optional) arguments, which become mandatory just to<br>
specify a third, I do not see it as a reasonable option.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- MaxMSP compatibility available through an extra class<br>
</blockquote></blockquote>
<br>
> An extra class breaks compatibility, as you need another class name -<br>
> seems like a drastic or last resource solution.<br>
<br>
IMHO, this fits the situation best, as several objects have different names in Pd and Max/MSP. Apart from the extra object name.<br>
<br>
- MaxMSP compatibility available with a -legacy startup flag<br>
<br>
The -legacy startup flag would mean you can have only one of the two solutions per Pd-instance. Introducing this flag (in Vanilla?) just for this object would be a bit of overkill.<br>
<br>
So I will try to combine the average2~ functionality into average~.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers and merry xmas<br>
<br>
</blockquote>
Greetings & happy 2016,<br>
<br>
Fred Jan<br>
<br>
<br>
*) <a href="https://en.wikipedia.org/wiki/Principle_of_least_astonishment" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Principle_of_least_astonishment</a><br>
</blockquote></div><br></div>