vst~ console output suppression
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?
(I am still on 4.5x)
thanks
best
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?
yes: close the max window.
-110
>> yes: close the max window.
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 ....
but thanks anyways
best
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.
-A
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.
-110
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.
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. :)
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
> 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" ?
thanks for your thoughts
best
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...
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
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.
Even debugging would be enhanced...
Seems to have many advantages...
Stefan
--
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
> 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.
-110
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...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com