<div dir="ltr"><div class="gmail_extra"><div>Thanks for replying, Jonathan.<br><br></div>If Pd-l2ork starts to supports Mac I'll seriously consider switching to it. Sounds like many of the issues and inconveniences are fixed there. Let me reply to your questions.<br><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div><div><div><div><div dir="ltr"><div><font size="2">> * Standard GUI objects are ugly and have limited functionality.<br><br>Yes. Just curious-- what's the most critical functionality you feel is missing?</font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I don't recall all of my frustrations with the GUI objects, I just remember there were many. But let me try.<br></div><div> * A button object. You know, a rectangle with a piece of text that can be clicked to generate a bang. Usually people put a bang next to a comment, but it takes more space. I've also seen people implementing load and save buttons by putting "L" and "S" inside bangs. It looks really ugly and is hard to read, especially when the bang is small. When I first saw the <a href="https://raw.githubusercontent.com/dotmmb/mmb/master/browser.mmb.pd">browser</a> abstraction from the mmb library I was very curious how it works. Turns out, it uses sliders! They send messages when are clicked and slider position indicator can be hidden by choosing colors in the properties menu. I think this is a great illustration to how often PD makes us create hacks/workarounds instead of having a nice straightforward solution.<br></div><div> * Ability to remove "dented" corners (symbolbox and numberbox) and the triangle from number2, as well as hide the border completely. They can be helpful when doing quick prototyping but when I'm building a nice GUI, I often don't want to see them.<br></div><div> * A text box that visually indicates that it has focus and stuff is getting entered. Even better: show a cursor, allow to move it around and select and copy/paste text.<br></div><div> * Some kind of API to determine mouse coordinates _relative to the GOP_. Currently there seems to be no way of, say, building a menu abstraction that will highlight menu items when mouse cursor hovers over them (it should work regardless of how many subpatches deep it's situated and which of the parent subpatches is currently open).<br></div><div> * Drop-down list and selectbox, working out of the box, no external libraries.<br></div><div> * Ability to edit subpatch/abstraction arguments from the properties menu when subpatch/abstraction is in GOP mode with hidden arguments. Currently one has to disable GOP, edit the arguments, reenable GOP again.<br></div><div> * Ability to hide inlets/outlets when using GOP. The little boxes are often distracting and they take additional space. Currently a similar effect can be achieved by placing a canvas of the same size as the GOP area that covers it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div><div><div dir="ltr"><div><div></div><div><div><div><font size="2"><span class=""><div>> * There's no good support for the concept of functions/procedures. Let's say we need to take some input, do some transformations and produce output, and we need to do that in multiple places in our patch. We can copy the objects but that will make the patch use more memory and there will be no code reuse. Another way is to make that an abstraction, but it's silly to make abstractions for every little thing that we need in 2 places. Also, instantiating 2 abstractions still uses more memory. We can try reusing the same code but we'll have to make multiple output connections so we'll need proper routing in order to figure out where to send the result. I made an abstraction to simplify that but this should be a standard feature of PD.</div><div><br></div></span></font><div><font size="2">What are the practical limitations of the higher memory use in these cases? You're still going to have the same message passing overhead.</font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I don't know too much about how PD works internally but I imagine it probably maps all objects into some data structure in memory and then passes messages around by going from one object to another. The more objects is there in the patch and all subpatches, the more memory it'll take. It's probably a very small amount of memory per object, but theoretically it can add up (if certain abstractions are used multiple times in other abstractions, which are used multiple times in other abstractions, etc.), especially on mobile platforms. Maybe the additional memory usage is always very tiny, I don't know. But it feels weird to be wasteful.<br><br></div><div>Anyway, there's other use cases for this concept. Imagine object [pd A] that is a storage of some type. When banged on the inlet it sends the storage contents to the outlet. Objects [B], [C] and [D] need to be able to query the contents of object [A]'s storage. We can connect their outlets to [A] so that they can send a bang to it but how do we route the output? We don't want [C] and [D] to receive the output when [B] sends a bang to [A]. We can use spigots or store the output in intermediate objects ([float], [symbol], [list]) but it all complicates the patch and makes it less readable. I created a [func] abstraction that can be used like this:<br><br></div><div> [inlet from B]<br></div><div> |<br></div><div> [func]x[pd A] <= A may be connected to other objects but we'll ignore all output from it unless a message from B initiated it<br> |<br></div><div> [outlet to B]<br><br></div><div>It ignores all input from the right inlet unless a message is sent to its left inlet. In that case the message gets passed through the right outlet to the cross-connected object. A spigot is opened on the right inlet, the output is collected and stored (it can be multiple messages). Then spigot gets closed and output is send through the left outlet.<br><br></div><div>I'm not sure if this is the best solution but it's the best I came up with so far. I'm using this abstraction for my projects. I don't know how you guys usually implement this but I think this situation is quite common.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div><div><div style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif"><div><div><div><div><div dir="ltr"><div><div><div><div><font size="2"><span class=""><div>> * *.pd format is not very friendly to Git. Try viewing diffs and resolving merge conflicts. Moving a subpatch on the screen causes different coordinates to be saved in the file, often resulting in conflicts. Cutting and pasting renumbers all objects and connections. This makes using branches and working on the same files impractical.</div><div><br></div></span></font><div><font size="2">Also true, but isn't the same for all dataflow/flow-based languages?</font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I only coded before in non-dataflow languages before so I don't know, but it's a bummer. I tried collaborating with another person on a project and we discovered we can't work on the same file at the same time. One thing that could immensely help is some way of viewing the diffs. Maybe generating a "diff" patch where differences are somehow highlighted. Or generating a bunch of text files, one per subpatch of the main patch, and run regular text diff on them (but try to account for object renumbering). This sounds like a big task though, I doubt somebody implement something like this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div><div><div dir="ltr"><div><div><div><font size="2"><span class=""><div>> * PD community uses mailing lists for communications, haha. In order to find useful information I have to view one message per page, with tons of distracting quotes from previous messages.</div></span></font><div><font size="2"><span class=""><div><br></div></span></font><div><font size="2">What's the alternative? Also, note that there is a Pure Data forum for general discussions, too.</font><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>The forum is great. I wish everybody used it instead of the mailing lists.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div><div><div dir="ltr"><div><div><div>On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:nik@parkellipsen.de" target="_blank">nik@parkellipsen.de</a>></span> wrote:<br clear="none"><div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm, i always thought that the dynamic creation and destruction of sound sources (oscillators etc.) pretty inconvenient in PD,<br clear="none">
compared to a source-code based approach.<br clear="none">
<br clear="none">
Maybe i missed some developments here, but the last time i checked (a year ago maybe), this was clearly quite<br clear="none">
a hassle, even though i know it's possible.<br clear="none">
<div><div><br clear="none">
<br clear="none">
On Mon, Feb 22, 2016 at 03:49:43AM +0200, Matti Viljamaa wrote:<br clear="none">
> Perhaps a bit of broad question, but I find it interesting in order to speculate about future additions.<br clear="none">
><br clear="none">
> How do you think Pure Data is limited?<br clear="none">
> _______________________________________________<br clear="none">
> <a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">
> UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
</div></div></blockquote></div><br clear="none"></div></div><span class=""></span></div></div></div></div><span class=""><div><br clear="none"><div>_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></div></span></div></div><div> </div></div><div> </div></div><div> </div></div></div></div></div></div></div></blockquote></div><br></div></div>