Hmm i'd say there's no way to force people to employ transparent, modular software design as long as you want to keep the language (whether it's patcher- or code-based) somewhat flexible and powerful ...
On Mon, Feb 22, 2016 at 09:03:16PM +0000, Jonathan Wilkes via Pd-list wrote: > There are plenty of Pd patches just as unreadable. > > When a large number of users are getting value out of code that unreadable, we > need to ask more fundamental questions than > whether the visual noise includes more or fewer right angles. > > -Jonathan > > > > On Monday, February 22, 2016 3:25 PM, Matt Barber <brbrof...@gmail.com> wrote: > > > I've said this before, but I think there are very good reasons not to ever > include segmented patch cords (although hideable patch cords would be even > worse). These two features are responsible for some of the very worst patching > habits in Max/MSP. Have you ever been called on to run someone's patch, and > you > need to tweak something for your specific audio setup or fix a bug or > whatever, > and when you open it you get something that looks like this (one of the first > "max patch" results on google image search): > > http://www.letatoubleu.com/OLcomposer_files/image001.jpg > > If you can't bend the cords there's much less of a temptation to make these > kinds of can-of-worms patches, and more of an incentive to use send/receive > when you need to get a value into an inconvenient place. There's also an > incentive to make things more modular, which is usually far easier to debug > than a huge sprawling patch. So while I can see where they'd be very useful if > used judiciously, as someone who often has to operate someone else's patches, > I'm very hesitant. > > > On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list < > pd-list@lists.iem.at> wrote: > > Hi Eugene, > Great post! > > I help develop pd-l2ork, and it addresses some of the points below. I > recently got it building on OSX with most of the pd-extended libraries. > > I'll reply to each point below... > > > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik < > evgenius.lazarc...@gmail.com> wrote: > > > > Where do I start? > > > * Dynamic patching is officially not supported and bug/feature requests > get ignored. I had to jump through a lot of hoops to use dynamic patching > with GOP but I discovered a bunch of weird issues with subpatches not > getting redrawn and connectors left hanging after object deletion. Had to > build ugly hacks/workarounds since nobody's gonna fix the issues in PD. > Sending loadbangs to dynamically created objects is a pain, as well as > trying to dynamically connect them to something (most examples of using > the > "connect" message use hardcoded object ID's). > > GOP with dynamic patching is certainly tricky-- I find it way too > complicated to be generally useful. However, Pd-l2ork should work without > bugs with > GOPs. Things get fixed there, and bug reports don't sit around for ten > years. > > As far as connect messages-- I have exposed the canvas "find" method > inside > an object called [canvasinfo] in pd-l2ork. It would be possible to write > a set of abstractions to faciliate connections using object/abstraction > names instead of indices. But like GOP, dynamic patching is at its core > pretty > clunky so it would still be difficult to dynamically patch things > (especially doing it live). > > > * Support for lists is quite limited. Wanna create a multidimentional > array? Build your own. Want a hash map? Build your own. Luckily there's > list-abs but it's weird that such basic functionality (that's present in > most programming languages) is not a core language feature. > > Data structures have support for multi-dimensional arrays. In Pd-l2ork > you > can create a scalar in an object box which makes it slightly easier to > use them. But it's definitely more complex than using list-abs or the > newer array objects for single-dimensional arrays. > > > * Sends and receives are global which creates a potential for conflicts. > $0 can be used to avoid that but it looks ugly and many libraries, > patches, > and I think even help files, don't use it. > > I agree that $0 is ugly. I've got some locality using data structures > with > a "canvas" field in upcoming Pd-l2ork release, but it's still very > experimental. > > Pd-l2ork has [preset_hub] and [preset_node] which handle locality without > $0. It works quite well, but it would be an _enormous_ undertaking to > use that-- or any other design-- as a general replacement for wireless > > > * Help files are *.pd which sounds neat at first, until you realize that > they're not easily searchable and can't be viewed online. > > They are searchable in Pd-l2ork, as well as the last version of > Pd-extended > (I think). In the upcoming version of Pd-l2ork the help browser indexes > the > doc folder in less than a second. I'm just indexing the keywords in [pd > META]-- it could index full text too but that turns out not to improve the > results > very much. But it's possible to do serious tweaks, save/load/ship an > index, etc. if someone wants to take it on. > > > * Bugs and weird behavior when handling special characters. There's no > consistent way of escaping them. Sometimes characters disappear when > saving > and loading a patch. > > I gutted all the tcl commands from the GUI calls for Pd-l2ork, so > theoretically it should be way easier to handle special characters now. > But I have to > admit I'm using some low value ASCII code to delimit messages to the GUI. > It's just way easier to split on a single byte as opposed to, say, the > semicolons that aren't preceded by a slash. > > Still, there is a lot of work to make sure special characters and spaces > get saved correctly within Pd. It needs a lot of testing by a developer > who > knows all the ins and outs of how to read/write/revise a parser, plus > knowing exactly how those changes will affect past and future Pd patches > (both > in terms of the running instance and saving/loading patches). > > > * Limited support for comments. Special characters are not allowed > (really? these are comments!). Automatic line wrapping doesn't work well > since after saving/loading a patch often changes how text is broken into > lines. So I have to put each line as a separate comment. > > I think Ivica added support for saving newlines inside comments (as above, > it uses a hack to deal with special characters). But they still get > parsed-- > that's bad, although Pd isn't the only language that does that. > > > * Dependence on font sizes. By default object boxes scale automatically > depending on the text inside. When you add more text, all inlets/outlets > move. I installed a different version of PD and font size is slightly > different and all objects are of a different size now. > > This is a hard problem. The only solution I know of is to draw an extra > border in editmode showing the maximum width and height for the object > at the given canvas font size. > > My hypothesis is that any spec you come up with for fixing this will cause > more problems than it solves. And I see complaints like the one you've > raised here in other GUI toolkits/APIs like Qt and HTML5, with no obvious > solutions. > > > * Want to add an outlet to the beginning of a trigger object? Enjoy > disconnecting and connecting all other outlets since there's no way of > automatically move them. > > Yeah, that's bad. But at least in Pd-l2ork you can a) auto-connect one > object to many, b) auto-connect many to one, and c) auto-connect many > to many. > > > * Want to print all messages flowing through a connection for debugging > purposes? > > Use the cord inspector, aka magic glass, available in the last version of > Pd-extended as well as Pd-l2ork. > > > * Vanilla provides only minimal functionality while most of the > convenient objects are supposed to come from external libraries. There's > multiple issues with that. First one is that libraries are less > standardized and consistent. They have different approaches, sometimes > duplicate each other, use different conventions for naming, > inlets/outlets, > etc. Second issue is that libraries often become dead/unmaintained. > > That's true, though it isn't a technical problem. > > > * Big patches/abstractions become unreadable really fast. Connectors are > always straight lines and there's no support for dummy intermediate > "points" for connecting stuff. I use [t a] and [+~] for these purposes but > it'd be nice to have native support for this. > > I know a lot of people want segmented patch cords. I'm pretty happy with > Pd-l2ork's bezier cords myself, but if someone has enough interest to > implement and test Max-style segmented cords I wouldn't dig my heels in > against them. > > > * Standard GUI objects are ugly and have limited functionality. > > Yes. Just curious-- what's the most critical functionality you feel is > missing? > > > * 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. > > What are the practical limitations of the higher memory use in these > cases? > You're still going to have the same message passing overhead. > > > * *.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. > > Also true, but isn't the same for all dataflow/flow-based languages? > > > * PD seems to be maintained by only a handful of people and new > features/ > bug fixes are rarely released. I used to code in C and was thinking of > contributing but I found no good guide for new contributors. I wasn't even > able to compile PD on my Mac (there's multiple build scripts in the > sources > but none of them work). I'm also not sure what the testing process should > be (to make sure I'm not breaking any existing functionality or support > for > operating systems or devices). > > This is a problem of mentoring, or lack of it. All I can say is that > Ivica > fixed all the bugs I threw at him wrt Pd-l2ork, and now I try to do the > same with > the work I do on Pd-l2ork. > > > * 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. > > What's the alternative? Also, note that there is a Pure Data forum for > general discussions, too. > > > These are just the first things that came to my mind... > > They are certainly helpful, and I'd encourage you to keep them coming. I > can't speak for the rest of the community, but feedback like this > is worth its weight in gold. And at least on Pd-l2ork, it _can_ affect > the > future path the software takes. > > -Jonathan > > On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel <n...@parkellipsen.de> > wrote: > > Hmm, i always thought that the dynamic creation and destruction of > sound sources (oscillators etc.) pretty inconvenient in PD, > compared to a source-code based approach. > > Maybe i missed some developments here, but the last time i checked (a > year ago maybe), this was clearly quite > a hassle, even though i know it's possible. > > > On Mon, Feb 22, 2016 at 03:49:43AM +0200, Matti Viljamaa wrote: > > Perhaps a bit of broad question, but I find it interesting in order > to speculate about future additions. > > > > How do you think Pure Data is limited? > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/ > pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/ > pd-list > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list