Hjalte Bested Møller

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

Will it be available in a comming release of MSP ?

vst-prayer

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

you can use vst~ only in MAXMSP which does not 

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


What do you mean sync information? something like Smpte?

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

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.......

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.......

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 :)

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...

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~

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

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...


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

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

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

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

>
>
>> 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

> 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 

what i mean by this is ... no VST plug-in would support 

"MAX host sync" anyway, there are only plug-ins which 

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 

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

> 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.

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.

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.


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....

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

Quote: lalo wrote on Sun, 19 February 2006 04:18

----------------------------------------------------

> 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....

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

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
----------------------------------------------------

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


>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 

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

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 

>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 

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

>It's not really a "sequencer" type program, but it certainly has the 

>tools to cut whatever time information you have coming in into 

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

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?]...

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

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.

>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


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.

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.
>

"Right - but you can't get that time information *into* certain VST

plugs because of the current limitation... And in so doing, you

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 :)

"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.

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 :)


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

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 !

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 !


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 !

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....

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 !
----------------------------------------------------

> In my opinion, it's a severe limitation in Max/MSP's 

maybe the error about geek s request is that MAXMSP

is not hosting the plug-ins; it is the vst~ object 

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 

> 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.


> 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...

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

> 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.


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...

> 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

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 :)

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...

> 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.

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.

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.

> > Who says thats a bad thing ;) .. I mean, come on, 

> you gotta > have a vst object to test pluggo plugins 

maybe that is just me but i find making pluggos 

for use in MAX pointless, i make mine for use in 

> want to make a simple step-sequencer it would be 

> nice to have >the ability to create "fake" VST-TimeInfo

> Max deals with all kind of data, so this is of course 

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 

in danger of repeating myself (or beeing accused of

if you want a full VST enviroment buy SX/nuendo.

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

> > 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.

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. 

> > 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

> come on roman...if i say this i say after some reasearch and experience...

> VSTTimeInfo works in both direction...host->plug and plug->host

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

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?

Vst~ prayer