Hi everyone,
I just read the recent thread regarding the plugin~ external, and the regrettable problems Kim was having getting a working plugin in host in Pd.
One of the problems here is that plugin~ has a subset of the functionality of dssi~, but yet the 2 projects are still maintained in parallel, with AFAICT no real advantage.
I can only guess the reasons dssi~ is not now the de facto standard for LADSPA and DSSI hosting in Pd:
- it has a dependency on liblo
- people assume that dssi~ only hosts DSSI plugins, not realising that DSSI is built on LADSPA?
So I propose the following solutions:
- I refactor dssi~ to use the iemnet/mrpeach externals for OSC communications (thus removing the liblo dependency)
- I rename dssi~ to pluginhost~ with a view to extending it to other plugin APIs (VST?) at some later point.
- I include a better help file/documentation (Frank?)
Any thoughts on this?
Finally, can I strongly encourage anyone who finds bugs and/or problems with dssi~ to contact me directly, since I read the list infrequently and am much more likely to respond and offer help quickly if I get direct email.
best,
Jamie
Sounds like a good plan. I was unaware of the difference between
plugin~ and dssi~. The last piece of the equation is distributing
easy-to-use binaries and making it easy to load and use plugins :)
.hc
On Jun 20, 2010, at 8:57 AM, Jamie Bullock wrote:
Hi everyone,
I just read the recent thread regarding the plugin~ external, and
the regrettable problems Kim was having getting a working plugin in
host in Pd.One of the problems here is that plugin~ has a subset of the
functionality of dssi~, but yet the 2 projects are still maintained
in parallel, with AFAICT no real advantage.I can only guess the reasons dssi~ is not now the de facto standard
for LADSPA and DSSI hosting in Pd:
- it has a dependency on liblo
- people assume that dssi~ only hosts DSSI plugins, not realising
that DSSI is built on LADSPA?
So I propose the following solutions:
- I refactor dssi~ to use the iemnet/mrpeach externals for OSC
communications (thus removing the liblo dependency)
- I rename dssi~ to pluginhost~ with a view to extending it to
other plugin APIs (VST?) at some later point.
- I include a better help file/documentation (Frank?)
Any thoughts on this?
Finally, can I strongly encourage anyone who finds bugs and/or
problems with dssi~ to contact me directly, since I read the list
infrequently and am much more likely to respond and offer help
quickly if I get direct email.best,
Jamie
-- http://www.jamiebullock.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)
Jamie Bullock wrote:
Hi everyone,
I just read the recent thread regarding the plugin~ external, and the regrettable problems Kim was having getting a working plugin in host in Pd.
Jamie no worries! I was finally able to figure it out with the help of the list and again want to thank all who contributed to the dicussion on how [plugin~] and some other externals are supposed to work
one of my aims here was not only to use the external myself (I'm moving some of my old Max/MSP patches forward to Pd) but also to help write a short tutorial for it on the FOSS Pd manual http://en.flossmanuals.net/bin/view/PureData/UsingLADSPAplugins
One of the problems here is that plugin~ has a subset of the functionality of dssi~, but yet the 2 projects are still maintained in parallel, with AFAICT no real advantage.
I can only guess the reasons dssi~ is not now the de facto standard for LADSPA and DSSI hosting in Pd:
- it has a dependency on liblo
- people assume that dssi~ only hosts DSSI plugins, not realising that DSSI is built on LADSPA?
So I propose the following solutions:
- I refactor dssi~ to use the iemnet/mrpeach externals for OSC communications (thus removing the liblo dependency)
- I rename dssi~ to pluginhost~ with a view to extending it to other plugin APIs (VST?) at some later point.
- I include a better help file/documentation (Frank?)
Any thoughts on this?
Finally, can I strongly encourage anyone who finds bugs and/or problems with dssi~ to contact me directly,
I am also interested in writing a [dssi~] external tutorial but don't have the bandwidth until next week or so... but if you have any more recent updated code I'd be happy to compile it and give it a spin I'm on 32 bit Ubuntu :)
since I read the list infrequently and am much more likely to respond and offer help quickly if I get direct email.
best,
Jamie
-
Hans-Christoph Steiner -
Jamie Bullock -
Kim Cascone