bingweb

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)

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)


hi-and-pp-automation-problems-in-cubase

tried to unsuccesfully to upload file so instead am posting a link to it:

http://uk.geocities.com/bingweb/forumpost.zip

Quote: bingweb wrote on Thu, 23 March 2006 19:21

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

> tried to unsuccesfully to upload file so instead am posting a link to it:

i dont think it is possible to save plugmod settings

to presets at all, because the menu values / the 

in your example [hi] is not even connected to an pp. :)

you could create a pp 4 just for saving the hi value mb.

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.

you could create a pp 4 just for saving the hi value mb.


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?

> 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 

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 

(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

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 

otherwise umenu item 17 is something else tomorrow.

when you exspect them to store up to ca. 80 umenu items

oh well, as a first step please renumber one of 

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

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 

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 

I hope the attached patch will illustrate what I am experiencing.

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.

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?

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.

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.

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.

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'

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'

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) :

- a plugmidiin box with a midiparse object and a route to select just one controler connected to the slider

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 !

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

about 2-3 years ago people kept asking me 

how to get automation with midi to work in 

and as i do not often use OS X myself i begun 

to think after a while that they are all completely 

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 

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?


hi and pp automation problems in cubase