Hallo,
Andy Farnell hat gesagt: // Andy Farnell wrote:
i) Dynamic DSP graph reconfiguration. The ability to seamlessly (no clicks or
dropouts) create and destroy graph elements and garbage collect on the fly.
ii) Through a supported (official and documented) message passing system
iii)
On Thu, Feb 14, 2008 at 10:40 AM, Andy Farnell [EMAIL PROTECTED]
wrote:
i) Dynamic DSP graph reconfiguration. The ability to seamlessly (no clicks
or
dropouts) create and destroy graph elements and garbage collect on the
fly.
ii) Through a supported (official and documented) message
Hello Pablo, list,
Let's differentiate two issues,
1) To use Pd as a sample replay based game audio engine
2) To use Pd as a procedural audio engine (synthesis).
These are different tasks with different goals and challenges. The latter is my
domain of expertise and something, for me;
i) Very
On Thu, 14 Feb 2008 17:52:59 +0100
Frank Barknecht [EMAIL PROTECTED] wrote:
Hallo,
Andy Farnell hat gesagt: // Andy Farnell wrote:
i) Dynamic DSP graph reconfiguration. The ability to seamlessly (no clicks
or
dropouts) create and destroy graph elements and garbage collect on the fly.
Hmmm, so far we have suggestions to use Lua and SC :)
There are many good reasons to choose other languages.
Csound - history, stability, SAOL encapsualtion
Nyquist (LISP) lends itself well to parallelism
SC - instance management/polyphony, recursion
But let's focus on Pd since this is Pd
Hi!
Chris McCormick escribió:
(...)
Which seems to vaguely work, although I haven't made it make a sound
yet. Anyway, I think this could be a good strategy for tying Pd into
Blender. I would suggest running Pd in a separate thread and using a
mutexed queue to pass it messages which would
hi!
marius schebella escribió:
Patrice Colet wrote:
marius schebella a écrit :
It would be great to have python modules that ease the communication
between Blender and PureData, with FUDI or OSCx!
why do you want to run all communication through python? or do you mean
on
Part of the trouble is that only one instance of Pd can live in any
given address space (because of widespread use of static variables).
This is fine for linking Pd into a video game where you'd only want
one instance, but if you want multiple ones you'd want to sprout separate
Pd processes with
Yes, but... why doesnt pd already export some kind of library? In a way
it sucks that such a powerful engine is trapped inside a binary in that
way, a good library would allow embedding in better ways, as well as
ease experiments like desiredata or any others that might follow (thats
my opinion at
Hans-Christoph Steiner escribió:
On Feb 11, 2008, at 9:55 AM, Pablo Martin wrote:
Andy Farnell escribió:
Hey Pablo,
Yes it is feasible. So Apricot is to use Pd?
Well its still being decided, and most team know nothing about pd, so
they are a bit reluctant to accept this
On Tue, Feb 12, 2008 at 11:03:13AM +0100, Pablo Martin wrote:
Mmmm, not so sure what you mean (i suppose the pd internal scheduler?),
but i guess the whole thing could be put in a thread maybe... don't know
why but it's always seemed like it good be a good idea to have pd as a
library (after
Patrice Colet wrote:
marius schebella a écrit :
hi,... I am not sure how easy the whole thing is. you for example will
want to do all the sound/driver settings from within the game, which
means pd has to be able to change this by sending commands. as far as
I know this is not possible with
marius schebella a écrit :
hi,... I am not sure how easy the whole thing is. you
for example will want to do all the sound/driver settings from within
the game, which means pd has to be able to change this by sending
commands. as far as I know this is not possible with current core pd.
It
No -- there ought to be, but it never makes it to the top of the
priority heap.
M
On Tue, Feb 12, 2008 at 01:30:11PM -0500, marius schebella wrote:
that sounds promising!
maybe still a little too ambitious for someone who does not know the pd
source at all (aka me). is there an overall
that sounds promising!
maybe still a little too ambitious for someone who does not know the pd
source at all (aka me). is there an overall introductory explanation of
how the various source codes components work together besides the source
code and in code documentation itself?
marius.
Miller
Pdvst, by Joe Sarlo, does something related (embeds Pd as a VST plug-in;
windows only). It uses the Pd executable, plugging in a user-supplied
scheduler that manages audio and control I/O to the calling program.
Since there might be several Pdvst plug-ins active at a time, each gets
its own
hi,
I want to help with that project. I would have spend time on research
and development into that direction also without the apricot game (for
school), and was looking for a possibility like this. so the combination
with blender and working on a real project is perfect. who is
coordinating
Hi!
Blender foundation together with crystalspace community just started
making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and
maybe also some more cool stuff), but I think it'd be important to be
able to have puredata as a library
On Feb 11, 2008, at 9:55 AM, Pablo Martin wrote:
Andy Farnell escribió:
Hey Pablo,
Yes it is feasible. So Apricot is to use Pd?
Well its still being decided, and most team know nothing about pd, so
they are a bit reluctant to accept this kind of risks... though they
also understand some
Andy Farnell escribió:
Hey Pablo,
Yes it is feasible. So Apricot is to use Pd?
Well its still being decided, and most team know nothing about pd, so
they are a bit reluctant to accept this kind of risks... though they
also understand some of the good parts, but of course i think it would
Hey Pablo,
Yes it is feasible. So Apricot is to use Pd?
You literally caught me walking out the door for a few days off.
So I'll get back to this discussion Thursday.
I've pretty much got an object for every sound you need in a game
including detailed parameterisation and some already with
21 matches
Mail list logo
