Good point. I wasn't involved when Peter first started the project and I'm
sure, back then, multiple PD instances seemed waaay off into the future.
That's not actually what I was thinking when I was putting together the API
of libpd. My goal was simply to create the thinnest possible wrapper in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2014-02-23 20:46, Dan Wilcox wrote:
Any further updates on this front? If a consensus is made, we could
outline a roadmap and move to the task of implementation. At this
point, I think breaking externals would be less of an issue if said
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2013-12-11 20:38, Rob Bairos wrote:
Sorry, Im pretty new to this code, whats an extern in pdlib?
the same as in proper Pd: an external aka plugin that is, a
pre-compiled object loaded on-demand at runtime.
Does it make more sense for the
+1 to localizing the symbol table and dsp chain, that would be a huge step
forward towards being able to use pd as a 'plugin''.
What other things would be global other than search path? Audio and midi
settings?
cheers,
Rich
On Thu, Dec 12, 2013 at 3:49 AM, IOhannes m zmoelnig
why would you make audio settings global?
in our particular setup each 'plugin / node' etc has an arbitrary number of
inputs/outputs/sample rate.
On Thu, Dec 12, 2013 at 12:31 PM, Rich E reakina...@gmail.com wrote:
+1 to localizing the symbol table and dsp chain, that would be a huge step
On Thu, Dec 12, 2013 at 1:16 PM, Rob Bairos r...@derivative.ca wrote:
why would you make audio settings global?
in our particular setup each 'plugin / node' etc has an arbitrary number
of inputs/outputs/sample rate.
I wouldn't, but I think they might already be. I was asking what other
vars
Oh, but for sending messages between instances, you would have to queue
the messages, and then it starts to get complicated..
I think sticking to independent instances with no shared arrays/etc would
be a great first step.
The idea of throwing all statis/externs into a data structure wouldn't
Sorry for the delay.
#1 I agree. Seems like a workaround. Ultimately it should be clear in the
source code when a static is meant to be shared across threads or not.
Seems like something that could be properly implemented in the future?
#2 Sounds good, but Im not familiar with which
Well, I think #1 (making statics per-thread) is only necessary on the
assumtion that you want Pd running simultaneously in multiple threads;
otherwise it would accomplish nothing. I'm not sure but I guess the overhead
would be the same as the one-structure solution (which is essentially how,
I
On Wed, Dec 11, 2013 at 3:55 AM, Miller Puckette m...@ucsd.edu wrote:
I'm liking the idea of simply localizing symbols and the DSP chain more
and more as I think about it... it's nice and self-contained and I think it
would help things a lot from what I'm hearing.
Perhaps I misunderstand
On Wed, Dec 11, 2013 at 8:52 AM, Kjetil Matheussen
k.s.matheus...@gmail.com wrote:
On Wed, Dec 11, 2013 at 3:55 AM, Miller Puckette m...@ucsd.edu wrote:
I'm liking the idea of simply localizing symbols and the DSP chain more
and more as I think about it... it's nice and self-contained and I
Hi Miller,
Idea #1 sounds quite good, except that it sounds hacky
and that performance might go down notifiable because
of thread switching. The extra amount of code necessary
to switch threads doesn't sound like too much work.
So I like idea #2 much better. The limitation of only one
DSP chain
Excellent plan.
In my branch of libpd on Github, I've solved the Pd multiple
instances problem by letting the linker take care of separating
the global variables. However, using the linker causing various
problems, such as making it very difficult to load externals,
and it should probably also be
13 matches
Mail list logo
