[PD-dev] including [dssi~] in Pd-extended

[Kyle Klipowicz]

An interesting inversion to this topic is the one of using _Pd_ as a
plugin within a host device.  I know there's jsarlo's pdvst, but
that's windows only and is less of a "plug in" solution as it is a
"open up the fuse box and rewire your house" kind of solution.  This
is not an insult, but more of a statement of my own stupidity
regarding these things.

Again, I'm not a coder and can't judge or say much on the dev list,
but I would love to be able to use Pd inside of other software, and
others would too (those of us who are too impatient to build our own
state-saving, non-crashing, graphical sequencers).

A preliminary (and un-thorough) search on google shows little
documentation of direct vst or audio unit wrappers for dssi and ladspa
plugins.  Would the best effort be to make a vst wrapper for
ladspa/dssi, and then try to make pd available as a ladspa/dssi plugin
in its own right?  This might appeal more to the hardcore GNU/Linux
crowd, since they use these tools anyway, and then some lucky soul
(not me unless I magically learn a shitload of coding skills) could
simply make ladspa/dssi available to the other OSes.

My only other idea would be to petition someone like Ableton to make
an open api based on bsd-liscensed Pd code so that people could
program Live extensions with it (which would be _sweet_).

What are your thoughts on this?

~Kyle

On 3/19/06, james tittle <tigital at mac.com> wrote:
> On Mar 18, 2006, at 7:23 PM, Hans-Christoph Steiner wrote:
> > On Mar 18, 2006, at 7:15 PM, Frank Barknecht wrote:
> >> We do need to draw a line somewhere about what to include in a Pd
> >> distribution and what to leave out. Every software package has to
> >> decide such things, Max has to, Pd has to, Ardour has to, Firefox has
> >> to. And I would draw that line when it comes to plugins. DSSI and
> >> LADSPA are well defined interfaces that were designed with the main
> >> goal in mind, that plugin authors and the authors of plugin host
> >> software should be able to work independently. Including plugins in
> >> the Pd CVS would defy that underlying idea of DSSI and LADSPA.
> >
> > What I don't understand with this whole thread is how is anyone
> > harmed if the plugin source code is included?  Ok, in theory, its a
> > plugin and meant to be standalone, but in practice its just a piece
> > of code like any other.
>
> ...here we're talking about two audio plugins:  would you want to
> include a selection of vst plugins where source is available?  How
> about extending this to freeframe video plugins, which are supported
> by both GEM and PDP?  I think it's enough to have the plugin loader,
> and then let the user find out about where to get plugins via a
> helpfile...
>
> > There is a real harm in not including them: people won't use them
> > because of the large hurdle in getting them running.  And that to
> > me is sad since most code is written for people to use.
>
> ...other than the harm of bloat and extended compiles and
> packagings...I think a better way to get over the "large hurdle" of
> placing plugins in the correct place for use would be to follow what
> Iohannes has done with Gem's freeframe and shader/program loading
> code:  make it search the paths that pd already looks into, like
> loading any other patch...it works very nicely, and would be a good
> addition to the ladpsa loaders...
>
> > When I include code in Pd-extended, I make sure its works on Mac OS
> > X, GNU/Linux, and Windows.  I would do the same for any plugin
> > source that I included.  Just look at Pd-0.38.4-extended.  I am not
> > saying there aren't problems with it, but look at the situation
> > before.
>
> ...you have done a great job with pd-extended, but you can't expect
> to cover all bases on such an open ended system, nor should you want
> to:  it'll just never happen...
>
> > That's my final two bits, I've spent too much time on this topic...
>
> ...yes, please, move on...
>
> james
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>


--
http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())())))
(())))))(()))))))))))))(((((((((((()()))))))))((())))
))(((((((((((())))())))))))))))))))__________
_____())))))(((((((((((((()))))))))))_______
((((((())))))))))))((((((((000)))oOOOOOO