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. :)
    • 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.
    • 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?