Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 usi

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 concern

Re: [PD] libpd separating gui from core

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 sta

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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:

Re: [PD] libpd separating gui from core

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/

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 l

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 thre

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 Extende

Re: [PD] libpd separating gui from core

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:

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 t

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

gt; 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] lib

Re: [PD] libpd separating gui from core

: 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

Re: [PD] libpd separating gui from core

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

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

Re: [PD] libpd separating gui from core

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 you

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 t

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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!

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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,

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

-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

Re: [PD] libpd separating gui from core

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-

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 eve

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 pr

Re: [PD] libpd separating gui from core

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 cre

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 g

Re: [PD] libpd separating gui from core

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 obj

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 mos

Re: [PD] libpd separating gui from core

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 th

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 w

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 s

Re: [PD] libpd separating gui from core

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-- $@ an

Re: [PD] libpd separating gui from core

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 devel

Re: [PD] libpd separating gui from core

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

Re: [PD] libpd separating gui from core

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 separa

Re: [PD] libpd separating gui from core

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 sa