steff3

well, just had the same question for sflist? - but can the output of vst? be suppressed? printing 500 times vst has 5 params on load .... that is not really ......

I mean those things can be quit helpful once you construct a patch - but for the rest of the life they are really just bothersome ....

well, just had the same question for sflist? - but can the output of vst? be suppressed? printing 500 times vst has 5 params on load .... that is not really  ......

vst-console-output-suppression

Quote: steff3 wrote on Fri, 11 May 2007 07:56

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

> well, just had the same question for sflist? - but can the output of vst? be suppressed? printing 500 times vst has 5 params on load .... that is not really ......

> I mean those things can be quit helpful once you construct a patch - but for the rest of the life they are really just bothersome ....

Quote: steff3 wrote on Fri, 11 May 2007 07:56
----------------------------------------------------
> well, just had the same question for sflist? - but can the output of vst? be suppressed? printing 500 times vst has 5 params on load .... that is not really  ......
>
> I mean those things can be quit helpful once you construct a patch - but for the rest of the life they are really just bothersome ....
>
> any hints? advices?

very funny :o ..... unfortunately I also use the console to print status information from subpatches - which is quite essential - this is why I do not really need debugging stuff with low entropy ....

Why are you reloading the vst so often? If you are managing CPU, then you may disable vst~ or use the poly~ object. This way you also avoid having to rebuild the DSP chain.

Quote: steff3 wrote on Fri, 11 May 2007 15:40

> very funny :o ..... unfortunately I also use the console to print status information from subpatches

maybe i am conservative, but console is for programming, not

maybe you print your custom stuff elsewhere next time?

it should not be too much hassle to replace all "print"

objects with a "send print" and display stuff in a textbox,

messagebox, or lcd so that you can have the max window closed.

Quote: steff3 wrote on Fri, 11 May 2007 15:40
----------------------------------------------------
> >> yes: close the max window.
>
> very funny :o ..... unfortunately I also use the console to print status information from subpatches

maybe i am conservative, but console is for programming, not
for performance. :)

maybe you print your custom stuff elsewhere next time?
it should not be too much hassle to replace all "print"
objects with a "send print" and display stuff in a textbox,
messagebox, or lcd so that you can have the max window closed.

when i get you right, you current request is about that:

you want to see the console because of plug-in 

parameters - but you dont want to see the console 

furthermore, you have to reload your plug-ins 

all the time because your vst~ is in a poly~.

as much as i understand that the console is the only place

which can tell you "error: no such object" i would like to

convince you that there are better ways for knowing about

you want to see the console because of plug-in 
parameters - but you dont want to see the console 
because of plug-in parameters.

furthermore, you have to reload your plug-ins 
all the time because your vst~ is in a poly~.

as much as i understand that the console is the only place
which can tell you "error: no such object" i would like to
convince you that there are better ways for knowing about
plug-in parameters.


> when i get you right, you current request is about that:

> you want to see the console because of plug-in 

> parameters - but you dont want to see the console 

> furthermore, you have to reload your plug-ins 

> all the time because your vst~ is in a poly~.

right, that would not make sense ..... no - I need the console to print status information for my patch - from subpatches and externals that give me valuable info about the state of my patch (and that I decided that I want to see them printed to the console) ..... I do not need to have information there that does not give me any valuable information - like the sflist~ printout - that does say nothing, or the vst~ printout that a plug has parameters. I think this info one need once or twice until one has designed the patch/sub-patch and then it should work .

> as much as i understand that the console is the only place

> which can tell you "error: no such object" i would like to

> convince you that there are better ways for knowing about

Well, of course error messages should be printed, as this is obviously important information - though the way Max prints error messages is often not that informative - error: sprintf ...... Well, nice, I have 130 subpatches - each load multiple times and about 50 of them have one or more sprintf modules - so, nice - where exactly is the error. All nodes can get the name of the parent patcher I think ......

I do not want Max to tell me plugin params - I decided to use that plug so I know about its params ..... :) 

That is exactly it - I do not want to print plugin params in the console - but Max does that all the time when loading a patch with plugin .... so how to tell vst~ to load "silently" ?

Thanks for yiour reply
----------------------------------------------------
>
> when i get you right, you current request is about that:
>
> you want to see the console because of plug-in 
> parameters - but you dont want to see the console 
> because of plug-in parameters.
>
> furthermore, you have to reload your plug-ins 
> all the time because your vst~ is in a poly~.
>
> that doesnt make much sense. :)

>
>
> as much as i understand that the console is the only place
> which can tell you "error: no such object" i would like to
> convince you that there are better ways for knowing about
> plug-in parameters.
----------------------------------------------------

Well, of course error messages should be printed, as this is obviously important information - though the way Max prints error messages is often not that informative - error: sprintf ...... Well, nice, I have 130 subpatches - each load multiple times and about 50 of them have one or more sprintf modules - so, nice - where exactly is the error. All nodes can get the name of the parent patcher I think ......
I do not want Max to tell me plugin params - I decided to use that plug so I know about its params ..... :) 
That is exactly it - I do not want to print plugin params in the console - but Max does that all the time when loading a patch with plugin .... so how to tell vst~ to load "silently" ?

> Why are you reloading the vst so often? If you are managing CPU, then

> you may disable vst~ or use the poly~ object. This way you also

I just made a wonderful patch where reloading of vst~s is the core of

the functionality. Especially because it doesn't rebuild the DSP chain!!!

No way to do it differently, and its not at all about managing CPU...

The world is bigger than any creator (including god) could imagine...

I can only advice Steff to request the feature I have requested already:

A maxgrab object. It should work like the grab object.

If connected to an object it would reroute all messages which are posted

to the max window from that object to an outlet, to avoid showing up in

the max window, and much more important to use these messages as

Many objects (not only vst~) post to the Max window as notification. I

desperately need that information for further processing in Max. And

also error handling would be much more convenient than with the error

object, as it could easily limited to the object which causes it.

Andrew Pask schrieb:
> Why are you reloading the vst so often? If you are managing CPU, then
>  you may disable vst~ or use the poly~ object. This way you also
> avoid having to rebuild the DSP chain.

I just made a wonderful patch where reloading of vst~s is the core of
the functionality. Especially because it doesn't rebuild the DSP chain!!!
No way to do it differently, and its not at all about managing CPU...

A maxgrab object. It should work like the grab object.
If connected to an object it would reroute all messages which are posted
to the max window from that object to an outlet, to avoid showing up in
the max window, and much more important to use these messages as
information.

Many objects (not only vst~) post to the Max window as notification. I
desperately need that information for further processing in Max. And
also error handling would be much more convenient than with the error
object, as it could easily limited to the object which causes it.

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> I can only advice Steff to request the feature I have requested already:

> A maxgrab object. It should work like the grab object.

> If connected to an object it would reroute all messages which are posted

> to the max window from that object to an outlet, to avoid showing up in

you just requested an update to the max runtime, are you aware of that ?

anybody who has ever worked with live midi input will 

agree with me that the max window is nothing what should 

> I can only advice Steff to request the feature I have requested already:
>
> A maxgrab object. It should work like the grab object.
> If connected to an object it would reroute all messages which are posted
> to the max window from that object to an outlet, to avoid showing up in
> the max window,

you just requested an update to the max runtime, are you aware of that ?
:)

anybody who has ever worked with live midi input will 
agree with me that the max window is nothing what should 
be open during performance.

> anybody who has ever worked with live midi input will 

> agree with me that the max window is nothing what should 

And if you need the info posted to the Max window you need "maxgrab"...

And anybody who has ever worked with live midi and/or audio will agree 

that its better to use the full version instead of Maxplay, I always 

Roman Thilenius schrieb:
> anybody who has ever worked with live midi input will 
> agree with me that the max window is nothing what should 
> be open during performance.

And if you need the info posted to the Max window you need "maxgrab"...
And anybody who has ever worked with live midi and/or audio will agree 
that its better to use the full version instead of Maxplay, I always 
change my patch in the last minute...

vst~ console output suppression