Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"
It's not possible to overload the function? aka 1 that takes 5 args and another that takes 7? From what I can tell, the usual style within the pd core has been to add new args to the end so that backwards compatibility isn't sacrificed. Then again, I don't know the details in this case ...
With libpd, so far, we've avoid trying to make any large, incompatible changes to the core. Mainly, at least IMO, because we do not want to end up diverging to the point to where we'll never be able to get said changes upstream. At this point, I'd love to sit down with a bunch of you and work out a proposed roadmap to separating gui & pd core so that libpd could become the standard core between flavors. I haven't delved into the core enough to know if that is a foolish idea, but it really seems like a great idea to standardize some of the functionality ...
On Jan 12, 2014, at 5:55 PM, pd-list-request@iem.at wrote:
From: Jonathan Wilkes jancsika@yahoo.com Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift" Date: January 12, 2014 at 5:54:49 PM EST To: pd-list@iem.at
On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote:
Hi,
This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it.
But notice the error tells the user that the proc expects five args, and not seven args like your revision of pdtk_canvas_sendkey. This is because matju told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably has to do with unicode support. I say that because you can find it in the Gridflow source file named "unicorn.cxx" (which is also funny in itself).
So if you can figure out what it's doing, you can try to merging it into Pd-l2ork or at least make it compatible with it. But there are probably several other places where matju drilled into Pd's walls from the outside, and they probably conflict with Pd-l2ork's renovations. (Probably the widgetbehavior struct and comment struct conflict.)
-Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
I tried in the past overloading things on tcl/tk side of things but that did not work out all that well. In this case, however, it is not practical to do so as the original implementation is inadequate to address the problem at hand and maintaining bunch of workarounds is simply too time consuming to push the project forward at a desired pace.
I think this is pretty much the reason why pd-l2ork exists. Pd-l2ork's philosophy is that it will maintain backwards compatibility as long as that does not require maintaining something broken/limited and whose workaround would result in way more overhead than it would to address the third-party libraries that rely on this. In this case it is AFAICT only Gridflow that does this and it has not been updated in quite some time (please correct me if I am wrong).
HTH
Best wishes,
Ico
From: Dan Wilcox [mailto:danomatika@gmail.com] Sent: Sunday, January 12, 2014 7:19 PM To: Jonathan Wilkes; Ivica Ico Bukvic Cc: pd-list@iem.at List Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"
It's not possible to overload the function? aka 1 that takes 5 args and another that takes 7? From what I can tell, the usual style within the pd core has been to add new args to the end so that backwards compatibility isn't sacrificed. Then again, I don't know the details in this case ...
With libpd, so far, we've avoid trying to make any large, incompatible changes to the core. Mainly, at least IMO, because we do not want to end up diverging to the point to where we'll never be able to get said changes upstream. At this point, I'd love to sit down with a bunch of you and work out a proposed roadmap to separating gui & pd core so that libpd could become the standard core between flavors. I haven't delved into the core enough to know if that is a foolish idea, but it really seems like a great idea to standardize some of the functionality ...
On Jan 12, 2014, at 5:55 PM, pd-list-request@iem.at wrote:
From: Jonathan Wilkes jancsika@yahoo.com
Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"
Date: January 12, 2014 at 5:54:49 PM EST
To: pd-list@iem.at
On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote:
Hi,
This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it.
But notice the error tells the user that the proc expects five args, and not seven args like your revision of pdtk_canvas_sendkey. This is because matju told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably has to do with unicode support. I say that because you can find it in the Gridflow source file named "unicorn.cxx" (which is also funny in itself).
So if you can figure out what it's doing, you can try to merging it into Pd-l2ork or at least make it compatible with it. But there are probably several other places where matju drilled into Pd's walls from the outside, and they probably conflict with Pd-l2ork's renovations. (Probably the widgetbehavior struct and comment struct conflict.)
-Jonathan
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com
On 01/12/2014 07:19 PM, Dan Wilcox wrote:
It's not possible to overload the function? aka 1 that takes 5 args and another that takes 7? From what I can tell, the usual style within the pd core has been to add new args to the end so that backwards compatibility isn't sacrificed. Then again, I don't know the details in this case ...
Well, if Pd-l2ork is sending 7 args to a canvas method "key", then it's surely using A_GIMME which allows an arbitrary number of arguments for the canvas "key" method. But even if the tcl proc that gave the error took variable args in both ico and matju's code there'd likely still be a problem: two developers making independent changes to the same part of Pd. The problem would just be pushed further down the line. (That's a good reason for using type-checked args, btw.)
With libpd, so far, we've avoid trying to make any large, incompatible changes to the core. Mainly, at least IMO, because we do not want to end up diverging to the point to where we'll never be able to get said changes upstream. At this point, I'd love to sit down with a bunch of you and work out a proposed roadmap to separating gui & pd core so that libpd could become the standard core between flavors. I haven't delved into the core enough to know if that is a foolish idea, but it really seems like a great idea to standardize some of the functionality ...
There are two issues:
- making libpd the standard core across flavors
- separating gui from audio/message system
#1 is fairly easy in theory. It just means declaring by fiat that libpd wants to be the standard core between flavors. In practice-- at least initially-- it's not too difficult either. Just take features that you think should be standard and work them into libpd. Something non-gui related and uncontroversial like "$@" or [initbang] would be a good candidate.
However, "reference implementation" will undoubtedly broaden the scope of libpd. For example-- it'd be extremely useful to everyone who uses the Pd GUI environment to have refcounted symbols, in order to build a decent, robust string manipulation library that doesn't require some new type or syntax to learn. If one just magically appeared tomorrow it would immensely broaden the scope of what your average Pd user could do in the language. However for libpd specifically, this would matter very little since the language the libpd user is binding to certainly has a decent, robust string manipulation library already. That's just one example. There are likely many other areas that are orthogonal to embedding Pd in another language but important to the general development of Pd.
#2 is hard. Where would you start and how would you proceed?
-Jonathan
On Jan 12, 2014, at 5:55 PM, pd-list-request@iem.at mailto:pd-list-request@iem.at wrote:
*From:*Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> *Subject:**Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"* *Date:*January 12, 2014 at 5:54:49 PM EST *To:*pd-list@iem.at mailto:pd-list@iem.at
On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote:
Hi,
This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it.
But notice the error tells the user that the proc expects five args, and not seven args like your revision of pdtk_canvas_sendkey. This is because matju told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably has to do with unicode support.
I say that because you can find it in the Gridflow source file named "unicorn.cxx" (which is also funny in itself).So if you can figure out what it's doing, you can try to merging it into Pd-l2ork or at least make it compatible with it. But there are probably several other places where matju drilled into Pd's walls from the outside, and they probably conflict with Pd-l2ork's renovations. (Probably the widgetbehavior struct and comment struct conflict.)
-Jonathan
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
#2 is hard. Where would you start and how would you proceed?
I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, & processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc.
Conceptually, I know the tcl/tk-ism for the canvas, object positions, etc are fully baked into how everything works and I don't see a reason to try and change that. Again, perhaps the easiest method would be formalize those conventions via function wrappers which work 1-1 within the existing tcl/tk gui but perhaps require some adaptation for other gui frameworks. In other words, trying to find the least intrusive way to do this as I believe Martin has already done with the existing work in libpd.
I truly respect Miller's work with Pure Data and understand the need to move slowly to maintain the highest possible backwards compatibility with all existing computer music pieces made in Pure Data. So far libpd has proven we can abstract some of the Pd core functionality without affecting Pd-vanilla, so I think it's possible to look for the next steps.
The recent point of not being able to run GEM & an audio heavy patch on the same pd instance is really not a fault of the core but of the gui implementation. I have used libpd within OpenFrameworks for a number of computer vision + sound apps so I know it's definitely possible.
Again, I'm only theorizing. I'm pretty familiar with how the iem guis are coded after emulating them in ObjC for PdParty, but I haven't delved into the nit and grit of the core yet. At least I can say now that the paradigms make more sense.
As reference, last summer I updated some pretty hairy C code in RTCmix so that it would build as a library on Windows in MinGW: https://github.com/CreativeInquiry/RTcmix I have access to a triple boot machine to test code on Win/Mac/Linux which I regular use for OpenFrameworks work. So if I seriously gave this a shot, it wouldn't be a "look, it works on my machine, but I haven't tried it on OS A, B, ...".
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core.
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
#2 is hard. Where would you start and how would you proceed?
I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL.
I think by DSP core you're referring to:
- DSP graph stuff
- message dispatching system
- various widgetbehaviors and data structures parentwidgetbehaviors
- all the gui logic in g_editor.c
- gui queuing stuff, array selection/manipulation logic, mouse motion
callbacks, and probably other things I'm forgetting
Is this correct?
In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, & processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc.
I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact?
-Jonathan
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core.
I wasn't referring to anything in particular, only in general.
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
#2 is hard. Where would you start and how would you proceed?
I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL.
I think by DSP core you're referring to:
- DSP graph stuff
- message dispatching system
- various widgetbehaviors and data structures parentwidgetbehaviors
- all the gui logic in g_editor.c
- gui queuing stuff, array selection/manipulation logic, mouse motion callbacks, and probably other things I'm forgetting
Is this correct?
Yes, minus the widgets and gui queuing stuff, etc. I'm talking about finding a way to separate the strictly gui stuff from the DSP graph. I recognize that some of that is required, so I'm trying to think pragmatically. Obviously you're a better judge of that as you have more experience with the code in the area.
In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, & processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc.
I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact?
Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core.
I wasn't referring to anything in particular, only in general.
Then what do you think of "$@" or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks?
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
#2 is hard. Where would you start and how would you proceed?
I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL.
I think by DSP core you're referring to:
- DSP graph stuff
- message dispatching system
- various widgetbehaviors and data structures parentwidgetbehaviors
- all the gui logic in g_editor.c
- gui queuing stuff, array selection/manipulation logic, mouse motion
callbacks, and probably other things I'm forgetting
Is this correct?
Yes, minus the widgets and gui queuing stuff, etc. I'm talking about finding a way to separate the strictly gui stuff from the DSP graph. I recognize that some of that is required, so I'm trying to think pragmatically. Obviously you're a better judge of that as you have more experience with the code in the area.
In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, & processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc.
I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact?
Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it.
Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer. However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive):
- displacing selected objects requires a message from core -> gui for
every single object that is selected. Here's such a message for displacing [clip] by one pixel:
.x9892638.c move .x9892638.t9896128 1 0 .x9892638.c coords .x9892638.t9896128R 40 37 72 54 .x9892638.c itemconfigure .x9892638.t9896128R -dash "" .x9892638.c coords .x9892638.t9896128o0 40 53 47 54 .x9892638.c coords .x9892638.t9896128i0 40 37 47 38 .x9892638.c coords .x9892638.t9896128i1 52 37 59 38 .x9892638.c coords .x9892638.t9896128i2 65 37 72 38
Compare to Pd-l2ork for the same action: .xa261e08.c move selected 1 0
And here's the Pd-l2ork message for displacing 100 selected [clip] objects by one pixel: .xa261e08.c move selected 1 0
(Compare to 36K of messages that Vanilla must send in order to do the same thing.)
It's even worse for "Put" menu arrays. Just fire up Pd with the "-d 3" flag and look at what gets sent from core -> gui every time you move the array one pixel.
- Vanilla only has a single "undo" level. So if you want the gui with
libpd to be at all modern you'll have to either a) add undo facilities to the core or b) code up a completely separate model of Pd objects in whatever language your gui uses. matju took route "b" in DesireData-- if you can still dl it, look in "poe.tcl"-- it's a tcl object-oriented library that keeps track of objects/canvases/etc. (Tcl/Tk 8.6 includes an object-oriented library in the core, so maybe this is easier to do now.) Ivica took route "a" in Pd-l2ork. Maybe there's some easier way to do this, but if you go a different route make sure it's maintainable.
- Most of the vanilla stuff doesn't even make use of the sys_queuegui
functionality which (as far as I understand it) can filter out needless calls to the gui.
- If you don't want to make changes to the core libpd stuff, the
problems mentioned above still cause dropouts. The core is sending (and the gui is receiving) enormous amounts of data over a socket while the audio engine is trying to meet deadlines. Additionally, any gui functionality you want to add on the gui side will be on top of what's already in g_editor.c. That will create unnecessary complexity. You'll essentially have one set of widget/canvas behaviors that get inspected in the core and send calls back to the gui, plus another set of widget/canvas behaviors that are defined in the gui and don't send messages at all to the core.
That's just off the top of my head. There are additional questions of design-- why the editing algos are even in the core instead of using the gui-toolkit which presumably has well-written, well-tested algos to do that kind of stuff very fast. (Plus the gui-toolkit is presumably doing that regardless, _every_ time you move the mouse in the window, so its wasted effort, especially for large patches with lots of objects on a canvas.) But if you're going to do incremental changes you don't have to tackle those right away.
-Jonathan
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core.
I wasn't referring to anything in particular, only in general.
Then what do you think of "$@" or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks?
Those would definitely be nice to have. I don't know what $@ refers to, is it the object arguments as a list?
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it.
Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer. However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive):
[snip]
That's all good info to know, thanks. I'd imagine libpd would't need to handle *move functions though. Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomatika@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomatika@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomatika@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned).
cheers, Rich
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? On Jan 13, 2014, at 5:14 PM, Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>> wrote:Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned).
You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime.
Actually even in 2d without audio the problems manifest themselves pretty quickly. For example: open the svg tiger inside Inkscape and move it around. Notice the clever trick-- the image is broken into tiles and moved starting with the pieces closest to the mouse. Since the user's eye focuses on the mouse pointer, the interaction looks snappy even though it may take half a second or more to finish moving the tile furthest from the pointer.
When you add realtime audio the options are either to err on the side of sluggishness or to be responsive and risk dropouts. If you want it to be responsive in both video and audio then you have to start doing some serious optimizations based on what you think the user cases are for the software. For example, the Inkscape trick is perfect for creating and manipulating vector graphics, but it would be terrible for a 2d animation environment where you'd presumably want the tiger to move as a single unit.
However, many of Pd's current problems don't have a lot to do with that. Tk is pretty good at being sluggish and avoiding dropouts when it doesn't have idle time to do graphics updates. In fact I can move around an svg tiger on a canvas without interrupting the "test audio" patch. Most dropouts related to the GUI have to do with what amounts to a DDOS attack from the core to the GUI. When you flood tcl with data from the socket it can't really do anything else but spend time receiving it. When you add that to whatever Pd core is doing to generate all those messages in the first place, you probably won't have any time left over for delivering audio.
Other toolkits are certainly more efficient than Tk. But if you're dragging an antialiased wire from the top left of the window to the bottom-right, the toolkit needs time to do those redraws.
Finally, I'm not really sure how Open-GL and hardware acceleration plays into all this. For example, Qt Graphics View docs have a note about accelerated graphics possibly adding a performance hit and possibly more latency, but it's only in the context of hardware that doesn't do floating point computations efficiently. I played around with Kivy a bit, which is hardware accelerated but honestly didn't see much of an improvement in cpu usage over comparable stuff in Tkpath.
-Jonathan
cheers, Rich
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomatika@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomatika@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned).
You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime.
The GUI and audio shouldn't be updated from the same thread. This is one nice thing about libpd, it forces a separation.
So in this type of world, the GUI can do whatever it needs to do in order to draw at the desired framerate, and flags graph changes along the way. The changes are then converted into a GUI-agnostic format and synchronously issued to the audio context.
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
On 02/18/2014 11:11 PM, Rich E wrote:On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>> wrote: Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? On Jan 13, 2014, at 5:14 PM, Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>> wrote:Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned).You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime.The GUI and audio shouldn't be updated from the same thread. This is one nice thing about libpd, it forces a separation.
What are the drawbacks to the multi-threaded approach? Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI?
So in this type of world, the GUI can do whatever it needs to do in order to draw at the desired framerate, and flags graph changes along the way.
In Pd-extended and Vanilla currently there is very little optimization to get the most out of Tk. Those problems have a tendency to get lumped in with single-threadedness. So if someone actually gets something with a better design up and running, just remember that you have to do similar optimization work before the benefits of the new system really start to shine. Otherwise you'll get burned out when the right approach still gets dropouts-- from the odd inefficient algorithm, some "standard" widget that eats CPU for lunch, or whatever else isn't documented on the shiny frontpage of the toolkit.
-Jonathan
The changes are then converted into a GUI-agnostic format and synchronously issued to the audio context.
Hi,
just to give some example of single vs multi-threaded, and some comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded programming, even on multi-core computers. BUT they handle a much reduced number of use cases.
- graphics chipsets are massively parallel. They handle huge amounts of
data. BUT they are hard to build, they also handle a much recuced number of use cases, CUDA and OpenCL being a generalization.
- vvvv (on windows) has its core single-threaded, and a lot of objects
are multi-threaded, just like pd. It suffers the same than pd: when you get interactive with the GUI, the framerate slows down dramatically.
- whitecat (a DMX software) has its GUI that runs on OpenGL, and it's
not that efficient.
In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much.
Take all this as small talk, I don't know much about core pd anyway :-/.
Cheers,
On 21/02/14 20:41, Charles Goyard wrote:
Hi,
just to give some example of single vs multi-threaded, and some comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded programming, even on multi-core computers. BUT they handle a much reduced number of use cases.
- graphics chipsets are massively parallel. They handle huge amounts of
data. BUT they are hard to build, they also handle a much recuced number of use cases, CUDA and OpenCL being a generalization.
- vvvv (on windows) has its core single-threaded, and a lot of objects
are multi-threaded, just like pd. It suffers the same than pd: when you get interactive with the GUI, the framerate slows down dramatically.
- whitecat (a DMX software) has its GUI that runs on OpenGL, and it's
not that efficient.
In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much.
[pd~] deals with the particular case of creating an extra dsp thread, it incurs overhead to do so and does not isolate the dsp from a busy patch. It is quite orthogonal to creating separate gui, video, audio or whatever threads.
What I guess you mean is very different .. an object to launch a distinct pd process within (and isolated from) the rest of a pd patch. But I am not sure how that would be any better or more human-readable than 2 pd instances with [netsend]s and a suitable script to launch them together.
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now.
Simon
Hi,
In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much.
[pd~] deals with the particular case of creating an extra dsp thread, it incurs overhead to do so and does not isolate the dsp from a busy patch. It is quite orthogonal to creating separate gui, video, audio or whatever threads.
Ah, I see the distinction now.
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread,
This is more like what I understood/infered. The idea is to put the burden of parallel programming from the guy that writes a patch to the pd developpers :).
Thanks for the details Simon,
++
Charles
On 02/21/2014 06:41 AM, Simon Wise wrote:
On 21/02/14 20:41, Charles Goyard wrote:
Hi,
just to give some example of single vs multi-threaded, and some comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded programming, even on multi-core computers. BUT they handle a much reduced number of use cases.
- graphics chipsets are massively parallel. They handle huge amounts of
data. BUT they are hard to build, they also handle a much recuced number of use cases, CUDA and OpenCL being a generalization.
- vvvv (on windows) has its core single-threaded, and a lot of objects
are multi-threaded, just like pd. It suffers the same than pd: when you get interactive with the GUI, the framerate slows down dramatically.
- whitecat (a DMX software) has its GUI that runs on OpenGL, and it's
not that efficient.
In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much.
[pd~] deals with the particular case of creating an extra dsp thread, it incurs overhead to do so and does not isolate the dsp from a busy patch. It is quite orthogonal to creating separate gui, video, audio or whatever threads.
What I guess you mean is very different .. an object to launch a distinct pd process within (and isolated from) the rest of a pd patch. But I am not sure how that would be any better or more human-readable than 2 pd instances with [netsend]s and a suitable script to launch them together.
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now.
Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent.
-Jonathan
Simon
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 22/02/14 06:28, Jonathan Wilkes wrote:
On 02/21/2014 06:41 AM, Simon Wise wrote:
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now.
Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent.
I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order.
Certainly in many audio patches the messaging load is small compared to the dsp, except when you add lots of gui elements to the patch. For them parallelising the messaging like this would indeed be pointless since a 2 thread solution with all the control interface in one instance of pd and all the dsp in another with both launched together from a script as the 'app' or using [shell] to launch the dsp instance makes a lot of sense ... here there is an obvious split for a separate thread. Since many modern computers are multicore and the dsp is only running on as many threads as you can devise with [pd~]s there is still plenty of idle cpu. I believe other languages have addressed parallelising the dsp graph in a more automated way but in pd this is done explicitly. For a single core raspberry or such the dsp thread can be given a higher priority so at least the audio isn't interrupted by too much interaction with the interface.
However pd is used for much more than audio. Dataflow programming is inherently parallel but the implementation in pd comes from a single core history (well, a single messaging core controlling a separate dsp if you go back far enough) and is sequential. Hence the whole trigger <-> fanout discussion, in pd fanouts are not really dataflow fanouts at all, just ill-defined triggers. The implementation is a sequential depth first tree traversal and triggers make that explicit.
Even the dsp<->gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches. Also splitting the dsp graph where ~ objects are in a distinct dataflow branch would make sense (there would need to be some decisions regarding exactly what distinct means in this context). A good implementation would follow the lead of other languages and wouldn't just create zillions of system threads to throw at the OS, but rather have a way of grouping them into a smaller number of ongoing system level processes. Writing and optimising this would be a huge project, and a patch run in a dataflow implementation would not behave in exactly the same way as it would in a sequential one, it couldn't.
But it is still an interesting thought experiment in the context of thinking about the future of pd in a world where a single thread sequential implementation is becoming increasingly problematic ... computers have been getting faster by adding cores rather than increasing clock speeds for some time now and that is not likely to change any time soon (quantum computing would be a whole new game and none of this would be relevant).
Simon
On 02/21/2014 10:04 PM, Simon Wise wrote:
On 22/02/14 06:28, Jonathan Wilkes wrote:
On 02/21/2014 06:41 AM, Simon Wise wrote:
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now.
Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent.
I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order.
[...]
Even the dsp<->gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches.
To know whether a control branch interacts with the signal domain is to solve the halting problem, no?
But you could have some kind of "seal" object that verifies the user thinks a subpatch or canvas is 100% pure control domain. And then Pd could take that to mean throw it in its own thread (and throw warnings/errors if it finds a message going to a signal object, or fudging with dsp in any way).
It could look like a wax seal and always be at the top-left of the patch.
-Jonathan
On 23/02/14 08:16, Jonathan Wilkes wrote:
On 02/21/2014 10:04 PM, Simon Wise wrote:
On 22/02/14 06:28, Jonathan Wilkes wrote:
On 02/21/2014 06:41 AM, Simon Wise wrote:
Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now.
Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent.
I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order.
[...]
Even the dsp<->gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches.
To know whether a control branch interacts with the signal domain is to solve the halting problem, no?
especially not if you allow a little syntactical help from the programmer .. as you note here. And note the point of this is that generally the interaction with the dsp does not have to be in zero logical time after it is initiated, although often discrete sequences of interactions must be applied together in a single dsp timeslice.
But also consider we are already making several simplifying assumptions and arbitrary (sometimes confusing) decisions as we turn the graph drawn as the pd patch into trees in the dsp and the message domains so that we can traverse them separately. If we allow fan-outs as parallel branches we change one of those arbitrary decisions. Instead of assigning an arbitrary order and re-writing the fan-out as a trigger we create new independent trees which we execute via a scheduler that runs in a similar way to any very basic OS scheduler ... when data is received for that tree it is put on a queue and executed the next time one of the cpu threads that pd has running is free. The usual priority queue stuff could be implemented regarding dsp interaction, scheduling on a basic level is very mundane stuff ... optimisations of all sorts at this point have been very well studied and can get as complex as you want. Note that we already break cycles in the graph, so we can indeed take each branch as a separate tree. There are obviously interesting complications and decisions regarding cold inlets, however the point of this is that by using a fan out the programmer is indicating that the branches may be run in parallel so cold inlets with data coming from outside should simply be updated whenever that data arrives ... use a trigger to ensure it is all part of the same tree if that is not good.
But you could have some kind of "seal" object that verifies the user thinks a subpatch or canvas is 100% pure control domain. And then Pd could take that to mean throw it in its own thread (and throw warnings/errors if it finds a message going to a signal object, or fudging with dsp in any way).
It could look like a wax seal and always be at the top-left of the patch.
that's somewhat like the notion in functional languages of 'pure' functions compared to ones with side effects, in this context the dsp could be considered as a side effect, in the same way any output from a functional program is ultimately a side effect.
Each functional language deals with this differently, and they are useful in different contexts. Unless you get into seriously strange constructs like monads for output and remain a strictly pure language (lambda calculus is turing-complete after all) there is some syntactical way (like your wax seal) to flag non-pure objects. In pd the ~ naming convention already does this, and could be enforced by the interpreter.
In pd the dsp and message passing domains are dealt with quite separately, and if we wanted to treat the message passing domain as a parallelisable dataflow graph with its effect on the dsp as one of its outputs (a side effect in functional languages jargon) then there is a wealth of research and implementations in the functional area to look into as a comparison.
A very crucial point here is that separating gui from dsp so that gui calculations do not block dsp means allowing the gui parts notion of 'zero logical time' to be distinct from the dsp parts notion of that. Essentially we want the result of some gui calculation to be applied a dsp block or so later rather than miss the deadline for calculating the next dsp block.
Currently this is most easily achieved explicitly by running a completely different pd process for each part. In our sequential tree traversal implementation we make sure that there are two message domain trees being traversed, and that the one controlling dsp shares a system thread with the (main) dsp and does as little as possible that is not strictly required for the dsp output. The other tree can run a bit late, we do not care if its messages to the dsp thread are received in the same dsp block as one the calculation started in.
If we interpret the pd patch as a dataflow graph allowing parallel execution of fanouts then we create several trees and schedule them in a dataflow manner, executing them in a collection of system threads maintained by our scheduler for that purpose. The notion of zero logical time is then on a per tree basis, and the interaction with the dsp thread(s) resulting from that tree must be applied in one atomic interaction when it completes.
Simon
On 23/02/14 15:13, Simon Wise wrote:
Note that we already break cycles in the graph, so we can indeed take each branch as a separate tree.
... but it is more an unroll than a break, or rather an exploration of the graph as a tree which may revisit the same nodes ... programmer beware of infinite loops, We can still create separate branches easily enough, if they overlap that is fine, the overlapping parts are simply included in each tree separately ... again programmer beware of the consequences and benefits of choosing a dataflow fanout rather than a trigger.
It is in the dsp domain we make choices and break cycles in the graph by passing the data to the next block instead to allow loops to work as expected.
Simon
On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomatika@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomatika@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned).
You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime.
The GUI and audio shouldn't be updated from the same thread. This is one nice thing about libpd, it forces a separation.
What are the drawbacks to the multi-threaded approach? Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI?
Firstly, I think the decision should at least be available (to process audio and GUI on separate threads), since this is the most common way to handle the two different update rates. Especially since, with most GUI frameworks, you _must_ update the GUI on the main / UI thread, which is running at 60fps.
But to answer the question... drawback is having to manage the whole 'this method must to be called on the audio thread, and that method must be called on the non-audio thread'. However this turns out to be little of a limitation since it is almost always what you want to do anyway, and you gain huge amounts in the area of responsiveness.
In the end, every situation is different. With pd vanilla, audio is most important and maybe that deserves the current architecture. To me, it is more about keeping options open, which is why I think abstracting the visual position from the core is a good idea.
I'm just having trouble with the specifics. Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Also, what is the metric to use here?
To compare apples to apples, imagine that every g_* sourcefile has already been moved to the GUI side of both the single- and double- threaded designs that are being compared.
-Jonathan
On Sunday, February 23, 2014 12:30 AM, Rich E reakinator@gmail.com wrote:
On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomatika@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomatika@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned).
You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime.
The GUI and audio shouldn't be updated from the same thread. This is one nice thing about libpd, it forces a separation.
What are the drawbacks to the multi-threaded approach? Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI?
Firstly, I think the decision should at least be available (to process audio and GUI on separate threads), since this is the most common way to handle the two different update rates. Especially since, with most GUI frameworks, you _must_ update the GUI on the main / UI thread, which is running at 60fps.
But to answer the question... drawback is having to manage the whole 'this method must to be called on the audio thread, and that method must be called on the non-audio thread'. However this turns out to be little of a limitation since it is almost always what you want to do anyway, and you gain huge amounts in the area of responsiveness.
In the end, every situation is different. With pd vanilla, audio is most important and maybe that deserves the current architecture. To me, it is more about keeping options open, which is why I think abstracting the visual position from the core is a good idea.
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
Also, what is the metric to use here?
Mmm open a larger patch with audio running, momentary dropouts.
Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
Also, to be honest, at this point if Cycling 74 came out with Max runtimes for iOS and Linux, I would probably switch. I don't say that because I don't like PD, but more from a pragmatic point of view where I consider which project is currently progressing in the long term.
For instance, on PD-dev, we're talking about updating GEM so it will work with the new Apple APIS aka in 64bit on any Mac OSX 10.7+. The writing has been on the wall for that transition FOR YEARS but there has been no work on that front. I must admit that I'm volunteering to make this update not because I use GEM, but because I fear PD losing out to Max when GEM doesn't work in computer labs running new Macs. Again, this is from personal experience at a major teaching institution where I was trying to push teaching PD but, frankly, it just wouldn't cut it for course requirements and taste of the professors involved. And I take that as a personal failure.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 23, 2014, at 7:37 AM, Dan Wilcox danomatika@gmail.com wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
Also, what is the metric to use here?
Mmm open a larger patch with audio running, momentary dropouts.
Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ok, Dan, i can feel you there. but let's not mix up the GUI-core separation with the GEM on OS X question. As much as their consequences are similar, they are fundamentally different in their implementation, no?
Questions that comes to my mind when I see the GUI-core separation discussion is this: Let's assume - totally hypothetically spoken - there is a company or individual who would sponsor this effort.
- Is there someone capable of completing the task?
- Would the result of this work be accepted by Miller and become vanilla?
- How long would that take?
m.
Am 2014년 02월 23일 21:37, schrieb Dan Wilcox:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
Also, what is the metric to use here?
Mmm open a larger patch with audio running, momentary dropouts.
Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
enohp ym morf tnes -------------- Dan Wilcox danomatika.com robotcowboy.com _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Feb 23, 2014, at 12:14 PM, Max abonnements@revolwear.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ok, Dan, i can feel you there. but let's not mix up the GUI-core separation with the GEM on OS X question. As much as their consequences are similar, they are fundamentally different in their implementation, no?
Max,
Forgive me as I'm not going to answer specifically regarding GEM :D That was just a recently re-opened wound so it made a pointed example.
I think what bothers me is that this comes up again and again and still the main response is: "what we have now is fine". That, after plenty of effort and previous code implementations that died on the vine and it feels already like trying to push libpd in that direction will yield the same result. I'm not trying to single out specific people, but just my general feeling in the project.
Maybe I'm off base, but I feel that pd needs real modernization or it will get less and less adoption. Sure it will be around, but you wont see as many beginners starting with it. At this point a continued debate over whether the gui should be multithreaded or not seems moot to me.
That comes in contrast to my involvement with the OpenFrameworks community which is growing via leaps and bounds. Sure, it's a younger project, but we've already had a number of developer conferences, developed a concerted development roadmap, delegated community leaders, etc. We work together. There have been a number of residencies sponsoring further development. I would really like to see that with this community as I really love working with PD but, again, why bother trying to push forward such an agenda on my own? I could probably rebuild my entire setup using Super Collider but I simply like patching audio better.
I'm not trying to weigh blame on anyone, just explain the situation as I see it. I suppose from a different perspective, I'm an outsider coming in and trying to needlessly shake up things that are already working, proposing premature optimizations, etc.
Questions that comes to my mind when I see the GUI-core separation discussion is this: Let's assume - totally hypothetically spoken - there is a company or individual who would sponsor this effort.
- Is there someone capable of completing the task?
I can probably do it if I wrap my head around the pd core. Peter Brinkmann and Jonathan W are probably better suited with their core familiarity and, obviously, Miller knows it through and through. The problem, of course, is that I or whoever would do this would need to be able to sit down, focus, and crank it out. I can't answer who could help sponsor that. My initial idea would have been STEIM, but do to NL budget cuts, they now have to rent the studios so the previous "no stings attached" residencies I had before are sadly no longer available. Another answer would Universities, but so far, I haven't seen much movement on this from previous discussions. The last option would be how I've funded my most recent project: freelance work and dedicating time off to work on my own projects. I could probably manage that, if needed, but I would *really really really* hate to spend a month on something that may not be adopted o go anywhere. I'd like to have the decisions made before I go out on a limb on my own dime. Open source is all about sharing, but that doesn't mean we write code for everyone else for free.
- Would the result of this work be accepted by Miller and become vanilla?
As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion.
- How long would that take?
Dunno. A few full time weeks for one person, probably (at least from my estimate). I imagine that could be shorter if there is a core developer meeting and overall architectural decisions could be hashed out and a roadmap developed. Sadly, this would be perfect for Google Summer of Code.
m.
Am 2014년 02월 23일 21:37, schrieb Dan Wilcox:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
Also, what is the metric to use here?
Mmm open a larger patch with audio running, momentary dropouts.
Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
enohp ym morf tnes -------------- Dan Wilcox danomatika.com robotcowboy.com _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMKLGwACgkQ3EB7kzgMM6Ij6QCeLvTudFFoBWIAryx6DvaFTI6D KH4An0zgJwCtqm1a9evrikGWWX48xyZ4 =oJnl -----END PGP SIGNATURE-----
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Hi all - just a short note since this discussion is much too wode-ranging to address in full...
- Would the result of this work be accepted by Miller and become vanilla?
As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion.
I think the main stakeholders are Pd users :)
Anyhow, there's a useful discussion thread about pdlib instancing here:
http://lists.puredata.info/pipermail/pd-dev/2013-12/019693.html
and there's a wonderful series of talks underway at IRCAM about the problems of real-time media computing in general:
http://repmus.ircam.fr/mutant/rtmseminars
cheers Miller
Well, then I'm simply out of the loop and mostly-off base. Woops, sorry. I'll go there and see if we can keep it going. Looks like we're talking about both multi-threading and multi-instances which would be a big move towards solving some fundamental problems.
Also, it's not really a discussion any more, I turned it into a rant. :P In any case, I'd rather let my frustration be known and apologize later than sit by and *hope* for updates. In any case, if I can be helpful I'm more than willing to pitch in and get things done.
On Feb 23, 2014, at 2:33 PM, Miller Puckette msp@ucsd.edu wrote:
Hi all - just a short note since this discussion is much too wode-ranging to address in full...
- Would the result of this work be accepted by Miller and become vanilla?
As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion.
I think the main stakeholders are Pd users :)
Anyhow, there's a useful discussion thread about pdlib instancing here:
http://lists.puredata.info/pipermail/pd-dev/2013-12/019693.html
and there's a wonderful series of talks underway at IRCAM about the problems of real-time media computing in general:
http://repmus.ircam.fr/mutant/rtmseminars
cheers Miller
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 02/23/2014 07:37 AM, Dan Wilcox wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
This is probably naive, but wouldn't it suffice to have an object that does automatically what the user is forced to do manually atm?
Manual -- user opens a Pd instance for GEM and a separate Pd instance for audio Auto -- user creates an object [foo-audio-magic somepatch.pd] which automatically fires up a separate instance-- _not_ a child of the first-- for the audio.
Also, what is the metric to use here?
Mmm open a larger patch with audio running, momentary dropouts.
How do you know that's due to Pd's single-threadedness, and not some CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI calculations in the core thread as well as tk's thread?
Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
That particular problem is due directly to *_getrect calls in a patch with lots of objects (and possibly a bunch of *_click calls if hovering over an object that does a lot of computation in such a function). It's not super easy to solve, but it's approachable because the Pd-GUI already exists. But that's a completely separate issue from getting something like GEM to run in its own thread.
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
It's not acceptable, but if you want to move forward _and_ do work that
will be in sync with or accepted into Pd vanilla I don't see a way
forward. I can't even get help docs into Pd vanilla, and they were
written to the PDDP spec that this community came up with and approved.
And as you know, there's a publicly viewable list of the same exact
frustrations from all kinds of developers with various styles of
communication.
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing.
Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket.
Anyway if you're interested in coding anything up related to this thread, I know Ivica is interested in solving the GEM issue you mentioned.
-Jonathan
Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On 23 Feb 2014, at 20:29, Jonathan Wilkes jancsika@yahoo.com wrote:
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication.
Indeed. This reminds of discussions on the pd dev list, some 7 years ago (!), which ultimately resulted in the Vibrez project a closed fork of Pd-devel, which added (among other things) basic multi-threading and a revamped GUI.
http://grrrr.org/research/software/vibrez/
http://grrrr.org/pub/grill-2007-pdcon-vibrez.pdf
IMHO, the introduction to that paper makes for sobering reading for anyone considering spending any significant effort on core Pd development.
Jamie
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 02/23/2014 07:37 AM, Dan Wilcox wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
This is probably naive, but wouldn't it suffice to have an object that does automatically what the user is forced to do manually atm?
I'm not saying there should be some mechanism to separate this object from that ... only that the gui should be on it's own thread, audio in the audio callback thread, and something like GEM running opengl in it's own thread. This is how modern applications work and also how using libpd inside OpenFrameworks works, same for iOS.
Manual -- user opens a Pd instance for GEM and a separate Pd instance for audio Auto -- user creates an object [foo-audio-magic somepatch.pd] which automatically fires up a separate instance-- _not_ a child of the first-- for the audio.
Or it *just works*, like Jitter in Max. Whether we split hairs about *how* it should work, the fact remains that to most people I introduce to Pd to, Max is more attractive as things like audio & video *just work* together. If the stakeholders of Pd are truly the users of Pd, then the complaints and requests for solving these kinds of issues should be obvious from the last 5-7 years ...
Also, what is the metric to use here?
Mmm open a larger patch with audio running, momentary dropouts.
How do you know that's due to Pd's single-threadedness, and not some CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI calculations in the core thread as well as tk's thread?
It can happen when opening patches in libpd, including those without "CPU-hogging objects". This is obviously *without* the gui.
Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
That particular problem is due directly to *_getrect calls in a patch with lots of objects (and possibly a bunch of *_click calls if hovering over an object that does a lot of computation in such a function). It's not super easy to solve, but it's approachable because the Pd-GUI already exists. But that's a completely separate issue from getting something like GEM to run in its own thread.
Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD.
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication.
This is what I'm worried about and if that's truly the case, why bother really?
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing.
Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket.
True, but will that be integrated back into vanilla? It's the same problem again ...
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomatika@gmail.com wrote:
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD.
If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.
Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication.
This is what I'm worried about and if that's truly the case, why bother really?
Because you said it earlier--you feel like you failed convincing your colleagues pd is a viable option and that implies that you care and would like to move the project forward. I would say it is not your fault because you're not the only one who experienced that. The vanilla implementation has an incredible backwards compatibility that unfortunately hampers its progress. I truly admire Miller's pioneering work as well as his ongoing efforts on maintaining pd. But let us not also forget that he also has an incredible vision to allow forks like pd-extended, pd-l2ork, libpd, eapd, now defunct dd, and many other (yes, I call them forks even though some try to closely adhere to the core compatibility). I myself adhere to the idea that I promote backwards compatibility as long as it does not prevent progress. More so, I see backwards compatibility being way overstated, particularly when it comes to source code as each release includes version-specific compiled externals, making this a moot point. Sure, there are behavioral corrections one needs to make to their patch ecosystem but I guess that is the price of progress. Think about the leap Apple did with OS9->OSX transition, and then later with G5->Intel, etc. The downside is a lot of stuff broke. The upside? They are now one of the largest company in the world that emerged from the ashes of a bankruptcy bailout. I do understand I am here correlating pd to a corporation--arguably a dubious endeavor, but only so if one fails to realize the core question:
What is more important to you: keeping backwards compatibility or moving the project forward? A question that applies to both regardless of their ostensibly orthogonal roots. Apparently, for Miller it is former (which is something I greatly respect him for), and for me it is latter.
At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing.
Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket.
True, but will that be integrated back into vanilla? It's the same problem again ...
Knowing the pd dev cycle, it is unlikely. In my last conversation with Miller, he did mention interest in porting my infinite undo and preserving stacking order (undo depends on it), so that may happen at some point. As for the rest--unlikely. And I am perfectly fine with that. Because, ultimately it is all about the productivity--if infinite undo truly makes that much of a difference, installing pd-l2ork is as easy as it gets, and the price you pay to stay within that ecosystem is potentially losing some of the backwards compatibility. Ask yourself if the shortcomings outweigh benefits and you'll have your answer. Then again, you can always use pd-vanilla/extended for your older projects as the source will be always there in perpetuity under a license you cannot refuse.
So, what does all this amount to? I guess, rather than spending time debating something that has been debated to death, if you feel so strongly about this change, feel free to join forces with the rest of the pd-l2ork devs (Jonathan is already contributing a ton)--at the very least we will do our best to merge your contributions as we've done over the past years as our dev base has grown. And who knows, maybe at some point in the future it all will get merged back. And if not, it's still a win-win proposition if this makes your life easier even if only temporarily...
HTH
Disclaimer: none of what I said was in any shape or form meant to be inflammatory. Potential efforts at starting flame wars will be left unheeded--I would much rather hack pd-l2ork code ;-)
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey lets keep on topic here. :) I'd say separating the gui and core is much less work than trying to revamp pd's threading model. Just *enabling* thirdparty GUI's that can talk to pd core as an audio and computation engine, should be possible without breaking backwards compatibility.
On 02/23/2014 08:15 PM, Ivica Bukvic wrote:
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>> wrote: Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD.If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.
Additionally, DesireData never had any stable releases as far as I remember. matju may have used it for some of his projects, but when I played around with it there were major chunks of functionality missing, and easy crashes.
If someone wanted to port over DD's keyboard-only patching feature to Pd-l2ork, for example, you'd very quickly see the difference between the two. Because once it makes it into a release you'd be using the feature in a piece of stable software. That's an enormous difference.
-Jonathan
Coming back on topic:
On Feb 23, 2014, at 8:15 PM, Ivica Bukvic ico@vt.edu wrote:
If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.
Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI.
My take on the future (and I believe Hans has brought this up as well):
If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core.
We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible.
My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too.
I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation.
Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back). pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd...
I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-)
If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name).
That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
On Sun, Feb 23, 2014 at 9:40 PM, Dan Wilcox danomatika@gmail.com wrote:
Coming back on topic:
On Feb 23, 2014, at 8:15 PM, Ivica Bukvic ico@vt.edu wrote:
If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.
Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI.
My take on the future (and I believe Hans has brought this up as well):
If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core.
We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible.
My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too.
I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation.
Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 23, 2014, at 10:46 PM, Ivica Bukvic ico@vt.edu wrote:
libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back).
Those sound like things that should/could be in the core.
pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd...
Those are objects and they can simply alias the existing objects on load, that or add an option to the core to not load existing objects / allow conditional calls the the object setup functions.
I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-)
The kernel is fragmented? Your talking distros and I see things going more Linux & BSD.
If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name).
I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.
That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.
Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.
On Sun, Feb 23, 2014 at 9:40 PM, Dan Wilcox danomatika@gmail.com wrote: Coming back on topic:
On Feb 23, 2014, at 8:15 PM, Ivica Bukvic ico@vt.edu wrote:
If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire.
Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI.
My take on the future (and I believe Hans has brought this up as well):
If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core.
We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible.
My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too.
I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation.
Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?
That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.
Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up.
If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.
And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward.
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic ico@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?
I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison.
I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this.
I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way.
That said, I would love to entertain the thought of co-developing libpd but
I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.
Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up.
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals.
I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug.
If the reality is as you say, then I'm not really interested in spending
my time hacking on our little island.
And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward.
That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours.
From: Dan Wilcox [mailto:danomatika@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic ico@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?
I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison.
But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd)
I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this.
I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way.
I am all ears :-)
That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.
Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up.
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals.
I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug.
If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.
And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward.
That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours.
I’ve said it many times and I’ll happily say it again—I have nothing but utmost respect for Miller and Miller’s work. Yet, based on my conversations with Miller, I have my doubts that there will ever be a middle ground—the goals are too divergent for one code base to meet both needs in a way that also satisfies your and my (and apparently others’) sense of urgency. That said, I’ve been proven wrong many times before, so please don’t let this stop you.
So let's just take a concrete example: "$@" syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in "the core". This is just an example-- there is a whole category of features which require changes to core code like this one.
If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it.
-Jonathan
On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic ico@vt.edu wrote:
From:Dan Wilcox [mailto:danomatika@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic ico@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?
I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up.
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.
And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward.
That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours. I’ve said it many times and I’ll happily say it again—I have nothing but utmost respect for Miller and Miller’s work. Yet, based on my conversations with Miller, I have my doubts that there will ever be a middle ground—the goals are too divergent for one code base to meet both needs in a way that also satisfies your and my (and apparently others’) sense of urgency. That said, I’ve been proven wrong many times before, so please don’t let this stop you.
Dan Wilcox danomatika.com robotcowboy.com
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd.
As we do in OpenFrameworks, I've started a PiratePad for general ideas/requirements. Feel free to add to this: http://piratepad.net/PureData-middle-ground-ideas
On Mon, Feb 24, 2014 at 2:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
So let's just take a concrete example: "$@" syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in "the core". This is just an example-- there is a whole category of features which require changes to core code like this one.
If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it.
-Jonathan
On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic ico@vt.edu wrote:
*From:* Dan Wilcox [mailto:danomatika@gmail.com] *Sent:* Monday, February 24, 2014 11:34 AM *To:* Ivica Bukvic *Cc:* Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann *Subject:* Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic ico@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?
I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison.
But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd)
I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this.
I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way.
I am all ears :-)
That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.
Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up.
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals.
I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug.
If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.
And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward.
That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours.
I’ve said it many times and I’ll happily say it again—I have nothing but utmost respect for Miller and Miller’s work. Yet, based on my conversations with Miller, I have my doubts that there will ever be a middle ground—the goals are too divergent for one code base to meet both needs in a way that also satisfies your and my (and apparently others’) sense of urgency. That said, I’ve been proven wrong many times before, so please don’t let this stop you.
-- Dan Wilcox danomatika.com robotcowboy.com
On 02/24/2014 03:03 PM, Dan Wilcox wrote:
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd.
Let's just focus on a single feature-- "$@"-- and assume that there is widespread desire for such a feature by most Pd users.
How do we put this feature into a wrapper like libpd? The only thing I can think of is as part of a patch set that get applied to core Vanilla, and that's hard to maintain.
As for working stuff into Vanilla-- that's Miller's personal version of Pd, and I've never once seen him state that it's the reference client, or that it's at the top of any hierarchy. All I've seen is passive-aggressive statements from other devs on this list who say, "You'll have to ask Miller if you want to get 'whatever' in Vanilla," when I ask about the kind of issues you're talking about. Of course I can't be certain but I'd guess that style of non-development is probably one of the biggest sources of your frustration.
But I really will help you implement whatever it is you think improves sustainable development for Pd. I really, really don't want to extract patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical changes would be fewer), but I'll help you do it if that's the path you want to take.
-Jonathan
I think Miller's puredata is awesome. more than 20 years ago I wrote my own assembly routines as well as c++ for an analog devices 32 ch board for waterplant control software , but ended up using the factory drivers instead when they came out for this software http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html. reminds me more of reaktor than puredata. I have a hard time comprehending reaktor stuff but things make so much more since using pd. I ought do dig into the programming part of pd . I read a lot of the code and it's kinda starting to sink in how to write an external, it's not quite like on the tip of my toungue yet though.
On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 02/24/2014 03:03 PM, Dan Wilcox wrote:
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd.
Let's just focus on a single feature-- "$@"-- and assume that there is widespread desire for such a feature by most Pd users.
How do we put this feature into a wrapper like libpd? The only thing I can think of is as part of a patch set that get applied to core Vanilla, and that's hard to maintain.
As for working stuff into Vanilla-- that's Miller's personal version of Pd, and I've never once seen him state that it's the reference client, or that it's at the top of any hierarchy. All I've seen is passive-aggressive statements from other devs on this list who say, "You'll have to ask Miller if you want to get 'whatever' in Vanilla," when I ask about the kind of issues you're talking about. Of course I can't be certain but I'd guess that style of non-development is probably one of the biggest sources of your frustration.
But I really will help you implement whatever it is you think improves sustainable development for Pd. I really, really don't want to extract patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical changes would be fewer), but I'll help you do it if that's the path you want to take.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Late to the party, but here are a few thoughts on the topics that have come up:
- Pd and concurrency: Audio processing must be separate from user
interaction. If you want decent latency, you need to do your audio processing on a real-time thread. On the other hand, the GUI cannot be on a real-time thread. So that's settled :P Moreover, processors haven't gotten faster in a while, but you get more and more of them. So, to stay relevant in the long run, we really want the option of multi-threaded audio processing (bonus points if we manage to squeeze in GPU support). It's not so much about existing patches that don't work well right now; it's more about patches that have never been attempted.
1a. On a related note, it would also be helpful to have support for hardware-specific optimizations such as vectorization. Right now, libpd will run anywhere (which is great), but it's optimized nowhere (which causes some users to abandon it after using it as a prototyping tool).
- Multi-instance support must happen because that's what it takes to make
plugins with libpd. I'm sure we'll see a whole cottage industry of people making Pd-based plugins when multiple instances of Pd become available. I'm also pretty sure that this change would seriously interact with a concurrency overhaul, and so those two should be done together.
- I'm sort of losing track of all the stakeholders and their agendas.
Here's a rough list of players and their agendas as I see them: * Pd Vanilla (maintain backward compatibility so that existing works won't bit-rot). * Pd Extended (get stuff done by adding lots of capabilities to Pd) * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; not sure how this relates to Pd Extended) * libpd (embed Pd into anything with a CPU) * Anyone else?
I don't think these agendas are necessarily at odds with one another. Cheers, Peter
On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner billy.stiltner@gmail.comwrote:
I think Miller's puredata is awesome. more than 20 years ago I wrote my own assembly routines as well as c++ for an analog devices 32 ch board for waterplant control software , but ended up using the factory drivers instead when they came out for this software http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html. reminds me more of reaktor than puredata. I have a hard time comprehending reaktor stuff but things make so much more since using pd. I ought do dig into the programming part of pd . I read a lot of the code and it's kinda starting to sink in how to write an external, it's not quite like on the tip of my toungue yet though.
On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 02/24/2014 03:03 PM, Dan Wilcox wrote:
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd.
Let's just focus on a single feature-- "$@"-- and assume that there is widespread desire for such a feature by most Pd users.
How do we put this feature into a wrapper like libpd? The only thing I can think of is as part of a patch set that get applied to core Vanilla, and that's hard to maintain.
As for working stuff into Vanilla-- that's Miller's personal version of Pd, and I've never once seen him state that it's the reference client, or that it's at the top of any hierarchy. All I've seen is passive-aggressive statements from other devs on this list who say, "You'll have to ask Miller if you want to get 'whatever' in Vanilla," when I ask about the kind of issues you're talking about. Of course I can't be certain but I'd guess that style of non-development is probably one of the biggest sources of your frustration.
But I really will help you implement whatever it is you think improves sustainable development for Pd. I really, really don't want to extract patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical changes would be fewer), but I'll help you do it if that's the path you want to take.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
re: ":P Moreover, processors haven't gotten faster in a while" you can say that again! I think it was 2005 I ordered the mayor of Appalachia a 3.2Ghz Intel CPU 17"laptop. My current machine is only 2.2 Ghz.
On Tue, Feb 25, 2014 at 10:41 PM, Peter Brinkmann < peter.brinkmann@googlemail.com> wrote:
Late to the party, but here are a few thoughts on the topics that have come up:
- Pd and concurrency: Audio processing must be separate from user
interaction. If you want decent latency, you need to do your audio processing on a real-time thread. On the other hand, the GUI cannot be on a real-time thread. So that's settled :P Moreover, processors haven't gotten faster in a while, but you get more and more of them. So, to stay relevant in the long run, we really want the option of multi-threaded audio processing (bonus points if we manage to squeeze in GPU support). It's not so much about existing patches that don't work well right now; it's more about patches that have never been attempted.
1a. On a related note, it would also be helpful to have support for hardware-specific optimizations such as vectorization. Right now, libpd will run anywhere (which is great), but it's optimized nowhere (which causes some users to abandon it after using it as a prototyping tool).
- Multi-instance support must happen because that's what it takes to make
plugins with libpd. I'm sure we'll see a whole cottage industry of people making Pd-based plugins when multiple instances of Pd become available. I'm also pretty sure that this change would seriously interact with a concurrency overhaul, and so those two should be done together.
- I'm sort of losing track of all the stakeholders and their agendas.
Here's a rough list of players and their agendas as I see them: * Pd Vanilla (maintain backward compatibility so that existing works won't bit-rot). * Pd Extended (get stuff done by adding lots of capabilities to Pd) * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; not sure how this relates to Pd Extended) * libpd (embed Pd into anything with a CPU) * Anyone else?
I don't think these agendas are necessarily at odds with one another. Cheers, Peter
On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner billy.stiltner@gmail.comwrote:
I think Miller's puredata is awesome. more than 20 years ago I wrote my own assembly routines as well as c++ for an analog devices 32 ch board for waterplant control software , but ended up using the factory drivers instead when they came out for this software http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html. reminds me more of reaktor than puredata. I have a hard time comprehending reaktor stuff but things make so much more since using pd. I ought do dig into the programming part of pd . I read a lot of the code and it's kinda starting to sink in how to write an external, it's not quite like on the tip of my toungue yet though.
On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes jancsika@yahoo.comwrote:
On 02/24/2014 03:03 PM, Dan Wilcox wrote:
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd.
Let's just focus on a single feature-- "$@"-- and assume that there is widespread desire for such a feature by most Pd users.
How do we put this feature into a wrapper like libpd? The only thing I can think of is as part of a patch set that get applied to core Vanilla, and that's hard to maintain.
As for working stuff into Vanilla-- that's Miller's personal version of Pd, and I've never once seen him state that it's the reference client, or that it's at the top of any hierarchy. All I've seen is passive-aggressive statements from other devs on this list who say, "You'll have to ask Miller if you want to get 'whatever' in Vanilla," when I ask about the kind of issues you're talking about. Of course I can't be certain but I'd guess that style of non-development is probably one of the biggest sources of your frustration.
But I really will help you implement whatever it is you think improves sustainable development for Pd. I really, really don't want to extract patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical changes would be fewer), but I'll help you do it if that's the path you want to take.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 26/02/2014 04:41, Peter Brinkmann a écrit :
- I'm sort of losing track of all the stakeholders and their agendas.
Here's a rough list of players and their agendas as I see them: * Pd Vanilla (maintain backward compatibility so that existing works won't bit-rot). * Pd Extended (get stuff done by adding lots of capabilities to Pd) * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; not sure how this relates to Pd Extended) * libpd (embed Pd into anything with a CPU) * Anyone else?
- pdvst (plugin for VST hosts) ?
On 02/25/2014 10:41 PM, Peter Brinkmann wrote:
Late to the party, but here are a few thoughts on the topics that have come up:
- Pd and concurrency: Audio processing must be separate from user
interaction. If you want decent latency, you need to do your audio processing on a real-time thread. On the other hand, the GUI cannot be on a real-time thread. So that's settled :P Moreover, processors haven't gotten faster in a while, but you get more and more of them. So, to stay relevant in the long run, we really want the option of multi-threaded audio processing (bonus points if we manage to squeeze in GPU support). It's not so much about existing patches that don't work well right now; it's more about patches that have never been attempted.
1a. On a related note, it would also be helpful to have support for hardware-specific optimizations such as vectorization. Right now, libpd will run anywhere (which is great), but it's optimized nowhere (which causes some users to abandon it after using it as a prototyping tool).
- Multi-instance support must happen because that's what it takes to
make plugins with libpd. I'm sure we'll see a whole cottage industry of people making Pd-based plugins when multiple instances of Pd become available. I'm also pretty sure that this change would seriously interact with a concurrency overhaul, and so those two should be done together.
- I'm sort of losing track of all the stakeholders and their agendas.
Here's a rough list of players and their agendas as I see them: * Pd Vanilla (maintain backward compatibility so that existing works won't bit-rot). * Pd Extended (get stuff done by adding lots of capabilities to Pd) * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; not sure how this relates to Pd Extended) * libpd (embed Pd into anything with a CPU) * Anyone else?
I don't think these agendas are necessarily at odds with one another.
They're not at odds explicitly because none of them-- including Miller's Vanilla-- claim to be the "core" Pd. People assume Miller's Vanilla is "upstream". But instead of saying "upstream" a new dev will erroneously ask, "How do I get 'x' into Vanilla," and a veteran dev will respond robotically without guidance, "Ask Miller." Eventually something like Dan Wilcox's frustration sets in, and potential development gets lost.
I think you've basically been able to do an end-run around the problem
with libpd up until this point. By jettisoning the GUI cruft (or,
technically speaking, ignoring it) you can base off Miller's code and
get a DSP engine and message dispatching system that's "good enough".
But it's not "upstream" in the sense of most free software communities
which have mechanisms to add missing features. I highly doubt libpd has
refrained from adding some functionality to fetch the list of args from
an abstraction because it's not worth the five minutes it'd take you to
implement that feature. I'd bet you haven't added it because, like
every other dev on the list, you know it would be a waste of your time
because Pd Vanilla doesn't work like most "upstream" repos do. Namely
a) Miller has an idea about how that feature should work, b) he doesn't
articulate what it is, c) he's never reviewed the myriad implementations
of that feature floating around in Pd-extended, and d) he won't accept
patches for that feature which have been sitting on the tracker for some
time now. This goes for a large number of feature categories-- not
everything, but enough categories to make devs wary from contributing
anything other than external libs in those categories.
So to keep this from becoming yet another copy of a previous thread in the archive, here's the thing: someone has to step up and say, "I am going to maintain 'core Pd'." That would mean listening to the needs of the community, reviewing patches, and _delegating_ responsibilities.
For example, I've got some objects in Pd-l2ork to fetch attributes of canvases, the Pd instance, and object classes. Some of the methods are stable, and some I'm still working on. But if someone said, "I am maintaining the core and am accepting patches" I'd prioritize work on those classes, test the heck out of them, and try to get as much input as possible before submitting them. And I guarantee many more Pd developers would come out of the woodwork and _ask_ to take responsibility for some other category of functionality, because it's exciting to do work when you know it's part of a larger project. If you've read the user mailing list lately you know how true this is-- there are long (recent) threads of people essentially daydreaming in detail about new directions for the software to take, without producing any code because they _know_ from experience it would just end up rotting on the tracker.
I'm not saying the "upstream" maintainer has to be you, Peter. But it has to be somebody. I'm happy to recount the details of why there's a Pd-l2ork and how it's different from Pd-extended, but if no one is willing to say they will do the work of listening, reviewing, and delegating work on an "upstream" core then we're just dancing around the real problem.
-Jonathan
Cheers, Peter
On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner <billy.stiltner@gmail.com mailto:billy.stiltner@gmail.com> wrote:
I think Miller's puredata is awesome. more than 20 years ago I wrote my own assembly routines as well as c++ for an analog devices 32 ch board for waterplant control software , but ended up using the factory drivers instead when they came out for this software http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html <http://home.comcast.net/%7Epatslabtech/Applications/seatbelt_testing.html>. reminds me more of reaktor than puredata. I have a hard time comprehending reaktor stuff but things make so much more since using pd. I ought do dig into the programming part of pd . I read a lot of the code and it's kinda starting to sink in how to write an external, it's not quite like on the tip of my toungue yet though. On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>> wrote: On 02/24/2014 03:03 PM, Dan Wilcox wrote: Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd. Let's just focus on a single feature-- "$@"-- and assume that there is widespread desire for such a feature by most Pd users. How do we put this feature into a wrapper like libpd? The only thing I can think of is as part of a patch set that get applied to core Vanilla, and that's hard to maintain. As for working stuff into Vanilla-- that's Miller's personal version of Pd, and I've never once seen him state that it's the reference client, or that it's at the top of any hierarchy. All I've seen is passive-aggressive statements from other devs on this list who say, "You'll have to ask Miller if you want to get 'whatever' in Vanilla," when I ask about the kind of issues you're talking about. Of course I can't be certain but I'd guess that style of non-development is probably one of the biggest sources of your frustration. But I really will help you implement whatever it is you think improves sustainable development for Pd. I really, really don't want to extract patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical changes would be fewer), but I'll help you do it if that's the path you want to take. -Jonathan _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So to keep this from becoming yet another copy of a previous thread in the archive, here's the thing: someone has to step up and say, "I am going to maintain 'core Pd'." That would mean listening to the needs of the community, reviewing patches, and _delegating_ responsibilities.
Yes! I really hope someone takes on the challenge. Perhaps we can crowd fund/donate/whatever some of the initial work?
IMO, Pd was such a great invention that it managed to stay rolling all these years despite of the lack of a clear path for contributors and a common upstream but the inertia is dying off now as this thread explains. It's been fascinating for me to see what has happened with OpenFrameworks and their "Do it with others" philosophy. It would be great if the Pd community would migrate into something similar.
Optimistically,
Rafael.
While it would be incredibly pretentious of me to even think about proposing pd-l2ork as an upstream standard, What I can share instead is that I welcome all submissions and as was the case with patches submitted so far we try to merge them quickly provided there are no major showstoppers. Even if there are problems, we try to work with the patch and adapt it to better conform or standards. I maintain a public priority todo list and project's primary focus is on maintaining stable environment between the releases. Similarly, if anyone is interested in seriously contributing, I'll gladly get you git access.
HTH On Feb 26, 2014 3:01 PM, "Rafael Vega" email.rafa@gmail.com wrote:
So to keep this from becoming yet another copy of a previous thread in the
archive, here's the thing: someone has to step up and say, "I am going to maintain 'core Pd'." That would mean listening to the needs of the community, reviewing patches, and _delegating_ responsibilities.
Yes! I really hope someone takes on the challenge. Perhaps we can crowd fund/donate/whatever some of the initial work?
IMO, Pd was such a great invention that it managed to stay rolling all these years despite of the lack of a clear path for contributors and a common upstream but the inertia is dying off now as this thread explains. It's been fascinating for me to see what has happened with OpenFrameworks and their "Do it with others" philosophy. It would be great if the Pd community would migrate into something similar.
Optimistically,
Rafael.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega email.rafa@gmail.com wrote:
It's been fascinating for me to see what has happened with OpenFrameworks
and their "Do it with others" philosophy. It would be great if the Pd community would migrate into something similar.
What's interesting to me is that we had a similar issue in OpenFrameworks a couple of years ago. As the community grew, more and more people wanted to contribute but there was a lack of focus and the priorities of the project were hidden by the core devs. We've had a couple of developer conferences/meetups where decisions were made on how to best handle the needs of the core people who started the project while opening up overall development to capitalize on the experience of others outside of the core group.
I must admit there were times where I wanted to fork OF or split off development in some other way, but instead I decided to knuckle down and see if we could work things out. I think it's worth a try in Pd. Even if it takes a bunch of work up front, it will be worth it in the long run.
It's been an involved social process but, overall, we are moving ahead quite well. There is a public roadmap, community action leaders (audio, 3d, graphics, linux, etc), a robust forum, etc. GitHub has been amazing helpful in this area is probably one of the main tools that makes this collaboration possible.
There have been missteps and there are still issues to resolve, but we're getting there. For instance, there will be a Documentation sprint at CMU in a few weeks.
The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 10000, it becomes unmaintainable and dies. Supposedly current pd codebase is at about 60 percent of that. That same code also lacks a lot of basic facilities like infinite undo and other core tools necessary for any kind of basic editing (given the nature of pd's structure it needs to exist inside the engine itself that is also responsible for stacking order). Features that have been added in pd-l2ork have added at least a couple of thousand lines of code with the externals and everything else obviously going well beyond that. As a result even if we prune the code and make a libpd which again implies Miller is okay with that (as in abandoning his version and building a new GUI app that interfaces with libpd), it is unknown whether we are going to be able to remain under the threshold required to meet Miller's goals. Personally I feel like Miller's wisdom should not be taken lightly but at the same time I prefer to choose the path of experimentation because it has proven so far very useful to me and therefore I would prefer to continue to run with it knowing very well that at some point in the future I just may hit a brick wall because I did not listen to his advice. In other words I am taking that risk because current benefits in my view far outweigh shortcomings and also because I expect to learn a lot in the process which will make any potential dead end look more like a crossroad. In my own work I simply do not have the luxury of time required for pd/extended to catch up with even half of the features that pd-l2ork currently offers. HTH On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega email.rafa@gmail.com wrote:
It's been fascinating for me to see what has happened with OpenFrameworks
and their "Do it with others" philosophy. It would be great if the Pd community would migrate into something similar.
What's interesting to me is that we had a similar issue in OpenFrameworks a couple of years ago. As the community grew, more and more people wanted to contribute but there was a lack of focus and the priorities of the project were hidden by the core devs. We've had a couple of developer conferences/meetups where decisions were made on how to best handle the needs of the core people who started the project while opening up overall development to capitalize on the experience of others outside of the core group.
I must admit there were times where I wanted to fork OF or split off development in some other way, but instead I decided to knuckle down and see if we could work things out. I think it's worth a try in Pd. Even if it takes a bunch of work up front, it will be worth it in the long run.
It's been an involved social process but, overall, we are moving ahead quite well. There is a public roadmap, community action leaders (audio, 3d, graphics, linux, etc), a robust forum, etc. GitHub has been amazing helpful in this area is probably one of the main tools that makes this collaboration possible.
There have been missteps and there are still issues to resolve, but we're getting there. For instance, there will be a Documentation sprint at CMU in a few weeks.
On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic ico@vt.edu wrote:
The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 10000, it becomes unmaintainable and dies.
That's why separating the GUI from the audio engine is so important. I sort of agree that 10000 lines of irreducible GUI+audio code would probably be unmaintainable. On the other hand, 5000 lines of audio code plus 5000 lines of GUI code, communicating through a smallish, well-defined interface, wouldn't be a problem at all.
What I have been doing is solidifying core features to get a better idea of what the source should look like. Separating anything beforehand will result in s lot of problems/busywork later. I would also not deceive myself that 10K lines is enough. Pd-extended is way above that when you include 3rs party externals. Ditto for pd-l2ork. On Feb 26, 2014 6:10 PM, "Peter Brinkmann" peter.brinkmann@googlemail.com wrote:
On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic ico@vt.edu wrote:
The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 10000, it becomes unmaintainable and dies.
That's why separating the GUI from the audio engine is so important. I sort of agree that 10000 lines of irreducible GUI+audio code would probably be unmaintainable. On the other hand, 5000 lines of audio code plus 5000 lines of GUI code, communicating through a smallish, well-defined interface, wouldn't be a problem at all.
HI all -
My figure was 100K lines, not 10K. PD's C code is at about 70K now, and the Tcl/TK code is 7K - so I am only adding expansions very carefully now.
Another related idea with an absurdly arbitrary round number attached: the code is built to last 50 years. It's now about 17 ywars in (1/3 of its intended lifetime.)
cheers Miller
On Wed, Feb 26, 2014 at 06:26:43PM -0500, Ivica Bukvic wrote:
What I have been doing is solidifying core features to get a better idea of what the source should look like. Separating anything beforehand will result in s lot of problems/busywork later. I would also not deceive myself that 10K lines is enough. Pd-extended is way above that when you include 3rs party externals. Ditto for pd-l2ork. On Feb 26, 2014 6:10 PM, "Peter Brinkmann" peter.brinkmann@googlemail.com wrote:
On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic ico@vt.edu wrote:
The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 10000, it becomes unmaintainable and dies.
That's why separating the GUI from the audio engine is so important. I sort of agree that 10000 lines of irreducible GUI+audio code would probably be unmaintainable. On the other hand, 5000 lines of audio code plus 5000 lines of GUI code, communicating through a smallish, well-defined interface, wouldn't be a problem at all.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Feb 26, 2014 at 6:39 PM, Miller Puckette msp@ucsd.edu wrote:
HI all -
My figure was 100K lines, not 10K. PD's C code is at about 70K now, and the Tcl/TK code is 7K - so I am only adding expansions very carefully now.
Another related idea with an absurdly arbitrary round number attached: the code is built to last 50 years. It's now about 17 ywars in (1/3 of its intended lifetime.)
Wow, that is an incredible number, and if I live that long, would love to see pd turn 50. :)
On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic ico@vt.edu wrote:
The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 10000, it becomes unmaintainable and dies. Supposedly current pd codebase is at about 60 percent of that. That same code also lacks a lot of basic facilities like infinite undo and other core tools necessary for any kind of basic editing (given the nature of pd's structure it needs to exist inside the engine itself that is also responsible for stacking order). Features that have been added in pd-l2ork have added at least a couple of thousand lines of code with the externals and everything else obviously going well beyond that.
Refactoring usually *reduces* code length, but the key to staying in sync with vanilla (and all projects that use it) is to refactor in small chunks, keeping the modifications focused.
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd b) separating GUI from core
There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.
IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.
For b) it seems like no one really knows fully what is entailed, maybe it is something that just needs to be tried as a throw away first, with say a minimal GUI in something other than tk as proof of concept.
Corollary about multi-instances and multi-thread support: while I agree thinking about them together can be useful, I think the former will only make the latter easier to take on afterwards. The smaller the changes, the easier it is to verify backwards compatibilty, and to accept into vanilla.
As a result even if we prune the code and make a libpd which again implies
Miller is okay with that (as in abandoning his version and building a new GUI app that interfaces with libpd)
I don't think anyone wants this, my understanding is that the goal is to make it where libpd does even less, by first isolating pd-core and its memory usage.
cheers, Rich
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd
b) separating GUI from core
I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app.
There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.
IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.
Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature).
it's the overhead of the os that gets in the way, i started to try ofxpd but found ofxui to be slow as all getout with my old machine. what would be nice is someone fixing tcltk
On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic ico@vt.edu wrote:
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd
b) separating GUI from core
I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app.
There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.
IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.
Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature).
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame falls elsewhere.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 28, 2014, at 3:13 AM, Billy Stiltner billy.stiltner@gmail.com wrote:
it's the overhead of the os that gets in the way, i started to try ofxpd but found ofxui to be slow as all getout with my old machine. what would be nice is someone fixing tcltk
On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic ico@vt.edu wrote:
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd
b) separating GUI from core
I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app.
There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.
IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.
Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature).
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
re: Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame falls elsewhere. on slow machines it doesnt matter what gui you use there will be problems is my point so the best thing to do is fix tcl/tk
On Fri, Feb 28, 2014 at 7:40 AM, Dan Wilcox danomatika@gmail.com wrote:
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame falls elsewhere.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 28, 2014, at 3:13 AM, Billy Stiltner billy.stiltner@gmail.com wrote:
it's the overhead of the os that gets in the way, i started to try ofxpd but found ofxui to be slow as all getout with my old machine. what would be nice is someone fixing tcltk
On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic ico@vt.edu wrote:
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd
b) separating GUI from core
I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app.
There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.
IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.
Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature).
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I fixed my wired mouse(was using hp wireless) , have 2 different keyboards laptop and desktop, still with 64 bit dual core 2.2Ghz laptop with 4Gb ram I get dropouts with xensynth even without moving the mouse. this does not happen with miniwoog_1.0 downloaded from the forum site I think. I guess I just have too many graphical objects.
On Fri, Feb 28, 2014 at 11:34 AM, Billy Stiltner billy.stiltner@gmail.comwrote:
re:
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame falls elsewhere. on slow machines it doesnt matter what gui you use there will be problems is my point so the best thing to do is fix tcl/tk
On Fri, Feb 28, 2014 at 7:40 AM, Dan Wilcox danomatika@gmail.com wrote:
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame falls elsewhere.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Feb 28, 2014, at 3:13 AM, Billy Stiltner billy.stiltner@gmail.com wrote:
it's the overhead of the os that gets in the way, i started to try ofxpd but found ofxui to be slow as all getout with my old machine. what would be nice is someone fixing tcltk
On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic ico@vt.edu wrote:
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd
b) separating GUI from core
I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app.
There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.
IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.
Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature).
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oops-- by "arguments of the parent" I mean arguments of the parent abstraction.
-Jonathan
On Monday, February 24, 2014 2:44 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
So let's just take a concrete example: "$@" syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in "the core". This is just an example-- there is a whole category of features which require changes to core code like this one.
If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it.
-Jonathan
On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic ico@vt.edu wrote:
From:Dan Wilcox [mailto:danomatika@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic ico@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomatika@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward?
I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up.
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.
And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward.
That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours. I’ve said it many times and I’ll happily say it again—I have nothing but utmost respect for Miller and Miller’s work. Yet, based on my conversations with Miller, I have my doubts that there will ever be a middle ground—the goals are too divergent for one code base to meet both needs in a way that also satisfies your and my (and apparently others’) sense of urgency. That said, I’ve been proven wrong many times before, so please don’t let this stop you.
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/13/2014 05:14 PM, Dan Wilcox wrote:
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core.
I wasn't referring to anything in particular, only in general.
Then what do you think of "$@" or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks?
Those would definitely be nice to have. I don't know what $@ refers to, is it the object arguments as a list?
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it.
Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer.
However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive):[snip]
That's all good info to know, thanks. I'd imagine libpd would't need to handle *move functions though. Does the dsp graph rely on positioning?
It does for [inlet~] and [outlet~]
And for message dispatching [inlet] and [outlet].
There are also objects like [cnv] and some externals which can use and report object position in the flow of an object chain.
I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving.
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On 13/01/2014 15:32, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
Personally I have mixed feelings about that. On the one hand the strong paradigm and attractiveness of Pd has always been the dataflow concept, and that is definitely related (and needs) some sort of GUI. Now personally I've never been concerned too much about the aesthetics of the gui as long as it enables me to make noise and supports me in experimenting with it. Nor have I ever really envied the aesthetics of other proprietary dataflow platforms which in the end are non-standard, non-native anyway..
Indeed I think in an environment like Pd, GUI has actually two aspects: dataflow (i.e. 'programming' with Pd) and control. Clearly the distinction is never clear-cut. For control I think the best solution would be to look at using external libraries (environments) which can communicate with Pd (gtk, Qt, html5, arduino, ...). There is already stuff in place like TCP, OSC, but I'm not sure it's the most friendly. Maybe Pd should have the option to expose a 'server' by default for easily doing the equivalent of a [send] or something like that without need for additional overhead? Isn't this even more relevant as people are seriously starting to experiment on Raspberry Pi and similar environments?
Just some brainstorming thoughts :)
Lorenzo.
I think that the way forward with the pd/gui separation is to work on the low hanging fruit, things that are easy to fix. Let the hard parts for later, which will only be a couple areas.
So that means looking at everywhere where sys_gui() or sys_vgui() is called, and seeing how the raw Tcl in those calls can be converted into Tcl procs. The syntax for calling Tcl procs is very close to a Pd list, so that is an easy way to get close.
The Pd dev community has always been plagued with a desire for grand plans before starting work. And that has proven to mean nothing happens.
.hc
On 13/01/2014 15:32, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
On 02/17/2014 10:48 AM, Hans-Christoph Steiner wrote:
I think that the way forward with the pd/gui separation is to work on the low hanging fruit, things that are easy to fix. Let the hard parts for later, which will only be a couple areas.
So that means looking at everywhere where sys_gui() or sys_vgui() is called, and seeing how the raw Tcl in those calls can be converted into Tcl procs. The syntax for calling Tcl procs is very close to a Pd list, so that is an easy way to get close.
The Pd dev community has always been plagued with a desire for grand plans before starting work. And that has proven to mean nothing happens.
No sane person is going to do incremental work without a plan on GUI software in 2014 that only has a single undo.
-Jonathan
.hc
On 13/01/2014 15:32, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-02-17 22:42, Jonathan Wilkes wrote:
No sane person is going to do incremental work without a plan on GUI software in 2014 that only has a single undo.
luckily the work on the GUI will most likely happen in git, which gives you infinite undo.
fmasdr IOhannes
On 02/18/2014 04:00 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-02-17 22:42, Jonathan Wilkes wrote:
No sane person is going to do incremental work without a plan on GUI software in 2014 that only has a single undo.
luckily the work on the GUI will most likely happen in git, which gives you infinite undo.
The question is whether a highly capable dev who isn't already entrenched in Pd development would see participation as worthwhile or a waste of time.
What I'm saying is that without a clear plan, no sane developer is going to undertake the work of adding infinite undo, various GUI improvements, or anything else that can't ship as an external.
But yes, technically you can use Git to do yet another GUI rewrite if you wish.
-Jonathan
fmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTAyE4AAoJELZQGcR/ejb4p20P/0v4ZnEhRhzuLBzl3Jr8bGRC FSp04pTFlgdIqYPvJJooQA2vWJPHCOcHNPI7u8kDJk3tr+1p1EQ41apK6qFw/xU5 E1093htLiZojq2OCMMO9ZOYbm0DXZZHRmo6nMcG2GXceqCSNA3OMw7p4MRGyVJB1 tS/gyckHowInGDif+3eYKSD6iTZcBFpa/QahaT9kZzTk6HQ4hRtoro5OZ/z97nj6 ILJsDv0xK01I4MF1s9OUsMdVp6itTCI9irHYOMr1IeNbhQMaZrT1z2HtqG9q8NZs Q4p6uKGtGgqIZU5noCrmLnxVde0HlirpxSIDzq+FHJ4b9dQk9pJSI+zKTE8hCs1O sCUFZNi2udd9NwkaAqs1/2msf15WO+GmguMZXzaOiOxcx9FKrVE03IATZ4vqLNCd AucU9dxohcYrqPuzzBhfxmmYk6aLwPaZpamezTeBNCni0qn25X5ZwDWY6YHnd5fO Ck1yvhWKO0g5jVH2Tx4iAgnceKVqe++q5q+XnR8goFPFvxPC3THCGoGaIx4FSgea Zcfy3VymCWByyG57K2yV2R+wr3qwK8TDligtM0XoUB+a0caYr6uq5qMnOTzOJpIt GpwrWerw1957a/ccxpkNpofh4HPosg0oeYRajc1mELY07bLcahgMaIGxIevxvub2 00RL1CEc36ySA5xLzcsd =M/8o -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey there,
i've been having this heisenbug for some time and learned to live with it, but having fixed some real bugs on my patch, this is the last one on my list and i'd like to give it a go, but no idea where to start.
symptoms are: some time into performing (20min to 1h) all the sliders, messageboxes, dials and bangs sort of get stuck, meaning they do not change their display state anymore. i can however still drag and click their active parts and their output will react accordingly, but none of this is being displayed. i should probably mention, that checkboxes still work correctly.
i had hoped it would go away moving from pd 0.42 to 0.43, but it didn't.
this is 64-bit linux (ubuntu 12.04), pd-extended (now ubuntu-package, previously self compiled from git)
speculations include: from a gut-feeling i suspect something like an input overload, ie some input shooting messsages at an insanely high rate, so the element's message queue (if there is such a thing) stops passing things on to the display.
i also suspect vjtools/videogrid as it messes with the interface, but does have a few issues, like race conditions between thumbnail creation and thumbnail display, esp if there's two of them.
hid: usb joysticks could maybe freak out and overload the interface inputs
anyway i can not see any direct connection between what i do and when it happens.
re-opening the patch doesn't help, only restarting pd does.
has anyone ever seen (something like) that? any ideas about how to debug, where to look or what to try?
thanks + cheers, ub
i had the same problems while using gem objects some time ago it was because of text2d or text3d.
you can remove some gui stuff too . replacing bng by bang for instance
and use [change] on your inputs to reduce the flow .
only suggestions , i don't remember what was the problem but i solved it
2014/1/18 ub@xdv.org ub@xdv.org
hey there,
i've been having this heisenbug for some time and learned to live with it, but having fixed some real bugs on my patch, this is the last one on my list and i'd like to give it a go, but no idea where to start.
symptoms are: some time into performing (20min to 1h) all the sliders, messageboxes, dials and bangs sort of get stuck, meaning they do not change their display state anymore. i can however still drag and click their active parts and their output will react accordingly, but none of this is being displayed. i should probably mention, that checkboxes still work correctly.
i had hoped it would go away moving from pd 0.42 to 0.43, but it didn't.
this is 64-bit linux (ubuntu 12.04), pd-extended (now ubuntu-package, previously self compiled from git)
speculations include: from a gut-feeling i suspect something like an input overload, ie some input shooting messsages at an insanely high rate, so the element's message queue (if there is such a thing) stops passing things on to the display.
i also suspect vjtools/videogrid as it messes with the interface, but does have a few issues, like race conditions between thumbnail creation and thumbnail display, esp if there's two of them.
hid: usb joysticks could maybe freak out and overload the interface inputs
anyway i can not see any direct connection between what i do and when it happens.
re-opening the patch doesn't help, only restarting pd does.
has anyone ever seen (something like) that? any ideas about how to debug, where to look or what to try?
thanks + cheers, ub
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 18.01.2014 17:07, Py Fave wrote:
i had the same problems while using gem objects some time ago it was because of text2d or text3d.
right. considered parts of gem as the culprit, but then i'm fairly sure i did experience this, before i added text2d and text3d objects and i'm hardly ever running them [0]->[gemhead]. i'll give it a shot and remove them.
you can remove some gui stuff too . replacing bng by bang for instance
since i'm using them only as indicators not buttons, that's not an option. guess i could use data strcuturs for sliders, but that probably opens a new can of worms.
and use [change] on your inputs to reduce the flow .
i'll do that!
only suggestions , i don't remember what was the problem but i solved it
good to know, someone has seen it too. thanks!
2014/1/18 ub@xdv.org mailto:ub@xdv.org <ub@xdv.org mailto:ub@xdv.org>
hey there, i've been having this heisenbug for some time and learned to live with it, but having fixed some real bugs on my patch, this is the last one on my list and i'd like to give it a go, but no idea where to start. symptoms are: some time into performing (20min to 1h) all the sliders, messageboxes, dials and bangs sort of get stuck, meaning they do not change their display state anymore. i can however still drag and click their active parts and their output will react accordingly, but none of this is being displayed. i should probably mention, that checkboxes still work correctly. i had hoped it would go away moving from pd 0.42 to 0.43, but it didn't. this is 64-bit linux (ubuntu 12.04), pd-extended (now ubuntu-package, previously self compiled from git) speculations include: from a gut-feeling i suspect something like an input overload, ie some input shooting messsages at an insanely high rate, so the element's message queue (if there is such a thing) stops passing things on to the display. i also suspect vjtools/videogrid as it messes with the interface, but does have a few issues, like race conditions between thumbnail creation and thumbnail display, esp if there's two of them. hid: usb joysticks could maybe freak out and overload the interface inputs anyway i can not see any direct connection between what i do and when it happens. re-opening the patch doesn't help, only restarting pd does. has anyone ever seen (something like) that? any ideas about how to debug, where to look or what to try? thanks + cheers, ub _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
usb/hid did this if i remember correctly.
i solved it by usind a different build or another object: [joystick] but it was on windows
i guess this is a known bug because [hid] is so useful perhaps someone has a better knowing of this .? or a workaround .
2014/1/18 ub@xdv.org ub@xdv.org
On 18.01.2014 17:07, Py Fave wrote:
i had the same problems while using gem objects some time ago it was because of text2d or text3d.
right. considered parts of gem as the culprit, but then i'm fairly sure i did experience this, before i added text2d and text3d objects and i'm hardly ever running them [0]->[gemhead]. i'll give it a shot and remove them.
you can remove some gui stuff too . replacing bng by bang for instance
since i'm using them only as indicators not buttons, that's not an option. guess i could use data strcuturs for sliders, but that probably opens a new can of worms.
and use [change] on your inputs to reduce the flow .
i'll do that!
only suggestions , i don't remember what was the problem but i solved it
good to know, someone has seen it too. thanks!
2014/1/18 ub@xdv.org mailto:ub@xdv.org <ub@xdv.org mailto:ub@xdv.org>
hey there, i've been having this heisenbug for some time and learned to live with it, but having fixed some real bugs on my patch, this is the last one on my list and i'd like to give it a go, but no idea where to start. symptoms are: some time into performing (20min to 1h) all the sliders, messageboxes, dials and bangs sort of get stuck, meaning they do not change their display state anymore. i can however still drag and click their active parts and their output will react accordingly, but none of this is being displayed. i should probably mention, that checkboxes still work correctly. i had hoped it would go away moving from pd 0.42 to 0.43, but it didn't. this is 64-bit linux (ubuntu 12.04), pd-extended (now ubuntu-package, previously self compiled from git) speculations include: from a gut-feeling i suspect something like an input overload, ie some input shooting messsages at an insanely high rate, so the element's message queue (if there is such a thing) stops passing things on to the display. i also suspect vjtools/videogrid as it messes with the interface, but does have a few issues, like race conditions between thumbnail creation and thumbnail display, esp if there's two of them. hid: usb joysticks could maybe freak out and overload the interface inputs anyway i can not see any direct connection between what i do and when it happens. re-opening the patch doesn't help, only restarting pd does. has anyone ever seen (something like) that? any ideas about how to debug, where to look or what to try? thanks + cheers, ub _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ok, first i checked and realized i had [change] to most of my hid output. so i tried without joysticks connected, [0] to [hid] and all metros off. froze the interface within seconds by quickly changing the input to vjtools/videogrid so i guess that's the object that's bugging me. i notice it does other strange things as well, like throw these errors:
image create photo imga1bbe04 -file /tmp/vigrid_4.ppm" ("uplevel" body line 1) invoked from within "uplevel #0 $cmds_from_pd".pdwindow: no such object
though it seems they appear without an interface-freeze.
also i noticed some time ago, that when you use two instances together, they use the tmp/names for the same slots. i tried to hack some sort of uniqe identifier into the filename but that didn't seem to improve things. i might give that another try ...
is there a usable alternative otherwise. i remember i saw these guys ones, which had something like videogrid, made inside pyext or so ... they said it worked absolute fine.
thanks+cheers, ub
On 18.01.2014 18:36, Py Fave wrote:
usb/hid did this if i remember correctly.
i solved it by usind a different build or another object: [joystick] but it was on windows
i guess this is a known bug because [hid] is so useful perhaps someone has a better knowing of this .? or a workaround .
2014/1/18 ub@xdv.org mailto:ub@xdv.org <ub@xdv.org mailto:ub@xdv.org>
On 18.01.2014 17:07, Py Fave wrote: i had the same problems while using gem objects some time ago it was because of text2d or text3d. right. considered parts of gem as the culprit, but then i'm fairly sure i did experience this, before i added text2d and text3d objects and i'm hardly ever running them [0]->[gemhead]. i'll give it a shot and remove them. you can remove some gui stuff too . replacing bng by bang for instance since i'm using them only as indicators not buttons, that's not an option. guess i could use data strcuturs for sliders, but that probably opens a new can of worms. and use [change] on your inputs to reduce the flow . i'll do that! only suggestions , i don't remember what was the problem but i solved it good to know, someone has seen it too. thanks! 2014/1/18 ub@xdv.org <mailto:ub@xdv.org> <mailto:ub@xdv.org <mailto:ub@xdv.org>> <ub@xdv.org <mailto:ub@xdv.org> <mailto:ub@xdv.org <mailto:ub@xdv.org>>> hey there, i've been having this heisenbug for some time and learned to live with it, but having fixed some real bugs on my patch, this is the last one on my list and i'd like to give it a go, but no idea where to start. symptoms are: some time into performing (20min to 1h) all the sliders, messageboxes, dials and bangs sort of get stuck, meaning they do not change their display state anymore. i can however still drag and click their active parts and their output will react accordingly, but none of this is being displayed. i should probably mention, that checkboxes still work correctly. i had hoped it would go away moving from pd 0.42 to 0.43, but it didn't. this is 64-bit linux (ubuntu 12.04), pd-extended (now ubuntu-package, previously self compiled from git) speculations include: from a gut-feeling i suspect something like an input overload, ie some input shooting messsages at an insanely high rate, so the element's message queue (if there is such a thing) stops passing things on to the display. i also suspect vjtools/videogrid as it messes with the interface, but does have a few issues, like race conditions between thumbnail creation and thumbnail display, esp if there's two of them. hid: usb joysticks could maybe freak out and overload the interface inputs anyway i can not see any direct connection between what i do and when it happens. re-opening the patch doesn't help, only restarting pd does. has anyone ever seen (something like) that? any ideas about how to debug, where to look or what to try? thanks + cheers, ub _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Billy Stiltner -
Charles Goyard -
Dan Wilcox -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Ivica Bukvic -
Ivica Ico Bukvic
-
Jamie Bullock -
Jonathan Wilkes -
Lorenzo Sutton -
Max -
Miller Puckette -
patrice colet -
Peter Brinkmann -
Py Fave -
Rafael Vega -
Rich E -
Simon Wise -
ub＠xdv.org