hi and pp automation problems in cubase


    Mar 24 2006 | 2:01 am
    I am creating a plugin which is controlled via a playstation style joystick.
    Within Cubase the joystick controls sucessfully modulate pp parameters in real time, but for some reason automation data is not stored in Cubase. I have tried using max interface objects as a workaround (i.e. toggles and sliders) but nothing seems to work, can anyone help out? (example patch attached)

    • Mar 24 2006 | 2:21 am
      tried to unsuccesfully to upload file so instead am posting a link to it:
    • Mar 24 2006 | 10:54 am
      Quote: bingweb wrote on Thu, 23 March 2006 19:21
      ----------------------------------------------------
      > tried to unsuccesfully to upload file so instead am posting a link to it:
      >
      > http://uk.geocities.com/bingweb/forumpost.zip
      ----------------------------------------------------
      i dont think it is possible to save plugmod settings
      to presets at all, because the menu values / the
      number of entries is dynamic.
      in your example [hi] is not even connected to an pp. :)
      you could create a pp 4 just for saving the hi value mb.
    • Mar 24 2006 | 1:21 pm
      Thanks for your reply
      The problem is that the max runtime within cubase seems to be able to discern between a 'pp' parameter being modulated directly ie using the mouse on a slider/toggle and a 'pp' parameter being modulated remotely ie using data from 'hi' even if it is routed through a slider/toggle.
      Unfortunately the former produces recordable automation data while the latter does not- but I am sure there must be a way to fool Max into thinking that modulation data from 'hi' is actually direct manipulation. Does anyone have any tricks they have used in the passed that may be relavent here?
      I've run out of ideas!
      bingweb
    • Mar 26 2006 | 5:46 am
      > The problem is that the max runtime within cubase seems to be able to discern between a 'pp' parameter being modulated directly ie using the mouse on a slider/toggle and a 'pp' parameter being modulated remotely ie using data from 'hi' even if it is routed through a slider/toggle.
      >
      > Unfortunately the former produces recordable automation data while the latter does not- but I am sure there must be a way to fool Max into thinking that modulation data from 'hi' is actually direct manipulation. Does anyone have any tricks they have used in the passed that may be relavent here?
      if i am not overlooking something fundamental then
      you are.
      in the given example your 2 pp?s which are running the
      plugmod systems are connected to a umenu.
      this umenu is filled from the pluggo runtime; pluggo
      runtime has to ask the host about plug-in parameters
      present in the cubase VST enviroment.
      (from other pluggos that is.)
      (or other VST plug-ins in case you are on OS 9.)
      it does that everytime when you load a plugmod object,
      and in addition it is continiously updated by the runtime.
      a possible plug-in preset of your [hi] plug-in is
      loaded when the plug-in initialises. that is why it is
      impossible to store that umenu from the plugmod into
      pp?s.
      the minimum requirement to reach this goal would be
      some kind of data delay, and it will of course only
      make sense when the parameters of other plugins used
      are the same everytime, lets say when cubase is used
      for an installation.
      otherwise umenu item 17 is something else tomorrow.
      and do not forget to scale the pps.
      when you exspect them to store up to ca. 80 umenu items
      you should use a pp 0 100 or so.
      oh well, as a first step please renumber one of
      the [pp 2 ... ] you used. :)
      max v2;
    • Mar 26 2006 | 10:15 pm
      Thanks for your reply Roman - unfortunately I seem to have been rather
      unclear in my description of the problem I am having:
      disregarding the umenu, pluggo does not output automation data when it is
      created by the hi object (ie my game controller) even though the operation
      the game controller is performing works perfectly within cubase. For
      clarities sake I should point out that I am running max and pluggo on
      windows XP
      Pluggo within cubase seems to be able to discern between a 'pp' parameter
      being modulated directly ie using the mouse on a slider/toggle and a 'pp'
      parameter being modulated remotely ie using data from 'hi' even but I am
      sure there must be a way to fool Max into thinking that modulation data from
      'hi' is actually direct manipulation.
      I hope the attached patch will illustrate what I am experiencing.
      max v2;
    • Mar 27 2006 | 5:16 pm
      Your patch works fine as a plugin in SX 3.1.1 on XP here. I'm using my Logitech attack 3.
      BTW, you're better off using route instead of the logic you had there
      I'm not quite sure what the problem is - does this patch work for you?
      Cheers
      Andrew
    • Mar 27 2006 | 6:35 pm
      Thanks for your reply Andrew,
      Does Cubase record the automation for the onoff parameter into an automation
      track when the W is enabled? - My problem is that it doesn't on my system.
      I'll give your patch a go and let you know.
      Thanks
    • Mar 28 2006 | 2:15 am
      Well that's pretty interesting.
      You're right - it's not recording the automation. My guess is that hi is outputting its data in the audio thread when it is polling internally, and the data not seen by Cubase as automation. One way round this is to defer the output of hi like this, which now works for me -
      Another way to get around it would possibly be to use a qmetro 100 to poll hi, but I didn't try this. I imagine it would work though.
      These threading problems in hosts are fairly subtle, and unfortunately are part of the pluggo programmer's lot in life. The problem that we have in providing a general "one size fits all" solution for pluggo programmers is that hosts all behave in different ways, and what might work in one host could break another etc. etc. I think that you would find in this case that deferring the output of hi will work in all hosts though.
      -A
    • Mar 29 2006 | 7:15 am
      Many many thanks that is now working perfectly - such a simple solution but one that I would never even have considered!
      I had just finished implementing a work-around where the hi data is converted to MIDI and the plug-in sends MIDI data to itself by being inserted as both the input and the output of a MIDI track so hi data was being recorded in MIDI form. Needless to say your solution is much more elegant, also thanks for the tip about 'route'
      bingweb
      Andrew Pask wrote:
      Well that's pretty interesting.
      You're right - it's not recording the automation. My guess is that hi is outputting its data in the audio thread when it is polling internally, and the data not seen by Cubase as automation. One way round this is to defer the output of hi like this, which now works for me -
      Another way to get around it would possibly be to use a qmetro 100 to poll hi, but I didn't try this. I imagine it would work though.
      These threading problems in hosts are fairly subtle, and unfortunately are part of the pluggo programmer's lot in life. The problem that we have in providing a general "one size fits all" solution for pluggo programmers is that hosts all behave in different ways, and what might work in one host could break another etc. etc. I think that you would find in this case that deferring the output of hi will work in all hosts though.
      -A
      Peter
      bingweb@yahoo.com
    • Apr 17 2006 | 1:54 pm
      hello
      I have had the same problem when I tried to draw VST automation with MIDI Controler in Cubase SX 3.1.1 running under a PC
      For instance, I needed to draw automation using MIDI controler but without passing throught the Generic Device Management of Cubase because I needed several 14bit controlers and those are easier to program with Max than with Cubase...
      the patch-test I made was something like that (sorry I can't paste it in text format) :
      - one slider connected with a pp box
      - a plugmidiin box with a midiparse object and a route to select just one controler connected to the slider
      - plugin“, plugout“ and plugconfig
      In Cubase, with a MIDI track routed to the plugin on an audio track, I can move the slider by moving my controler but nothing was drawn in the VST automation tack !
      I added a deferlow object (thanks to Andrew for tis idea !) between plugmidiin and midiparse and the problem was solved !
      Thanks for all
      ChianLi
      PS : I very sorry for my bad english...
    • Apr 17 2006 | 2:41 pm
      about 2-3 years ago people kept asking me
      how to get automation with midi to work in
      SX/nuendo because they knew i make midi
      plug-ins.
      and as i do not often use OS X myself i begun
      to think after a while that they are all completely
      mad that they do not get it to work.
      i am glad we finally found out that it is only
      a software problem and even have a solution for it.
      but i would be interested if it will also help
      to connect the midi input and output data directly
      to the [pp] insetad of the slider, could anyone
      please try ChianLi s simple slider example that
      way in SX and report?