Hi Jerome,
The idea to put -lib vst~ before -lib cyclone is a little bit strange. How should I know that ? Is it show somewhere ? a place where I've not been.
the reason for this is that cyclone defines its own vst~ object (because it wants to provide all possible Max/MSP objects, although it's just a dummy, non-functioning thing then). By loading the vst~ before cyclone you can be sure that cyclone's dummy object doesn't get loaded before the "real" vst~. Btw., on the list there are discussions going on about how to solve this name-clash problem for PD in a generic manner.
best greetings, Thomas
Hi! Did some tests with some SynthEdit made VSTi (done by OdO)...they works pretty well... the only things is seems that we miss the feature to send VSTTimeInfo to the plugs loaded in [vst~] that's very important!....the MaxMSP's [vst~] has the same problem.... Is there a way to send midi data out the [vst~] to other pd objects? If not i think this is would be great .... i'm happy to know other vst~/pd experiences thanx lalo
Hi Lalo,
the only things is seems that we miss the feature to send VSTTimeInfo to the plugs loaded in [vst~] that's very important!....the MaxMSP's [vst~] has the same problem....
hmmm, never thought of that but i'll have a look.
Is there a way to send midi data out the [vst~] to other pd objects?
There's no midi out at the moment, but there should be.... Can you name a vst plugin that sends midi data?
best greetings, Thomas
Thanx for the quick reply Thomas! There's a lot of plugs around that deal with midi out...for example a lot of stuff from Tobybear ( http://www.tobybear.de ), check out his nice (and freeware/donationware) midibag suite... there's a lot of Synthedit made stuf too ;) ... oh...do you think will be possible to do a version of your [vst~] for maxmsp too?...using flext? thanx lalo p.s. : these are a few suggestins i made to the maxmsp community...maybe you they can help you
- provide full VSTTimeInfo to [vst~] ...it's a class in VSTSDK
providing all tempo information to plug-ins
(start/stop/transport/bar position/beat/ticks/sampleposition/etc...)
if to give pd a "classic" vst host implementation is not the
case...i have in mind another strategy....
do a kind of [vsthost~] object wich provide all the vst event
known ..it's inlets could be bpm, time signature, start, stop, and
inlets to receive info from other time-related max objects as
[metro], [timer] etc.
it's outlets could be a kind of "vstevent" one...to be passed to
a new [vst~] inlet called i.e. "vstevent".....the [vst~] could have
a "vstevent" outlet too to pass it's received or
internal-generated vstevents.
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
By loading the vst~ before cyclone you can be sure that cyclone's dummy object doesn't get loaded before the "real" vst~. Btw., on the list there are discussions going on about how to solve this name-clash problem for PD in a generic manner.
This is a special case in this regard, because it's not a nameclash with a real external in cyclone, but with a generated dummy.
One solution for Cyclone is to only load cyclone as a library (-lib cyclone) if you want to import Max patches. Other than that don't load the cyclone lib, especially not in .pdrc
Ciao
Frank Barknecht _ ______footils.org__
Thomas Grill wrote:
Btw., on the list there are discussions going on about how to solve this name-clash problem for PD in a generic manner.
proposal:
add the possibility to load externals from inside a patch ( load <external> )
put every external in a name space by default (cyclone.vst~)
possibility to load externals in another name space ( load <external> as <namespace name> )
possibility to load only one object from an external library ( load <object> from <external> ) ( load * from <external>
to remain compatibility the -lib parameter could load the externals as usual.
i think that loading externals at startup without the possibility to load externals later condtradicts the visual on-the-fly programming.
is there are reason not load externals from inside a patch?
i feel that Pd has the biggest flaws with it usability and loading of externals is one of the greatest sources of frustration. (i have to admit that usability of PD vastly improved over the last years, especially with the windows installers and the linux packages for the externals).
addition: the name spaces stuff should apply to abstractions (patches), too. maybe i'm influnced to much by python :-)
smoerk wrote:
Thomas Grill wrote:
Btw., on the list there are discussions going on about how to solve this name-clash problem for PD in a generic manner.
proposal:
add the possibility to load externals from inside a patch ( load <external> )
put every external in a name space by default (cyclone.vst~)
possibility to load externals in another name space ( load <external> as <namespace name> )
possibility to load only one object from an external library ( load <object> from <external> ) ( load * from <external>
to remain compatibility the -lib parameter could load the externals as usual.
i think that loading externals at startup without the possibility to load externals later condtradicts the visual on-the-fly programming.
is there are reason not load externals from inside a patch?
i feel that Pd has the biggest flaws with it usability and loading of externals is one of the greatest sources of frustration. (i have to admit that usability of PD vastly improved over the last years, especially with the windows installers and the linux packages for the externals).
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
hi,
smoerk said: addition: the name spaces stuff should apply to abstractions (patches), too. maybe i'm influnced to much by python :-)
addition to the addition: also for the help patches. for instance append from Pd and Append from cyclone both look for the same named help-patch. marius.
hi all,
I am very sorry for causing trouble this way. Back in May, I have already renamed vst~ dummy to c74.vst~, along with some other classes never going to be part of cyclone. For changes finding their way into installers, etc, some time is always needed, though...
Perhaps, I have to accept the fact, that people prefer using -lib cyclone, instead of single classes, or hammer/sickle duo, and make them load the dummies library per request.
Krzysztof
Thomas Grill wrote: ...
the reason for this is that cyclone defines its own vst~ object (because it wants to provide all possible Max/MSP objects, although it's just a dummy, non-functioning thing then).
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
I am very sorry for causing trouble this way. Back in May, I have already renamed vst~ dummy to c74.vst~, along with some other classes never going to be part of cyclone. For changes finding their way into installers, etc, some time is always needed, though...
Perhaps, I have to accept the fact, that people prefer using -lib cyclone, instead of single classes, or hammer/sickle duo, and make them load the dummies library per request.
Well, it's not a fault of Cyclone. As you may remember I was bitten by the dummy replacement of plugin~, because I was loading cyclone as a library. I only did this to overcome the prepend nameclash with iemlib: Loading Cyclone as library allowed me to overwrite the prepend in iemlib, which also had to be loaded as library.
However thanks to Hans-Christoph's effort to split out the iem-externals into single externals I now can use practically every external needed for my (rradical) patches as single externals. The exceptions are OSC and zexy, but to my knowledge they have no clashes, so this is fine with me. (I don't use Gem normally.)
I can only recommend everyone to use the externals in the CVS-build system. They solve a huge number of possible nameclash problems and keep the .pdrc short and clean.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Krzysztof Czaja -
lalo -
marius schebella -
smoerk -
Thomas Grill