I plan to update the help file for pix_video before hans gets
the next extended out the door.
cheers,
tim
On 22/08/2007, at 9:58 AM, Olivier Heinry wrote:
Le mardi 21 août 2007 à 22:49 +0200, Tim Boykett a écrit :
Apologies for a slight stuff up, The suggestion I made here, I now
notice
Tim Blechmann wrote:
With the small exception that, as Hans mentioned, two cores will be of
benefit because the graphics process can run on its own core.
the benefit is that minimal, that it's hardly worth mentioning ... just
run your favorite patch and look at the used cpu time ...
Hi,
im trying to create a subpatch like the colored boxes of the patch i attach
(open _KINOKO.pd).
These are my steps:
I create an object called [pd c]. A new pd window appears.
Inside this new window I create an [inlet] and an [outlet] object and i
press the second button of my mouse and
On Tuesday 21 August 2007 22:25, Tim Blechmann wrote:
i somehow doubt, that i would make sense to use a jackdmp-style
multicore scheduling algorithm for a max/pd/nova dsp graph, which can
easily contain thousands of nodes (jack graphs are usually rather
small), because of the scheduling
On Wednesday 22 August 2007 13:18, Mathieu Bouchard wrote:
making DS and pointers work again.
The reason I ended up abandoning data structures was, as far as I could see,
the only way to get data from them was by polling them. Which I found
ridiculous.
I found it was much easier and less
Tim Boykett schrieb:
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made.
with the message
|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
It should be documented in the help patch though ...
One of the limitations with the Pd DSP chain *is* it's style of
modularity. The stream is broken down into indivisible blocks. The
tree is parallel at the top, but as you go down the tree, it becomes
more and more serial. There would be a bottleneck, where the parallel
processes aren't
Tim Boykett schrieb:
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made.
with the message
|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
I should be documented in the help patch though ...
That's too bad. I'll take your word for it that jackdmp wouldn't be
able to manage the inter-process connection in a scalable way -- I'm not
familiar with how it works. I'm disappointed, because it sounded like a
cheap (and yes, slightly inconvenient -- but better than nothing) way to
Le mardi 21 août 2007 à 22:49 +0200, Tim Boykett a écrit :
Apologies for a slight stuff up,
The suggestion I made here, I now notice deep in the source, has been
made.
with the message
|device /dev/dv1394/0(
to pix_video I could have made this work all those days ago.
Cheers,
On Tue, 21 Aug 2007, Robert Scott wrote:
So following this pattern, will 0.42 be a compatibility-breaking
redesign replacing insane messages with LISP-like lists of lists and
atoms?
In DesireData, as soon as I'm done reprogramming the GOP feature (which
has been dragging for a while and is
On Mon, 20 Aug 2007, Tim Blechmann wrote:
On Sun, 2007-08-19 at 11:09 -0700, Miller Puckette wrote:
Resizing large memory objects in a real-time thread can block as the
OS pages other memory out to disk... so the operation is never safe
unless done in a separate thread.
what's the problem
Le mercredi 22 août 2007 à 00:40 +0200, Javier García a écrit :
Hi,
im trying to create a subpatch like the colored boxes of the patch i attach
(open _KINOKO.pd).
These are my steps:
I create an object called [pd c]. A new pd window appears.
Inside this new window I create an
Hallo,
Robert Scott hat gesagt: // Robert Scott wrote:
So following this pattern, will 0.42 be a compatibility-breaking redesign
replacing insane messages with LISP-like lists of lists and atoms?
I think, with the introduction of the [list] object family, many more
LISP-like list operations
On 8/21/07, Tim Blechmann [EMAIL PROTECTED] wrote:
to make use of a multicore machine the only way to utilize all cores
is
to run several instances of pd, that are connected via jackdmp.
Now *there's* an idea. Would that really work? What would be the
downside -- aside from the
Hallo,
Matthias Blau hat gesagt: // Matthias Blau wrote:
after playing around with debian etch I can't get pd to pop up the gui
anymore, pd -verbose just tells me it is using port 5400 and
Waiting for connection request... and doesn't do anything.
Googling around told me that there
Hello,
I'm starting to use puredata recently,
and I'd like to know if there exists a simple way to put a real-time
mirror of the canvas into a gem window, for example, to overlay the
images I want to display with the puredata objects I use to generate them.
Someone told me in max/msp there is
17 matches
Mail list logo
