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).
- 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.
- 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.
- Help files are *.pd which sounds neat at first, until you realize that
they're not easily searchable and can't be viewed online.
- 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.
- 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.
- 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.* 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.
- Want to print all messages flowing through a connection for debugging
purposes? Remove the connection, then create a [t a a] object, then create a [print] object, then connect [print] to the second outlet, then connect [t a a] to the previous and next object (If you don't use the [trigger], messages will only be printed after they flow through the whole system). After you're done, delete the objects and re-create the connection. Not very convenient for quick debugging.
- 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.
- 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.
- Standard GUI objects are ugly and have limited functionality.
- 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.
- *.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.
- 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).
- 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.
These are just the first things that came to my mind...
On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel nik@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
Over the years, the most common complaint I've heard about Pd's limitations is that it's not identical to Max/MSP.
On Mon, Feb 22, 2016 at 4:19 AM, Eugene Lazarchik < evgenius.lazarchik@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).
- 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.
- 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.
- Help files are *.pd which sounds neat at first, until you realize that
they're not easily searchable and can't be viewed online.
- 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.
- 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.
- 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.* 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.
- Want to print all messages flowing through a connection for debugging
purposes? Remove the connection, then create a [t a a] object, then create a [print] object, then connect [print] to the second outlet, then connect [t a a] to the previous and next object (If you don't use the [trigger], messages will only be printed after they flow through the whole system). After you're done, delete the objects and re-create the connection. Not very convenient for quick debugging.
- 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.
- 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.
- Standard GUI objects are ugly and have limited functionality.
- 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.
- *.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.
- 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).
- 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.
These are just the first things that came to my mind...
On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel nik@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
Or SC :)
2016-02-22 11:12 GMT-03:00 Matt Barber brbrofsvl@gmail.com:
Over the years, the most common complaint I've heard about Pd's limitations is that it's not identical to Max/MSP.
On Mon, Feb 22, 2016 at 4:19 AM, Eugene Lazarchik < evgenius.lazarchik@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).
- 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.
- 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.
- Help files are *.pd which sounds neat at first, until you realize that
they're not easily searchable and can't be viewed online.
- 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.
- 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.
- 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.* 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.
- Want to print all messages flowing through a connection for debugging
purposes? Remove the connection, then create a [t a a] object, then create a [print] object, then connect [print] to the second outlet, then connect [t a a] to the previous and next object (If you don't use the [trigger], messages will only be printed after they flow through the whole system). After you're done, delete the objects and re-create the connection. Not very convenient for quick debugging.
- 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.
- 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.
- Standard GUI objects are ugly and have limited functionality.
- 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.
- *.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.
- 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).
- 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.
These are just the first things that came to my mind...
On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel nik@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
Well yeah lots of people jabber about how Max/MSP is an "industry standard" and how badly documented Pd is (which might have been true 10 years ago, but not today), and generally seem to be afraid of free software ... incidentially, most of those use a Mac ;)
About the comparison to SC, well, different tools for different jobs, i guess ?
On 22.02.2016 16:01, Alexandre Torres Porres wrote:
Or SC :)
2016-02-22 11:12 GMT-03:00 Matt Barber <brbrofsvl@gmail.com mailto:brbrofsvl@gmail.com>:
Over the years, the most common complaint I've heard about Pd's limitations is that it's not identical to Max/MSP. On Mon, Feb 22, 2016 at 4:19 AM, Eugene Lazarchik <evgenius.lazarchik@gmail.com <mailto:evgenius.lazarchik@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). * 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. * 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. * Help files are *.pd which sounds neat at first, until you realize that they're not easily searchable and can't be viewed online. * 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. * 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. * 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.* 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. * Want to print all messages flowing through a connection for debugging purposes? Remove the connection, then create a [t a a] object, then create a [print] object, then connect [print] to the second outlet, then connect [t a a] to the previous and next object (If you don't use the [trigger], messages will only be printed after they flow through the whole system). After you're done, delete the objects and re-create the connection. Not very convenient for quick debugging. * 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. * 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. * Standard GUI objects are ugly and have limited functionality. * 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. * *.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. * 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). * 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. These are just the first things that came to my mind... On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel <nik@parkellipsen.de <mailto:nik@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 <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
2016-02-22 12:12 GMT-03:00 Niklas Reppel nik@parkellipsen.de:
Well yeah lots of people jabber about how (...) how badly documented Pd is (which might have been true 10 years ago, but not today).
I guess we have to mention "which" Pd are we talking about, cause vanilla is quite raw and naked, in a comparison to max, SC or whatever is just tough to match
But we basically have only vanilla widely available for all platforms. Extended is dead and poorly documented indeed. External packages in general are not well maintained, just realize how almost all libraries that were in extended are unmaintained.
Pd-l2ork is a great project, well documented so it seems (I never installed it), but only for linux now
cheers
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.lazarchik@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 nik@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
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.lazarchik@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 nik@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
2016-02-22 17:25 GMT-03:00 Matt Barber brbrofsvl@gmail.com:
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):
I agree, and I laugh when people say, this is hard to understand in Max, because of all the cords, I can't imagine how ugly it'd be in Pd.
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 <brbrofsvl@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.lazarchik@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 nik@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
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 brbrofsvl@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.lazarchik@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 <nik@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
I consider sends and receives evil. They're similar to global variables or goto statements in general purpose programming languages.
When you see a receive object, it's not obvious where all corresponding sends may be. As opposed to simply following where the cords go.
Also, consider a subpatch (or abstraction), with certain cords connected to it. In a way the inlets and outlets describe how this object can be used: it can receive certain messages through inlets and then send output to the outlets. But if there's sends and receives inside, it becomes much harder to track what the object may do.
In regards to the screenshot: it could be simplified by putting stuff into subpatches. However, even when there's only a couple of objects on a subpatch, the cords can still cross the objects if there's no way to segment them. Typical reasons include long objects ([pd $0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this and that], etc.). Also it's hard to avoid a mess without segmenting if there's a lot of feedback connections (when A's output is connected to B but also B's output is connected to A).
Also, moving functionality in a subpatch usually should only be done when there's something common between the objects inside and they implement a relatively siloed functionality. Otherwise it may be hard to understand what the subpatch is doing and the reader will have to constantly switch between the parent and the subpatch to understand how they work together.
On Mon, Feb 22, 2016 at 12:25 PM, Matt Barber brbrofsvl@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.lazarchik@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 nik@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
Thanks for replying, Jonathan.
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.
- Standard GUI objects are ugly and have limited functionality.
Yes. Just curious-- what's the most critical functionality you feel is missing?
I don't recall all of my frustrations with the GUI objects, I just remember there were many. But let me try.
- 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 browser https://raw.githubusercontent.com/dotmmb/mmb/master/browser.mmb.pd 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.
- 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.
- 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.
- 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).
- Drop-down list and selectbox, working out of the box, no external
libraries.
- 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.
- 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.
- 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.
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.
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:
[inlet from B]
|
[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 | [outlet to B]
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.
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.
- *.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?
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.
- 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.
The forum is great. I wish everybody used it instead of the mailing lists.
On Sun, Feb 21, 2016 at 6:30 PM, Niklas Reppel nik@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
On Mon, 2016-02-22 at 01:19 -0800, Eugene Lazarchik wrote:
Where do I start?
Thanks. That is a pretty comprehensive list, though I do not agree with all your points (ugly look, mailing list, big patches become unreadable fast). For me the most important point is still missing.
- Since Pure Data aims to be a realtime / live application, I am missing
most that I cannot do some actions without interrupting audio. Everything that touches the DSP graph is a no-go. There's a way around many things that touch DSP graph (never resize arrays used in DSP, for instance). But not being able load patches without interrupting audio is the most limiting factor for me.
- The world of CPUs has shifted focus from single-threading performance
to many cores and power efficiency. It seems it's getting harder finding a device with a single-threading performance as good as my 8-year old laptop. And I'm easily saturating that one with my Pd stuff. What am I going to do when it dies? I'd love if Pd would provide some true multi-threading (not like [pd~] which is tightly coupled to its parent).
Roman
- 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).
- 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.
- 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.
- Help files are *.pd which sounds neat at first, until you realize
that they're not easily searchable and can't be viewed online.
- 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.
- 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.
- 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.* 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.
- Want to print all messages flowing through a connection for
debugging purposes? Remove the connection, then create a [t a a] object, then create a [print] object, then connect [print] to the second outlet, then connect [t a a] to the previous and next object (If you don't use the [trigger], messages will only be printed after they flow through the whole system). After you're done, delete the objects and re-create the connection. Not very convenient for quick debugging.
- 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.
- 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.
- Standard GUI objects are ugly and have limited functionality.
- 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.
- *.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.
- 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).
- 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.
Le 23/02/2016 09:00, Roman Haefeli a écrit :
going to do when it dies? I'd love if Pd would provide some true multi-threading (not like [pd~] which is tightly coupled to its parent).
Roman
That's a clever point I'm also sharing, but from informations grabbed in tcl documentation that seem to imply a complete rewrite of the client:
Some consolidated rules for embedding Tcl in a threaded application:
You can*NEVER*use the same interpreter from more than one thread
If you only have one Tcl Interpreter:
You can use either Unthreaded or Threaded Tcl
No/Big Global Mutex/[ http://wiki.tcl.tk/25243Big Global Mutex] http://wiki.tcl.tk/25243is required for Unthreaded Tcl Build (Never required for Threaded Tcl build)
If you have Multiple Tcl Interpreters:
If you are using an Unthreaded Tcl/Big Global Mutex/[ http://wiki.tcl.tk/25243Big Global Mutex] http://wiki.tcl.tk/25243is required for*ALL*calls to functions in libtcl
If you are using a Threaded Tcl, no mutex locks are required
-
Alexandre Torres Porres -
Eugene Lazarchik -
Jonathan Wilkes -
Matt Barber -
Niklas Reppel -
patrice colet -
Roman Haefeli