Re: [PD] libpd separating gui from core

[Billy Stiltner]

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
wrote:

> 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  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 
>> 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  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
>>>
>>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Billy Stiltner]

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  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 
> 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  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
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

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  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  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
> 
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Billy Stiltner]

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  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
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Ivica Ico Bukvic]

 

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: [PD] libpd separating gui from core

[Rich E]

On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic  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 1, 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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Wed, Feb 26, 2014 at 6:39 PM, Miller Puckette  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. :)
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Miller Puckette]

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" 
> wrote:
> 
> >
> >
> >
> > On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic  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 1, it becomes unmaintainable and dies.
> >>
> > That's why separating the GUI from the audio engine is so important. I
> > sort of agree that 1 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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Ivica Bukvic]

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" 
wrote:

>
>
>
> On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic  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 1, it becomes unmaintainable and dies.
>>
> That's why separating the GUI from the audio engine is so important. I
> sort of agree that 1 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

Re: [PD] libpd separating gui from core

[Peter Brinkmann]

On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic  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 1, it becomes unmaintainable and dies.
>
That's why separating the GUI from the audio engine is so important. I sort
of agree that 1 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

Re: [PD] libpd separating gui from core

[Ivica Bukvic]

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 1, 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  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.

-- 
Dan Wilcox
danomatika.com
robotcowboy.com

___
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: [PD] libpd separating gui from core

[Dan Wilcox]

On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega  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.

-- 
Dan Wilcox
danomatika.com
robotcowboy.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Ivica Bukvic]

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"  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
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rafael Vega]

>
> 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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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:


1. 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).


2. 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.


3. 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. 

Re: [PD] libpd separating gui from core

[IOhannes m zmölnig]

On 02/26/2014 12:53 PM, patrice colet wrote:
> * pdvst (plugin for VST hosts) ?

that's a *perfect* usecase for libpd

fgmrdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[patrice colet]

Le 26/02/2014 04:41, Peter Brinkmann a écrit :



3. 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) ?

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Billy Stiltner]

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.brinkm...@googlemail.com> wrote:

>
> Late to the party, but here are a few thoughts on the topics that have
> come up:
>
> 1. 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).
>
> 2. 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.
>
> 3. 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 
> 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.
>> 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 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
>>>
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
_

Re: [PD] libpd separating gui from core

[Peter Brinkmann]

Late to the party, but here are a few thoughts on the topics that have come
up:

1. 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).

2. 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.

3. 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 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.
> 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 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
>>
>
>
> ___
> 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: [PD] libpd separating gui from core

[Billy Stiltner]

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  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
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

Oops-- by "arguments of the parent" I mean arguments of the parent abstraction.

-Jonathan





On Monday, February 24, 2014 2:44 PM, Jonathan Wilkes  
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  wrote:
 
 
 
From:Dan Wilcox [mailto:danomat...@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  wrote:
 
>On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  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 requ

Re: [PD] libpd separating gui from core

[Dan Wilcox]

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  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 
> wrote:
>
>
> *From:* Dan Wilcox [mailto:danomat...@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  wrote:
>
>
> On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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  wrote:
 
 
 
From:Dan Wilcox [mailto:danomat...@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  wrote:
 
>On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  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

Re: [PD] libpd separating gui from core

[Ivica Ico Bukvic]

 

 

From: Dan Wilcox [mailto:danomat...@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  wrote:

 

On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  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 

Re: [PD] libpd separating gui from core

[Dan Wilcox]

On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic  wrote:

>
> On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  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.

-- 
Dan Wilcox
danomatika.com
robotcowboy.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Ivica Bukvic]

On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

On Feb 23, 2014, at 10:46 PM, Ivica Bukvic  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  wrote:
> Coming back on topic:
> 
> On Feb 23, 2014, at 8:15 PM, Ivica Bukvic  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 
> eventual

Re: [PD] libpd separating gui from core

[Ivica Bukvic]

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  wrote:

> Coming back on topic:
>
> On Feb 23, 2014, at 8:15 PM, Ivica Bukvic  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
>
>
>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

Coming back on topic:

On Feb 23, 2014, at 8:15 PM, Ivica Bukvic  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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/23/2014 08:15 PM, Ivica Bukvic wrote:




On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox > wrote:


On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes mailto:jancs...@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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Ivica Bukvic]

On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox  wrote:

> On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes  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 t

Re: [PD] libpd separating gui from core

[Dan Wilcox]

On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes  wrote:

> On 02/23/2014 07:37 AM, Dan Wilcox wrote:
>> On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes  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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jamie Bullock]

On 23 Feb 2014, at 20:29, Jonathan Wilkes  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://g.org/research/software/vibrez/

http://g.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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/23/2014 07:37 AM, Dan Wilcox wrote:

On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes  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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

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  wrote:

> Hi all - just a short note since this discussion is much too wode-ranging to
> address in full...
> 
>>> 2. 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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Miller Puckette]

Hi all - just a short note since this discussion is much too wode-ranging to
address in full...

> > 2. 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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

On Feb 23, 2014, at 12:14 PM, Max  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.
> 1. 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. 

> 2. 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.

> 3. 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 
>> 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
>> thi

Re: [PD] libpd separating gui from core

[Max]

-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.
1. Is there someone capable of completing the task?
2. Would the result of this work be accepted by Miller and become vanilla?
3. 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 
> 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-

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

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  wrote:

> On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes  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

Re: [PD] libpd separating gui from core

[Dan Wilcox]

On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes  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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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  wrote:
 





On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes  wrote:

On 02/20/2014 09:50 PM, Rich E wrote:
>
>
>>
>>
>>On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes  wrote:
>>
>>On 02/18/2014 11:11 PM, Rich E wrote:
>>>
>>>




On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  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  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.___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes  wrote:

>  On 02/20/2014 09:50 PM, Rich E wrote:
>
>
>
> On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes wrote:
>
>>   On 02/18/2014 11:11 PM, Rich E wrote:
>>
>>
>>
>>
>> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  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  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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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.

-  (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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Charles Goyard]

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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Simon Wise]

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.

-  (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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Charles Goyard]

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.

-  (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,

-- 
Charles

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/20/2014 09:50 PM, Rich E wrote:



On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes > wrote:


On 02/18/2014 11:11 PM, Rich E wrote:




On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox mailto:danomat...@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 mailto:danomat...@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.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes wrote:

>  On 02/18/2014 11:11 PM, Rich E wrote:
>
>
>
>
> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  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  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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/18/2014 11:11 PM, Rich E wrote:




On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox > 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 mailto:danomat...@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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  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  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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[IOhannes m zmoelnig]

-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
-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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Hans-Christoph Steiner]

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.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Lorenzo Sutton]

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.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 01/13/2014 05:14 PM, Dan Wilcox wrote:


On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes > 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 > 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 > 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 
robotcowboy.com 







___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

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  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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes  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  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  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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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 > 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 > 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,

Re: [PD] libpd separating gui from core

[Dan Wilcox]

Woops, forgot the reply-all.

On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes  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  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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

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 > 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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Dan Wilcox]

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  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





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list