<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox <span dir="ltr"><<a href="mailto:danomatika@gmail.com" target="_blank">danomatika@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="">On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>> wrote:<br>
</div><div><div class=""><br></div></div><div><div class=""><div><br></div></div><div>Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD.</div>
</div></div></blockquote><div><br></div><div>If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class=""><br><blockquote type="cite"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.<br>
</blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</blockquote><div><br></div></div><div>This is what I'm worried about and if that's truly the case, why bother really?</div></div></div></blockquote><div><br></div><div>Because you said it earlier--you feel like you failed convincing your colleagues pd is a viable option and that implies that you care and would like to move the project forward. I would say it is not your fault because you're not the only one who experienced that. The vanilla implementation has an incredible backwards compatibility that unfortunately hampers its progress. I truly admire Miller's pioneering work as well as his ongoing efforts on maintaining pd. But let us not also forget that he also has an incredible vision to allow forks like pd-extended, pd-l2ork, libpd, eapd, now defunct dd, and many other (yes, I call them forks even though some try to closely adhere to the core compatibility). I myself adhere to the idea that I promote backwards compatibility as long as it does not prevent progress. More so, I see backwards compatibility being way overstated, particularly when it comes to source code as each release includes version-specific compiled externals, making this a moot point. Sure, there are behavioral corrections one needs to make to their patch ecosystem but I guess that is the price of progress. Think about the leap Apple did with OS9->OSX transition, and then later with G5->Intel, etc. The downside is a lot of stuff broke. The upside? They are now one of the largest company in the world that emerged from the ashes of a bankruptcy bailout. I do understand I am here correlating pd to a corporation--arguably a dubious endeavor, but only so if one fails to realize the core question:</div>
<div><br></div><div>What is more important to you: keeping backwards compatibility or moving the project forward? A question that applies to both regardless of their ostensibly orthogonal roots. Apparently, for Miller it is former (which is something I greatly respect him for), and for me it is latter.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class=""><br><blockquote type="cite"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing.<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</blockquote><div><br></div></div><div>True, but will that be integrated back into vanilla? It's the same problem again ...</div></div></div></blockquote><div><br></div><div>Knowing the pd dev cycle, it is unlikely. In my last conversation with Miller, he did mention interest in porting my infinite undo and preserving stacking order (undo depends on it), so that may happen at some point. As for the rest--unlikely. And I am perfectly fine with that. Because, ultimately it is all about the productivity--if infinite undo truly makes that much of a difference, installing pd-l2ork is as easy as it gets, and the price you pay to stay within that ecosystem is potentially losing some of the backwards compatibility. Ask yourself if the shortcomings outweigh benefits and you'll have your answer. Then again, you can always use pd-vanilla/extended for your older projects as the source will be always there in perpetuity under a license you cannot refuse.</div>
<div><br></div><div>So, what does all this amount to? I guess, rather than spending time debating something that has been debated to death, if you feel so strongly about this change, feel free to join forces with the rest of the pd-l2ork devs (Jonathan is already contributing a ton)--at the very least we will do our best to merge your contributions as we've done over the past years as our dev base has grown. And who knows, maybe at some point in the future it all will get merged back. And if not, it's still a win-win proposition if this makes your life easier even if only temporarily...</div>
<div><br></div><div>HTH</div><div><br></div><div>Disclaimer: none of what I said was in any shape or form meant to be inflammatory. Potential efforts at starting flame wars will be left unheeded--I would much rather hack pd-l2ork code ;-)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class=""><br><div>
<span style="border-collapse:separate;border-spacing:0px"><div style="word-wrap:break-word"><span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<div>--------</div><div>Dan Wilcox</div><div>@danomatika</div><div><a href="http://danomatika.com" target="_blank">danomatika.com</a></div><div><a href="http://robotcowboy.com" target="_blank">robotcowboy.com</a></div><div>
<br></div></div></span><br></div></span><br><br>
</div>
<br></div></div><br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div></div>