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
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 i...@vt.edu wrote:
For instance, it seems like there are two
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame
falls elsewhere.
enohp ym morf tnes
--
Dan Wilcox
danomatika.com
robotcowboy.com
On Feb 28, 2014, at 3:13 AM, Billy Stiltner billy.stilt...@gmail.com wrote:
it's the overhead of the os that gets in the
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 danomat...@gmail.com 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
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
17laptop. My current machine is only 2.2 Ghz.
On Tue, Feb 25, 2014 at 10:41 PM, Peter Brinkmann
peter.brinkm...@googlemail.com wrote:
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
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
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
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
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
On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega email.r...@gmail.com wrote:
It's been fascinating for me to see what has happened with OpenFrameworks
and their Do it with others philosophy. It would be great if the Pd
community would migrate into something similar.
What's interesting to me is
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
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
On Wed, Feb 26, 2014 at 6:39 PM, Miller Puckette m...@ucsd.edu wrote:
HI all -
My figure was 100K lines, not 10K. PD's C code is at about 70K now, and
the
Tcl/TK code is 7K - so I am only adding expansions very carefully now.
Another related idea with an absurdly arbitrary round number
On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic i...@vt.edu wrote:
The reason why I believe combining all of these will not be feasible is
because in one of my recent conversations with Miller (and Miller please
correct me if I somehow misremember here) he expressed his belief any
project that
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
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely
Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is
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 i...@vt.edu wrote
; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely
Pd-vanilla
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 i...@vt.edu wrote:
On Sun, Feb 23
Bukvic i...@vt.edu 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 i...@vt.edu
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
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current
single-threaded implementation that would be measurably improved by using a
multi-threaded approach?
Ask any of the people who have to run two instances of
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
-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
On Feb 23, 2014, at 12:14 PM, Max abonneme...@revolwear.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ok, Dan, i can feel you there. but let's not mix up the GUI-core
separation with the GEM on OS X question. As much as their
consequences are similar, they are fundamentally
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
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
On 02/23/2014 07:37 AM, Dan Wilcox wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current
single-threaded implementation that would be measurably improved by using a
multi-threaded approach?
Ask any of
On 23 Feb 2014, at 20:29, Jonathan Wilkes jancs...@yahoo.com wrote:
Things maybe acceptable to us PD grey beards, but at some point it would
be nice to find a way to enter the modern, multicore multithreaded world.
Moores law has shifted from clock speed to just add more cores years ago
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 02/23/2014 07:37 AM, Dan Wilcox wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current
single-threaded implementation that would
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com wrote:
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes 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
Hey lets keep on topic here. :) I'd say separating the gui and core is much
less work than trying to revamp pd's threading model. Just *enabling*
thirdparty
GUI's that can talk to pd core as an audio and computation engine, should
be possible without breaking backwards compatibility.
On 02/23/2014 08:15 PM, Ivica Bukvic wrote:
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com
mailto:danomat...@gmail.com wrote:
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
Yeah, stuff like that we should be
Coming back on topic:
On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote:
If I may chime in for a sec (pd-l2ork author here), there is absolutely no
interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already
has thousands of lines of code either altered or added
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
On Feb 23, 2014, at 10:46 PM, Ivica Bukvic i...@vt.edu wrote:
libpd requires a lot of what pd-l2ork offers in order to be able to move
forward (obeying stacking order for instance, that are a prerequisite for
global system-wide presets as well as editing tools like undo/redo and
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely
Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is pd-vanilla +
externals + most limitations of the vanilla. How does
On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.comwrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox
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
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com
mailto:danomat...@gmail.com
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
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.
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
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
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.comwrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how
it determines execution order
-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
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox 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 danomat...@gmail.com wrote:
Does the
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
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com
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
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
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()
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
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
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
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps
solve the PD gui development doesn't move fast enough problem in the long
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 jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to
perhaps solve
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
Sorry, I don't know quite what you're referring to here. The only two
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 danomat...@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd
On 01/13/2014 05:14 PM, Dan Wilcox wrote:
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com
61 matches
Mail list logo
