<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="">On Sep 30, 2016, at 2:44 PM, João Pais <<a href="mailto:jmmmpais@gmail.com" class="">jmmmpais@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On 09/30/2016 09:11 PM, João Pais wrote:<br class=""><blockquote type="cite" class="">ah, I was thinking of android and iOs<br class=""></blockquote><br class="">ah, that one again....<br class=""><br class="">the problem with iOS is that<br class="">- all software must go through the AppStore<br class="">AND<br class="">- the AppStore does not allow GPL software.<br class=""><br class="">the "problem" with the entire external collection as was shipped with<br class="">Pd-extended (and is shipped with Pd-l2ork and purr-data) is that a<br class="">relevant percentage of the externals are released under the GPL.<br class=""><br class="">so how?<br class=""></blockquote><br class=""><span class="" style="float: none; display: inline !important;">didn't Dan manage a Pd "port" with his pdparty?</span></div></div></blockquote><div class=""><br class=""></div><div class="">No. PdParty uses libpd and emulates the GUI objects via send/receives. There is no ability to patch, only run patches and scenes which are essentially folders with a specific layout. I could/would consider adding this in the future if/when libpd can properly wrap the various GUI controls. Also, rethinking interface design for mobile-based patching is a non-trivial task. So far I am limiting myself to things I *need* as opposed to things that are *possible*.</div><div class=""><br class=""></div><div class="">PdParty is meant as an alternative to my Linux-based wearable computer using iOS. It’s not a replacement for desktop Pd. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="" style="float: none; display: inline !important;">in case purr-data turns out to be reliable, would it be a possible idea to use it also with this project, or is it too much too fast?</span></div></div></blockquote><div class=""><br class=""></div><div class="">I have no plans to switch from libpd which is built around Pd vanilla. AFAICT most of the major updates to versions/branches/forks etc of Pure Data involve usability and bundling of externals which is a different domain that is not useful for a libpd-based app which creates it’s own interface and only uses the pd core.</div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">--------<br class="">Dan Wilcox<br class=""><a href="https://twitter.com/danomatika" class="">@danomatika</a><br class=""><a href="http://danomatika.com" class="">danomatika.com</a><br class=""><div class=""><a href="http://robotcowboy.com" class="">robotcowboy.com</a></div></div>
</div>
<div><br class=""></div><br class=""></body></html>