Forums > MaxMSP

Vst~ prayer

February 17, 2006 | 10:09 pm

Does anyone know if there will ever be a vst~ object accepting sync information ?

Will it be available in a comming release of MSP ?


February 17, 2006 | 11:04 pm

> Does anyone know if there will ever be a vst~ object accepting sync information ?

what would it be good for?
you can use vst~ only in MAXMSP which does not
have any VST implementation. 8|


February 17, 2006 | 11:12 pm

You could PRAY!

;-)


February 18, 2006 | 1:51 am

What do you mean sync information? something like Smpte?
T


February 18, 2006 | 2:27 am

The ability for vst~ to deal with host sync will be supported in some way in a future version of MaxMSP.

It is always interesting to me that despite numerous calls for this feature, noone has ever speculated on how the systems which would support such a thing might best be implemented. We have had a bunch of internal conversations about it, maybe some people might have ideas as well.

For instance, It seems to me that it’s mostly useless for vst~ to have an idea of host sync if the idea of host sync is not incorporated in the patch in some some way which could be shared ( or not ) with other vst~s. This leads us to the idea of global or local tempi, the possiblity of either new objects for dealing with tempi or a modification of the current ones etc. etc…….

-A


February 18, 2006 | 7:27 am

interesting discussion :)
i would provide a kind of tempo-master object that can propagate in the whole patch…(with start/stop, bpm, ppq, and samplepos information…

another great idea would be to add to the pluggo oriented object collection a plugsynctohost~ object… so a pluggo can give tempo info to the host….would be very useful to use pluggos in other modular enviroments as bidule :)

lalo


February 18, 2006 | 11:30 am

I was thinking something like one additional inlet to the vst~ object, where u could supply a phasor~, like you would use plugphasor~ when building pluggo…

It should also be possible to supply beats, bars, ticks, timesig, etc….. like the opposite of the plugsync~/plugphasor~
objects…

a optional master tempo supplied by max would also be a great idea ! nice for building frameworks and sharing patches…


February 18, 2006 | 12:35 pm

On Feb 18, 2006, at 12:04 AM, Roman Thilenius wrote:

>
>
>> Does anyone know if there will ever be a vst~ object accepting sync
>> information ?
>
> what would it be good for?

http://mdsp.smartelectronix.com/2005/07/livecut-08-summer-be ta-
preview.php

http://www.instajungle.com/

http://www.soniccharge.com/products

http://bram.smartelectronix.com/plugins.php?id=6

p


February 18, 2006 | 1:16 pm

> It is always interesting to me that despite numerous calls > > for this feature, noone has ever speculated on how the systems > which would support such a thing might best be implemented.

if there is any solution then it is something
based on signals and not the sheduler. :)

it is a bit stupid though when you have a vst~ object
which supports a variant of hostsync which isnt
identically with VST host sync, isnt it?
what i mean by this is … no VST plug-in would support
"MAX host sync" anyway, there are only plug-ins which
support VST host sync.

how does vst~ takes VST parameter value changes?
right, as lists. you guys at cycling are clever people
but i dont think you will manage to give us objects
which can create lists of messages in signal form.

VST in cubase isnt a signal either, just very high
priority messages.

one last thought.
maybe thats just me, but if i had a waves plug-in
open in MAX and the plug-in has an LFO which supports
VST host sync, i would just ignore it and build my own
LFO in MAX, sync it to my MAX stuff like i want it to be,
and send the parameter value changes to vst~ the regular
way.

… whats VST plug-in anyway?


February 19, 2006 | 12:08 pm

I really don’t understand why there is any need to have this "implemented". What vst in particular are you hoping to have utilize this? …if you don’t mind me asking. [some sort of stepsequencer?]…

I really don’t see why this is so difficult to get around, there are so many ways of getting time information into maxmsp. It’s not really a "sequencer" type program, but it certainly has the tools to cut whatever time information you have coming in into whatever you need it to be.


February 19, 2006 | 12:18 pm

come on guys…

to provoke a little bit…

if no VSTTimeInfo is needed why is vst~ needed…

everything we could think of can be implemented in max/msp…

the whole problem is to integrate max/msp with other prexisting stuff that one may use in his workflow…

why have one to do a 303-like stuff in max where there are freeware vst around?

so if there is a vst~ to me it should be the max/msp way….

powerful and…complete

lalo


February 19, 2006 | 12:55 pm

Quote: lalo wrote on Sun, 19 February 2006 04:18
—————————————————-
> come on guys…
>
> to provoke a little bit…
>
> if no VSTTimeInfo is needed why is vst~ needed…
>
> everything we could think of can be implemented in max/msp…
>
> the whole problem is to integrate max/msp with other prexisting stuff that one may use in his workflow…
>
> why have one to do a 303-like stuff in max where there are freeware vst around?
>
> so if there is a vst~ to me it should be the max/msp way….
>
> powerful and…complete
>
> lalo
—————————————————-

AMEN! Thats what I’m saying. I have built environments that take time information out of whatever, hardware/software and piped it into max via midi/osc/netsend, etc… Granted, I don’t know where everyone else is with their maxing abilities and such, so it needs to be said with a grain of salt.

Anyways, the point is that putting something like this in max is relatively pointless, but, possibly at this point the answer to what you’re looking for just hasn’t made itself known due to whatever route you’re on. Max is capable of doing it, just keep learning ;0


February 19, 2006 | 5:20 pm

At 4:08 AM -0800 2/19/06, bine~ wrote:
>I really don’t understand why there is any need to have this
>"implemented". What vst in particular are you hoping to have
>utilize this? …if you don’t mind me asking. [some sort of
>stepsequencer?]…

A good starting list has already been posted, here it is again:

http://mdsp.smartelectronix.com/2005/07/livecut-08-summer-be ta-preview.php

http://www.instajungle.com/

http://www.soniccharge.com/products

http://bram.smartelectronix.com/plugins.php?id=6

But this is just a start — there are tens if not hundreds of VST
plugs now, on both PC and Mac, that require VSTTimeInfo data to be
support all of their functions.

>I really don’t see why this is so difficult to get around, there are
>so many ways of getting time information into maxmsp.

Right – but you can’t get that time information *into* certain VST
plugs because of the current limitation… And in so doing, you
cripple certain plugin’s functionality.

In my opinion, it’s a severe limitation in Max/MSP’s ability to host VST plugs.

Dan

>It’s not really a "sequencer" type program, but it certainly has the
>tools to cut whatever time information you have coming in into
>whatever you need it to be.


Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com

http://www.jackosx.com


February 19, 2006 | 9:42 pm

Quote: Dan Nigrin wrote on Sun, 19 February 2006 10:20
—————————————————-
>
>
> In my opinion, it’s a severe limitation in Max/MSP’s ability to host VST plugs.
>

yesss…amen ;)


February 19, 2006 | 10:58 pm

"Right – but you can’t get that time information *into* certain VST
plugs because of the current limitation… And in so doing, you
cripple certain plugin’s functionality.

In my opinion, it’s a severe limitation in Max/MSP’s ability to host VST plugs."

Who says thats a bad thing ;) .. I mean, come on, you gotta have a vst object to test pluggo plugins out on anyways. Its a good object and is pretty much an essential part of our library of functions. Max isn’t designed to be a sequencer, so I doubt your vsttimeinfo is ever going to exist, but I can see why you want it now. Maybe host/plug sync can start generating vsttimeinfo as well invisibly or so. that would be cool :)


February 19, 2006 | 11:55 pm

how can we test in max/msp pluggo stuff that needs VSTTimeInfo? …lol

…bidule isn’t a sequencer in the traditional way but it supports VSTTimeInfo in both direction host->plug and plug->host

lalo


February 20, 2006 | 9:17 am

Quote: bine~ wrote on Sun, 19 February 2006 15:58
—————————————————-
> Who says thats a bad thing ;) .. I mean, come on, you gotta have a vst object to test pluggo plugins out on anyways. Its a good object and is pretty much an essential part of our library of functions. Max isn’t designed to be a sequencer, so I doubt your vsttimeinfo is ever going to exist, but I can see why you want it now. Maybe host/plug sync can start generating vsttimeinfo as well invisibly or so. that would be cool :)
—————————————————-

U can build sequencers in Max….now there is even the new ICE library, which is ment for this purpose…..but even if u just want to make a simple step-sequencer it would be nice to have the ability to create "fake" VST-TimeInfo and feed it to VST~ !
Max deals with all kind of data, so this is of course possible to implement.

I’m having a hard time understanding, that someone thinks this would be a useless feature…..I think it’s a very big issue….i like vst’s, and would love the ability to sync them to the rest of my system…..i don’t really want to re-invent a nice plugin like livecut or Glitch, when someone already did it better then i could !


February 20, 2006 | 9:25 am

Quote: geek74@gmail.com wrote on Mon, 20 February 2006 02:17
—————————————————-
…..i don’t really want to re-invent a nice plugin like livecut or Glitch, when someone already did it better then i could !
—————————————————-

exactly…totally agree…

i would be very interested in the opportunity to have an object for pluggo export that gives VSTTimeInfo to the host

imagine i do a buffer realted thing exported as a pluggo vst…

ideally i record external audio to the buffer and try to retrive tempo information from sample duration and or peak recognizing in the buffer itself….

lalo


February 20, 2006 | 1:35 pm

> In my opinion, it’s a severe limitation in Max/MSP’s
> ability to host VST plugs.

maybe the error about geek s request is that MAXMSP
is not hosting the plug-ins; it is the vst~ object
which is hosting plug-ins.

i am afraid that when this request is fullfilled the
next guy comes and asks for 64-bit support, because he
thinks vst~ got to have everything VST has :)

mind you that using plug-ins in MAXMSP today allows
you things like directly talking to the plug-ins
parameters, a function which not even programs like
emagic logic support.


February 20, 2006 | 1:43 pm

> i would be very interested in the opportunity to have an object for pluggo export that gives VSTTimeInfo to the host
>
> imagine i do a buffer realted thing exported as a pluggo vst…

VST is not doing that either i think.
time info is a host thing.

you can do your buffer releated things with plugsync~
just fine, and add your custom SMPTE or frame count
display to the GUI when you really need to have modulation
functions longer than 16 bars.


February 20, 2006 | 1:49 pm

Quote: Roman Thilenius wrote on Mon, 20 February 2006 06:43
—————————————————-
>
> > i would be very interested in the opportunity to have an object for pluggo export that gives VSTTimeInfo to the host
> >
> > imagine i do a buffer realted thing exported as a pluggo vst…
>
>
> VST is not doing that either i think.
> time info is a host thing.
>
> you can do your buffer releated things with plugsync~
> just fine, and add your custom SMPTE or frame count
> display to the GUI when you really need to have modulation
> functions longer than 16 bars.
—————————————————-

come on roman…if i say this i say after some reasearch and experience…
VSTTimeInfo works in both direction…host->plug and plug->host
..
check bidule out if you don’t believe me…
or check a SynthEdit module by Chris Kerry (TapTempo) wich does exacly this…
you can build plug in that can send VSTTimeInfo to the host (for the hosts that support the entire VST sdk..like bidule does…

but maybe is too simple stuff for top max/msp scientists ’round here?… just joking :)

lalo


February 20, 2006 | 6:14 pm

Quote: Dan Nigrin wrote on Sun, 19 February 2006 10:20
—————————————————-
> Right – but you can’t get that time information *into* certain VST
> plugs because of the current limitation… And in so doing, you
> cripple certain plugin’s functionality.

Amen again!

Even being able to feed a tempo to certain plug-ins, without a tight "sync" (as regards phase position within a measure), would be a step in the right direction.

Leigh


February 20, 2006 | 10:23 pm

> > Who says thats a bad thing ;) .. I mean, come on,
> you gotta > have a vst object to test pluggo plugins
> out on anyways.

maybe that is just me but i find making pluggos
for use in MAX pointless, i make mine for use in
cubase or portools.

> want to make a simple step-sequencer it would be
> nice to have >the ability to create "fake" VST-TimeInfo
> and >feed it to VST~ !
> Max deals with all kind of data, so this is of course
> possible to implement.

mabye that is just me, but i find VST time info
event generation in the max runtime pointless, because
syncronisation is something very timecritical.

> I’m having a hard time understanding, that someone
thinks this would be a useless feature…..I think it’s
a very big issue….i like vst’s, and would love the
ability to sync them to the rest of my system…..

maybe the truth lies somewhere in the middle.
there are several – but not milions – plug-ins which make
use of hostsync.

in danger of repeating myself (or beeing accused of
steinberg promotion):
if you want a full VST enviroment buy SX/nuendo.

-plug-in #110 (the natural enemy of all hosts)


February 20, 2006 | 10:40 pm

Quote: lalo wrote on Mon, 20 February 2006 06:49
—————————————————-
> Quote: Roman Thilenius wrote on Mon, 20 February 2006 06:43
> —————————————————-
> >
> > > i would be very interested in the opportunity to have an object for pluggo export that gives VSTTimeInfo to the host
> > >
> > > imagine i do a buffer realted thing exported as a pluggo vst…
> >
> >
> > VST is not doing that either i think.
> > time info is a host thing.
> >
> > you can do your buffer releated things with plugsync~
> > just fine, and add your custom SMPTE or frame count
> > display to the GUI when you really need to have modulation
> > functions longer than 16 bars.
> —————————————————-
>
> come on roman…if i say this i say after some reasearch and experience…
> VSTTimeInfo works in both direction…host->plug and plug->host

ok let me rephrase.
:)

.. "is a thing you only find in "normal" host programs."

which the vst~object isnt.

i dont know how to say that better but humh … MAX
does not have a vst implementation like bidule.

where would you start making VstTimeInfo in the runtime?
it will have to depend on some kind of major clock.

a timeline? and what if you have more than one?

the signalling? then lets talk about the IO vector
size of the runtime.

sending messages from a metro/counter? forget it.

> check bidule out if you don’t believe me…
> or check a SynthEdit module by Chris Kerry (TapTempo)
> wich does exacly this…

you can guess my opinion about tapping onto a plug
in order to change the speed of a sequencer. :P

what in MAX you would like to control by tapping onto
such a plug-in? the non existing major timeline of the
frontmost patch???

-VstTimeInfo::tempo 110/2 = NaN


February 21, 2006 | 8:15 am

The big idea is not building pluggos for use in max…i could make them sync anyways, using send~ & receive~….the idea is using other plugins in max…

I dont believe this is impossible to implement… How about writing a method for providing VSTTimeInfo, then you woulden’t have to create the sync info using something stupid like metro->counter…..

This method could be it’s own object (VSTime~), and should be synched to something like a phasor or clicktrack…it could accept messages like "goto 4 2" to make the VSTTime goto to any bar/beat position….but it should calculate all the time info from a single signal.

Then the vst~ object could be modified to tap into whatever named VSTime~ object…


February 21, 2006 | 8:21 am

Quote: geek74@gmail.com wrote on Tue, 21 February 2006 01:15
—————————————————-
> The big idea is not building pluggos for use in max…i could make them sync anyways, using send~ & receive~….the idea is using other plugins in max…
>
> I dont believe this is impossible to implement… How about writing a method for providing VSTTimeInfo, then you woulden’t have to create the sync info using something stupid like metro->counter…..
>
> This method could be it’s own object (VSTime~), and should be synched to something like a phasor or clicktrack…it could accept messages like "goto 4 2" to make the VSTTime goto to any bar/beat position….but it should calculate all the time info from a single signal.
>
> Then the vst~ object could be modified to tap into whatever named VSTime~ object…
—————————————————-

totally agree…seems a very good strategy :)


February 21, 2006 | 12:32 pm

I think this starts to get to the question that originally started
this thread – around potentially having a central time "master", that
could send/receive its signals anywhere (including VSTTimeInfo).

Agree it would be a good idea.

Dan

Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com

http://www.jackosx.com


February 21, 2006 | 2:38 pm

> This method could be it’s own object (VSTime~)

exactly, that seems to be the only way it could work.


February 22, 2006 | 12:21 am


February 22, 2006 | 10:40 am

On around Feb 22, 2006, at 1:21, pure@test.at, quoting Miller S.
Puckette:
> Max is a graphical music programming environment for people who have
> hit the limits of the usual sequencer and voicing programs for MIDI
> equipment.

In other words, Max is designed for people who *don’t* want to do what
you do with the usual sequencer and voicing programs…

IOW, Max is not another sequencer.

That’s the way I’ve read for the past 18 years or so. Both Miller and
DDZ have confirmed said reading with a variety of comments during that
period.

>> Max isn’t designed to be a sequencer,
>
> no?

Exactly.

Max is not a sequencer, Mac is not a typewriter, cinema is not a silent
stage.

Cheers — P.

>
————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 22, 2006 | 11:06 am

Sequencer or not….it would still be very usefull to have a VST


February 23, 2006 | 10:36 am


February 23, 2006 | 11:34 am


February 23, 2006 | 10:13 pm

Quote: pure wrote on Thu, 23 February 2006 03:36
—————————————————-
> peter, i canZt keep myself from suspecting you to misunderstand me on
> purpose ;)

if it is not a misunderstandment this is the
purpose of the whole maxmsp mailing list.

> "In my opinion, it’s a severe limitation in Max/MSP’s ability to host
> VST plugs."
> Who says thats a bad thing ;)"

why do suggest that "sequencers", be it "usual" (puckette)
or unusual ones, always must support proper VST enviroment?

> " .. I mean, come on, you gotta have a vst object to test pluggo
> plugins out on anyways.

or a proper host like cubase or protools.

the only thing you can not do in MAXMSP is the actual
plug-in releated things like plugsend or plugsync, all
other things can be tested fine while in the MAX app.

this is not better in XCode. With the difference that
we OOP users have realtime audio programming since 15
years at our hand.

> Maybe host/plug sync can start generating
> vsttimeinfo as well invisibly or so. that would be cool :)"

thats also a good idea. a startup object which is
running under the vst~ object and all vst~s will share
thesame timeinfo generator. (like 2 noise~ also share
the same generator)

> although i posted 5 links to vst plugins which dont work at all without
> sync info the day before he/she is still asking what one would need
> that for.

yea 5 out of 1200.

well i am not argueing against you; it
is true that there are a few plugs which require it
to run.

> () i think its legitimate to understand mspZs quote in such a way that
> max enables you to build things (e.g. sequencers) that do things (e.g.
> sequencing) that go beyond the limits of "usual sequencer and voicing
> programs".

that X allows you to do things beyond the things
Y can do, does not automatically mean that X can
do _everything Y can do.

if MAX would be doing that what you got from the puckette
quote, MAX would ship with A-1 and dolby exporters, had
a TDM interface, DP?s midi editor, abletons skins, fruity
loops silly user group, and the pro version came with
spacedesigner AU.
it would cost 7000 euros, had 10000 tracks, would
support 64-bit audio streams, and you can only run
it after plugging in the 3 dongles.

> () as far as i know about the history of max (without MSP) it was only
> capable of controlling external midi gear. so what else could you do
> besides sequencing?

this is a very good argument for your thesis, so i will
pretend to overlook it.


March 6, 2006 | 2:20 pm

yer, until someone with more knowledge about implementing the vstTimeInfo
creates such a thing…… i’m like max or kontakt. bugger.
jJ


March 22, 2006 | 1:30 am

Yea I agree also

Im currently using max to make a midi sequencer based on pure mathematics for a uni project. Having not used it before at 1st I was very impressed with it

Then I came to syncronising it to cubase (as I want to implement what im doing into into my music) and I have to say, I have no interest in purchasing max when the trial runs out now. I nearly did fork out the cash last week, im glad I didnt now. Im not 100% sure if its because im a newbie and Im if im missing something with plugsync~ tho


March 22, 2006 | 3:12 am

You may never find out…..

Post up the patch – or if you would rather not – the part of it you feel is not working.
Sometimes getting sync working correctly in a pluggo plugin can be a little tricky.

I assume that what you mean is *not* actually what this thread is about. I’m not trying to be a thread nazi – please let me know if I am wrong about that one. Just curious….

Also – you may be interested to know that there is a 9 month student license of MaxMSP available for not much to all people who can show us their student ID. Details in the web shop

Cheers

Andrew


March 22, 2006 | 2:20 pm

Ok your on

Your probably right, it wouldn’t surprise me if I am totally getting the wrong end of the stick tbh. Ive put up the patch on this thread…

http://www.cycling74.com/forums/index.php?t=msg&th=18908 &start=0&rid=2961&S=90bcac607f433c3a3ca7f8f78050 bd3c

Thanks

Dan


September 30, 2006 | 11:54 pm

Hi,

once this project will be released, i wonder if it will provide solution to this: http://sourceforge.net/projects/jvst/ ?

having no time info going into vsts is a nightmare if you want to use vsts inside msp. say, one wants to create a vsthosting vst that will load vsts on program change/bank select. thing something like ni kore. the slogan says it all: "think in sounds" this way , during live performance, i could just load a setup by hitting a button on a midi controller, all vsts/or whatever would get loaded and i could concentrate on playing. there is a host that can do this kind of thing very well: http://www.hermannseib.com/english/vsthost.htm , only problem with it is that it doesnt support controll of tempo via midi. this leaves me with having the same tempo for all plugins. surely you can fire sequences at different speeds, but if a synth needs tempo info for its envelopes, than you are init again.

even though a lot of interest around this exists between max users, cycling isnt interested and i doubt they will ever implement this function. shame i was gonna buy this soft, but i reckon i finish (not to the extent i wanted) designing onarb at college and wave goodbye,….

cycling team: max is not a good sequencer? …. i remember miller puckett saying this in his max tutorials, but since metro can bang it faster than every ms (i have it set at 0.04ms … is that not enough for tempo control to work? ), this statement is incorrect today. i am almost finished with my sequencer in max (no signals) and it is popsteady. i programmed a time correction function and when i play my sequence against a steady beat from a machine, its dead in sync, even after a day.
if you are saying your clock is crap, why dont you change it?
32bit float is enough for good quality (low noise floor)audio, and i really dont understand why you mix such different issues together. or do you really thing we want something that extra///


October 24, 2006 | 4:01 pm

Hello,- i’m just bringing this thread to the top, because i wan’t cycling to consider this for the comming release of MaxMSP 5.0 …

VSTime~ and a modification of the vst object – or a vst2~ object capable of sync !!

— not just to bring it to the top,- if you have comments please share (if you agree with me;)


October 24, 2006 | 4:18 pm


October 24, 2006 | 4:37 pm

I just want plugins to work reliably, I would trade features for
reliability. I can’t imagine how tough it must be for C74 to keep
with all these standards. its not like they have one tiny bit of
code to update, they have the entire max environment. still it seems
like every pluggo I make comes with a different problem
-matt


October 24, 2006 | 4:41 pm

This feature request has been noted (several times).

-A


Viewing 43 posts - 1 through 43 (of 43 total)