Graphics Speed Problems Using JSUI in Pluggo VST


    Aug 26 2006 | 8:13 pm
    I'm trying to bring some of my Max patches with interactive, animated GUI's into the VST world through Pluggo. I'm having problems, though, with not being able to refresh the JSUI interface quickly enough outside of Max/MSP. If I have a metro object set to send a redraw command to the jsui object once every 50 ms, it will work fine in Max, but then run at only a fraction of that speed in Cubase SX or Minihost where I am testing it. Increasing the speed of the metro object changes nothing, as there seems to be a ceiling for the fastest it can update in a VST.
    Additionally, this rate of update seemed to very between hosts. If I loaded the pluggo VST into Cubase SX, it would be one speed, Minihost would be a little different, and a host made in Max/MSP would run it at the original speed. None of the hosts had any CPU problems as to cause GUI updates to slow down.
    Is there some unchangeable limitation on how fast JSUI graphics can update in a VST made through Pluggo? I've had this exact same problem with all the patches I've made with animated GUI's.

    • Aug 27 2006 | 8:28 am
      > > Is there some unchangeable limitation on how fast JSUI graphics can update in a VST made through Pluggo? I've had this exact same problem with all the patches I've made with animated GUI's. > ----------------------------------------------------
      i have no clue about java but when you say you drive the graphics update with a metro object that sounds a bit dangererous.
      what i can tell for sure is it is normal that pluggo updates slower than a patch in max does - compare multisliders and you will see this isnt a java problem.
      it is more or less .. ehm .. a plug-in window problem. in cubase on the mac for example pluggos update faster when the mouse is held down in the window - or when the window is not the frontmost window, but when you only look at the fromtmost plug-in it can be very slow for no reason.
    • Aug 28 2006 | 2:19 am
      Quote: Roman Thilenius wrote on Sun, 27 August 2006 02:28 ---------------------------------------------------- > > i have no clue about java but when you say you drive > the graphics update with a metro object that sounds a > bit dangererous. > > what i can tell for sure is it is normal that pluggo > updates slower than a patch in max does - compare > multisliders and you will see this isnt a java problem. > > it is more or less .. ehm .. a plug-in window problem. > in cubase on the mac for example pluggos update faster when > the mouse is held down in the window - or when the window > is not the frontmost window, but when you only look at the > fromtmost plug-in it can be very slow for no reason. > ----------------------------------------------------
      Thanks for the response, that was quick!
      I'm probably showing my ignorance here, but is there any other possible way to drive consistent graphics updates other than with a metro or qmetro triggering an update function? I originally started doing that because it was how Jitter handled all of its graphics updating in the tutorials.
      Creating a Task within the javascript and completely internalizing everything is the only other option I know of, but the Max jscript documentation says the timing for that isn't accurate. I'm trying to keep the audio and graphics completely synchronized for some of my patches, so I was trying to avoid going that route (and maybe it won't even help).
      Is it really "dangerous"? I've always set up my animated JSUI objects like that because it's the only way I know to do updates at constant time intervals.
      If the problem is a plug-in window problem, is that a lost cause? Is there a way to have the plug-in signal the host to change the idle rate, or something like that?
    • Aug 28 2006 | 6:48 am
      > I'm probably showing my ignorance here, but is there > any other possible way to drive consistent graphics > updates other than with a metro or qmetro triggering > an update function?
      i would guess from INSIDE java?
    • Sep 15 2006 | 8:58 am
      I also have the feeling that the fastest GUI rate inside pluggo is about 50 ms at best... Though, from what I understand, the "#C accurate" message in plugconfig is meant improve the control rate down to the vector size (32 samples usually) which is less than 1ms.
      I didn't tested the speed difference myself, maybe that's what you need ! Let us know !
      Salvator