I am a bit confused how to use the plugin~ source code from the CVS repo: http://pure-data.cvs.sourceforge.net/pure-data/externals/plugin~/
There's no configure or makefile there.
I feel like I'm seeing the same (maybe older?) code at:
ftp://iem.kug.ac.at/pd/Externals/PLUGIN/
and this code builds fine. Am I missing something?
-John
If you have the whole Pd-extended sources, you could "make flatspace"
and it'll show up in externals/build/src/plugin~.pd_linux.
.hc
On Dec 3, 2006, at 12:51 PM, John Harrison wrote:
I am a bit confused how to use the plugin~ source code from the CVS
repo: http://pure-data.cvs.sourceforge.net/pure-data/externals/plugin~/There's no configure or makefile there.
I feel like I'm seeing the same (maybe older?) code at:
ftp://iem.kug.ac.at/pd/Externals/PLUGIN/
and this code builds fine. Am I missing something?
-John
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
FYI, I just enabled the building of [plugin~] on Mac OS X. So it
should be included in nightly builds and upcoming test and final
releases.
.hc
On Dec 3, 2006, at 12:51 PM, John Harrison wrote:
I am a bit confused how to use the plugin~ source code from the CVS
repo: http://pure-data.cvs.sourceforge.net/pure-data/externals/plugin~/There's no configure or makefile there.
I feel like I'm seeing the same (maybe older?) code at:
ftp://iem.kug.ac.at/pd/Externals/PLUGIN/
and this code builds fine. Am I missing something?
-John
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Dec 5, 2006, at 11:14 AM, Hans-Christoph Steiner wrote:
FYI, I just enabled the building of [plugin~] on Mac OS X. So it
should be included in nightly builds and upcoming test and final
releases.
...this sounds good, but what will this build of [plugin~] do on
OSX? The problem has with this external has not been "can it
compile" but rather "which plugin does it support?", because it
compiles as VST on some systems, and LADSPA on others...
...I've never gotten the VST version to work on OSX, but the LADSPA
is easy enough, if you have LADSPA installed system wide on the
machine: any ideas on making LADSPA portable in the app package?
jamie
On Dec 5, 2006, at 1:28 PM, james tittle wrote:
On Dec 5, 2006, at 11:14 AM, Hans-Christoph Steiner wrote:
FYI, I just enabled the building of [plugin~] on Mac OS X. So it
should be included in nightly builds and upcoming test and final
releases....this sounds good, but what will this build of [plugin~] do on
OSX? The problem has with this external has not been "can it
compile" but rather "which plugin does it support?", because it
compiles as VST on some systems, and LADSPA on others......I've never gotten the VST version to work on OSX, but the LADSPA
is easy enough, if you have LADSPA installed system wide on the
machine: any ideas on making LADSPA portable in the app package?
It builds with LADSPA. LADSPA is in Fink, and one of the last steps
of the Pd-extended.app build process is to grab all dependencies from
Fink and add them to the Pd-extended.app. So LADSPA plugins should
"just work" AFAIK (look at Pd-extended.app/Contents/lib to see what's
included). otool doesn't list any LADSPA libs, so I guess its
statically linked or something.
It loads in last night's autobuild, but I don't have any LADSPA
plugins to test with:
http://autobuild.puredata.info
.hc
Access to computers should be unlimited and total. - the hacker ethic
Hi Hans,
On Tue, 2006-12-05 at 11:14 -0500, Hans-Christoph Steiner wrote:
FYI, I just enabled the building of [plugin~] on Mac OS X. So it
should be included in nightly builds and upcoming test and final
releases.
Any chance of getting [dssi~] included in this? It has an additional dependency on the liblo library, but it builds and works fine on both linux and Mac OS (powerpc and intel).
The advantages of [dssi~] over [plugin~] are
- It supports DSSI plugins as well as LADSPA
- It can host multiple plugin instances within a single [dssi~]
instance e.g. [dssi~ sine_faaa 20] for 20 sine oscillators.
It doesn't do VST but other than that the functionality of plugin~ is a subset of the functionality of dssi~.
Jamie
On Dec 6, 2006, at 9:15 AM, Jamie Bullock wrote:
Hi Hans,
On Tue, 2006-12-05 at 11:14 -0500, Hans-Christoph Steiner wrote:
FYI, I just enabled the building of [plugin~] on Mac OS X. So it should be included in nightly builds and upcoming test and final releases.
Any chance of getting [dssi~] included in this? It has an additional dependency on the liblo library, but it builds and works fine on both linux and Mac OS (powerpc and intel).
The advantages of [dssi~] over [plugin~] are
- It supports DSSI plugins as well as LADSPA
- It can host multiple plugin instances within a single [dssi~]
instance e.g. [dssi~ sine_faaa 20] for 20 sine oscillators.
It doesn't do VST but other than that the functionality of plugin~
is a subset of the functionality of dssi~.
Sure, if you do the work. I think the issue was that the DSSI code
would have to be maintained in the pure-data CVS, which some people
strongly protested. DSSI isn't in Fink. In order for it to be
supported in the auto-builds and Pd-extended packages on Mac OS X,
the code either needs to be in CVS or Fink, or included in the OS.
You could just make a libdir package, then people could use DSSI with
plain pd too (with the libdir external).
.hc
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
-
Hans-Christoph Steiner -
james tittle -
Jamie Bullock -
John Harrison