Hi guys! Is the vst~ a finished project? i mean can i send/recieve midi/audio from/to VST/VSTi in puredata? Are multiple in/outs implemented? thanx lalo
i found this on http://devdsp.net/index.pl?main=categories&category=48
PD vst~ is Dead by koolym on 2002-06-21 08:01:32
Pure-Data.org reports Mark Williamson's vst~ object (that lets you run VST effects and instruments from within PD) has officially been declared dead. The reason? Mark doesn't have enough time to maintain it properly.It seems to be yanked from pure-data.org's download page as well. If you nevertheless want it, you'll have to get it from SourceForge and compile it yourself.
Which, I can attest to, isn't the easiest thing in the world to do when you're on Windows. Getting MSVC++ to output anything other than regular Windows apps is a royal pain in the butt.
lalo wrote:
Hi guys! Is the vst~ a finished project? i mean can i send/recieve midi/audio from/to VST/VSTi in puredata? Are multiple in/outs implemented? thanx lalo
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
well, that's an issue i also can't quite understand. because i think vst-plugin support is a much-asked feature of any audio application.
plus, there's actually a working "vst~.dll" i got one year ago from thomas grill. he's now working on it but still hasn't officially published a compiled .dll, you can only cvs and compile it yourself...
thomas, why is this still so ? the vst~.dll works perfect and never crashed (some GUI windows didn't show, though...), so i guess that nobody would be offended by a downloadable beta .dll that works this good. even if it's not working 100%, still its a damn good start and would make many newbie users of PD happy. why keeping it secret ? are there any copyright reasons ?
ciao
oliver
Quoting smoerk smoerk@gmx.de:
i found this on http://devdsp.net/index.pl?main=categories&category=48
PD vst~ is Dead by koolym on 2002-06-21 08:01:32
Pure-Data.org reports Mark Williamson's vst~ object (that lets you run VST effects and instruments from within PD) has officially been declared dead. The reason? Mark doesn't have enough time to maintain it properly.It seems to be yanked from pure-data.org's download page as well. If you nevertheless want it, you'll have to get it from SourceForge and compile it yourself.
Which, I can attest to, isn't the easiest thing in the world to do when you're on Windows. Getting MSVC++ to output anything other than regular Windows apps is a royal pain in the butt.
lalo wrote:
Hi guys! Is the vst~ a finished project? i mean can i send/recieve midi/audio from/to VST/VSTi in puredata? Are multiple in/outs implemented? thanx lalo
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
sent through klingt.org webmail
plus, there's actually a working "vst~.dll" i got one year ago from thomas grill. he's now working on it but still hasn't officially published a compiled .dll, you can only cvs and compile it yourself...
a highly unofficial, but pretty recent vst~ (along with 520 other extras) at http://whats-your.name/pd/extra/ , thanks to whoever made the exellent CVS build system...
thomas, why is this still so ? the vst~.dll works perfect and never crashed
it crashes quite easily, i think almost exclusively due to a mismatch of the specified # of in/outs vs the amount the plugin actualy wants to claim. plugin~ also loads VSTs, and somehow magically resizes to fit the plugins preferred io slots. i might try bringing this over to vst~ since otherwise it seems vastly more feature-complete (unless i missed a help file somewhere..)
i guess the main usablity thing that has me using pdVST and another host for normal plugins, is the convenience of an 'insert rack'..is it possible to easily construct something of this sort to automagically cable-in vst~ or other audio abstractions/externals in general?
hello,
a highly unofficial, but pretty recent vst~ (along with 520 other extras) at http://whats-your.name/pd/extra/ , thanks to whoever made the exellent CVS build system...
very nice collection. could it be possible to have a compressed file of all this stuff?
thanks Cyrille
thomas, why is this still so ? the vst~.dll works perfect and never crashed
it crashes quite easily, i think almost exclusively due to a mismatch of the specified # of in/outs vs the amount the plugin actualy wants to claim. plugin~ also loads VSTs, and somehow magically resizes to fit the plugins preferred io slots. i might try bringing this over to vst~ since otherwise it seems vastly more feature-complete (unless i missed a help file somewhere..)
i guess the main usablity thing that has me using pdVST and another host for normal plugins, is the convenience of an 'insert rack'..is it possible to easily construct something of this sort to automagically cable-in vst~ or other audio abstractions/externals in general?
#N canvas 126 601 359 302 10; #X msg 102 99 note $1 100; #X floatatom 134 75 5 0 0 0 - - -; #X obj 56 264 dac~; #X obj 133 187 print; #X obj 137 61 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X msg 22 122 plug $1; #X obj 19 80 bng 25 250 50 0 empty empty empty 0 -6 0 8 -225271 -1 -1; #X obj 21 105 openpanel; #X msg 164 99 noteoff $1; #X obj 34 228 spigot~; #X obj 101 213 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X msg 175 124 getparams; #X obj 239 120 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 185 169 ro 8 1; #X obj 187 147 route params; #X msg 185 189 param $1 $2; #X obj 267 60 random 128; #X obj 267 29 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X floatatom 222 171 5 0 0 0 - - -; #X obj 267 43 metro 200; #X obj 70 187 *~ 0.5; #X obj 34 187 *~ 0.5; #X obj 76 142 vst~ 0 2; #X obj 100 173 hsl 49 9 0 1 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X msg 76 125 edit 1; #X obj 10 3 notein 1; #X obj 10 20 pack; #X obj 56 3 bendin; #X msg 56 20 pbend $1; #X msg 10 37 note $1 $2; #X msg 102 37 ctlchg $2 $1; #X obj 102 20 pack; #X obj 102 3 ctlin; #X obj 200 50 hsl 64 11 10 4000 0 0 empty empty empty -2 -6 0 8 -262144 -1 -1 0 1; #X obj 164 82 pipe 400; #X obj 71 228 spigot~; #X connect 0 0 22 0; #X connect 1 0 0 0; #X connect 1 0 34 0; #X connect 4 0 1 0; #X connect 5 0 22 0; #X connect 6 0 7 0; #X connect 7 0 5 0; #X connect 8 0 22 0; #X connect 9 0 2 0; #X connect 9 1 2 0; #X connect 9 1 2 1; #X connect 10 0 9 1; #X connect 10 0 35 1; #X connect 11 0 22 0; #X connect 12 0 13 0; #X connect 13 0 15 0; #X connect 14 0 13 1; #X connect 14 0 18 0; #X connect 15 0 22 0; #X connect 16 0 4 0; #X connect 17 0 19 0; #X connect 19 0 16 0; #X connect 20 0 35 0; #X connect 21 0 9 0; #X connect 22 0 21 0; #X connect 22 1 20 0; #X connect 22 2 3 0; #X connect 22 2 14 0; #X connect 23 0 20 1; #X connect 23 0 21 1; #X connect 24 0 22 0; #X connect 25 0 26 0; #X connect 25 1 26 1; #X connect 26 0 29 0; #X connect 27 0 28 0; #X connect 28 0 22 0; #X connect 29 0 22 0; #X connect 30 0 22 0; #X connect 31 0 30 0; #X connect 32 0 31 0; #X connect 32 1 31 1; #X connect 33 0 34 1; #X connect 34 0 8 0; #X connect 35 0 2 1;
#N canvas 564 574 218 244 12; #X obj 49 74 until; #X obj 72 93 - 1; #X obj 49 54 t f f; #X obj 49 93 i; #X obj 34 194 pack f f; #X obj 49 120 t f b; #X obj 34 215 outlet; #X obj 49 13 inlet; #X obj 49 34 f $1; #X obj 100 104 f $2; #X obj 100 84 loadbang; #X obj 69 152 random; #X obj 158 84 inlet; #X obj 100 124 * 1e+007; #X obj 69 172 / 1e+007; #X obj 100 16 inlet; #X connect 0 0 3 0; #X connect 1 0 3 1; #X connect 1 0 5 0; #X connect 2 0 0 0; #X connect 2 1 3 1; #X connect 3 0 1 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 5 1 11 0; #X connect 7 0 8 0; #X connect 8 0 2 0; #X connect 9 0 13 0; #X connect 10 0 9 0; #X connect 11 0 14 0; #X connect 12 0 13 0; #X connect 13 0 11 1; #X connect 14 0 4 1; #X connect 15 0 8 1;
it crashes quite easily, i think almost exclusively due to a mismatch of
the specified # of in/outs vs the amount the plugin actualy wants to claim. plugin~ also loads VSTs, and somehow magically resizes to fit the plugins preferred io slots. i might try bringing this over to vst~ since otherwise it seems vastly more feature-complete (unless i missed a help file somewhere..)
Thanks for the reports, i'll look into it. The help file should be right there in cvs....
best, Thomas
Hi Carmen,
thomas, why is this still so ? the vst~.dll works perfect and never
crashed
it crashes quite easily, i think almost exclusively due to a mismatch of
the specified # of in/outs vs the amount the plugin actualy wants to claim.
I would really appreciate if could you give me an example of a crashy situation (plugin and number of ins/outs)? I can't get it crashing with my plugins here.
plugin~ also loads VSTs, and somehow magically resizes to fit the plugins
preferred io slots. i might try bringing this over to vst~ since otherwise it seems vastly more feature-complete (unless i missed a help file somewhere..)
As far as i know, adapting the number of inlets/outlets to a number of IO slots would only be possible if the plugin name were fixed, which is not what we/i want.
best greetings, Thomas
Hey all, vst~ is not a secret, it's in cvs. It seems that also the Steinberg copyright issues have become better due to the efforts of the FST project. The problem is that it always takes some time to make a release package and i use to do that when things have been tested to some extent. The last time someone mentioned the need for vst~ on the list i posted a call for vst~ test reports of all kinds of available plugins. I didn't get one single reply - that can mean that either nobody uses vst~ or it's not working at all or it's working perfectly. So here again... i'd appreciate _very_ much reports of vst~ with all kinds of plugins - perfectly working/somehow working (details) /not working at all (errors?). The other reason for not publishing a binary was a change in the architecture, so that a OSX version (and maybe linux FST version) can follow. I'll upload a binary shortly.
please test and report, best greetings, Thomas
well, that's an issue i also can't quite understand. because i think
vst-plugin
support is a much-asked feature of any audio application.
plus, there's actually a working "vst~.dll" i got one year ago from thomas grill. he's now working on it but still hasn't officially published a
compiled
.dll, you can only cvs and compile it yourself...
thomas, why is this still so ? the vst~.dll works perfect and never
crashed
(some GUI windows didn't show, though...), so i guess that nobody would be offended by a downloadable beta .dll that works this good. even if it's
not
working 100%, still its a damn good start and would make many newbie users
of
PD happy. why keeping it secret ? are there any copyright reasons ?
Thomas Grill wrote:
Hey all, vst~ is not a secret, it's in cvs. It seems that also the Steinberg copyright issues have become better due to the efforts of the FST project. The problem is that it always takes some time to make a release package and i use to do that when things have been tested to some extent. The last time someone mentioned the need for vst~ on the list i posted a call for vst~ test reports of all kinds of available plugins. I didn't get one single reply - that can mean that either nobody uses vst~ or it's not working at all or it's working perfectly. So here again... i'd appreciate _very_ much reports of vst~ with all kinds of plugins - perfectly working/somehow working (details) /not working at all (errors?). The other reason for not publishing a binary was a change in the architecture, so that a OSX version (and maybe linux FST version) can follow. I'll upload a binary shortly.
i'll test it then and put comments on http://pd.iem.at/pdwiki/index.php?Vst~ (and post it to the list)
of course that "news" is more than 2 years old. as stotz mentioned, thomas grill has taken over vst~ dev and the version of the dll i have works wonderfully. my brother is planning to get new releases of the pd installers out pretty soon, it should have a somewhat recent build of it (along with the rest of cvs)
-josh
smoerk wrote:
i found this on http://devdsp.net/index.pl?main=categories&category=48
PD vst~ is Dead by koolym on 2002-06-21 08:01:32
Pure-Data.org reports Mark Williamson's vst~ object (that lets you run VST effects and instruments from within PD) has officially been declared dead. The reason? Mark doesn't have enough time to maintain it properly.It seems to be yanked from pure-data.org's download page as well. If you nevertheless want it, you'll have to get it from SourceForge and compile it yourself.
Which, I can attest to, isn't the easiest thing in the world to do when you're on Windows. Getting MSVC++ to output anything other than regular Windows apps is a royal pain in the butt.
lalo wrote:
Hi guys! Is the vst~ a finished project? i mean can i send/recieve midi/audio from/to VST/VSTi in puredata? Are multiple in/outs implemented? thanx lalo
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list