Controlling VSTi plugin parameter which doesn't recognize midi CC data

[UsineHeaven]

Hello,

I have done large research for a software solution that will allow me to 'code' & build my own multi-touch surfaces for controlling VST instruments in Cubase.

Sure, when plugins can receive midi CC data, there is no problem. But my problem is that I need to control a plugin parameter on VST instrument GUI that doesn't respond to Midi CC.

So, now I'm wondering, if Hollyhock SDK will allow me, or somebody else, to 'connect' to such GUI parameter?

Btw, that particular plugin doesn't gets recognized by *ovation *utomap software either. That plugin is coded in some non-main stream programming language I think.


Main question: Can I assume that Hollyhock will be able to control (connect) to whichever VST parameter that is present as a part of VST instrument GUI?

Maybe I missing the point. Please give me some clarification.

Best regards.

[shawnb]

Sounds like you need a screen-scraper / gui automation package. I don't think HH does this, but lots of apps do. Helpful for automated testing of applications, that's the normal context.

Once you have such an app, I think HH can communicate with it...

Google screen scrapers...

Hope this helps...

[ceasless]

HH can control any parameter that can be 'mapped' in another host. In general this is not a 'midi cc' in the traditional sense. But there are plenty of VSTs that leave out some of their controls from mapping.

Either way, you should be able to test this in the demo. Usine will only be able to interact with parameters that appear when you 'show all params' on the VST module.

[UsineHeaven]

But there are plenty of VSTs that leave out some of their controls from mapping.

In such case, what are my options (if any) with Usine Hollyhock?

Either way, you should be able to test this in the demo. Usine will only be able to interact with parameters that appear when you 'show all params' on the VST module.

Will try it now and post my results.

Thanks!

[iococoi]

that particular plugin

what might that be?

That plugin is coded in some non-main stream programming language I think.

i mean that shouldn't be a problem as long as it "obeys" the official VST plugin interface, otherwise it's not a VST plugin . there are some wrappers flying around in the www( java, delphi, .NET, etc)

[UsineHeaven]

Sounds like you need a screen-scraper / gui automation package. I don't think HH does this, but lots of apps do. Helpful for automated testing of applications, that's the normal context.

Once you have such an app, I think HH can communicate with it...

Google screen scrapers...

Hope this helps...

Very interesting concept, but maybe that is a overkill for my problem? Bur sure, if such screen-scraper also works bidirectional, maybe that is is way to go. First I will try out other possible Hollyhock in-box solution. Thanks.

[UsineHeaven]

Usine will only be able to interact with parameters that appear when you 'show all params' on the VST module.

None of VST parameters shows when clicking on 'show all params'. Dead end?

Check:

[ceasless]

Yes, unfortunately it seems like the plugin has not set up any parameters for host mapping

Have you ever been able to automate any parameters in other hosts?

The next thing to check is the manual for the plugin. For instance NI Battery was confusing me until I looked up the specific method of host automation that is used for that plugin -- you manually set up mapping for any parameter you want to use, but until you do nothing shows up to be automated (this is true in all hosts).

I hope it turns out to be something like that!

But otherwise... I would write the plugin author asking for an explanation. It seems odd indeed not to make any parameters available to host automation.

[UsineHeaven]

Yes, unfortunately it seems like the plugin has not set up any parameters for host mapping

Have you ever been able to automate any parameters in other hosts?

The next thing to check is the manual for the plugin. For instance NI Battery was confusing me until I looked up the specific method of host automation that is used for that plugin -- you manually set up mapping for any parameter you want to use, but until you do nothing shows up to be automated (this is true in all hosts).

I hope it turns out to be something like that!

But otherwise... I would write the plugin author asking for an explanation. It seems odd indeed not to make any parameters available to host automation.

Well, in *ubase you can automate it without any problem by right clicking on particular function in GUI and assign a midi CC to it through plugins own pane for that. The problem is that developers forgot to enable that function for one particular parameter on GUI. So I was hopping that Hollyhock could somehow 'grab' that parameter and make it accessible via external controller.

Btw, I guess it is possible to automate parameters for it in Hollyhock too, but the quirk is that plugin wont show its parameters in usual state...

I spoke to plugin developer and they told me that plugin is coded in different way than main stream VST instruments, so...

Cheers.

[shawnb]

Very interesting concept, but maybe that is a overkill for my problem? Bur sure, if such screen-scraper also works bidirectional, maybe that is is way to go. First I will try out other possible Hollyhock in-box solution. Thanks.

Basically, macro utilities must talk with UI elements at the OS level, which is what you would have to do if they don't expose parameters in any way.

I think there is even a Windows freebie out there called Autoit, complete with its own little programming/scripting language.

More food for thought:
http://en.wikipedia.org/wiki/Comparison ... r_software
http://www.autoitscript.com/wiki/Tutorials

[UsineHeaven]

Very interesting concept, but maybe that is a overkill for my problem? Bur sure, if such screen-scraper also works bidirectional, maybe that is is way to go. First I will try out other possible Hollyhock in-box solution. Thanks.

Basically, macro utilities must talk with UI elements at the OS level, which is what you would have to do if they don't expose parameters in any way.

I think there is even a Windows freebie out there called Autoit, complete with its own little programming/scripting language.

More food for thought:
http://en.wikipedia.org/wiki/Comparison ... r_software
http://www.autoitscript.com/wiki/Tutorials

Yes, I think that using something like this is unavoidable in this situation. I need such software to be able to work bi-directional. It should read but also apply changes that comes outer way - from and to Hollyhock.

I would need to find someone to help me with such implementation (coding) in Hollyhock though.

Cheers.

[woodslanding]

seems like if you are going to pay a developer, it would be simpler to pay the developer of the vst to update his code, in order to expose the extra parameter(s)? Have you tried talking to the developer?

[UsineHeaven]

Have you tried talking to the developer?

As a matter of fact, yes I have. How much I understood, the programming logic architecture of that plugin does not allow that. So I do not have much choice left...

[woodslanding]

bummer.... no other vst will do the trick? I guess you have no choice after all.

[UsineHeaven]

bummer.... no other vst will do the trick? I guess you have no choice after all.

That plugin have something I value most when it comes to sound. I have invested a lot of time and passion into it and I'm kind off stranded into its sonic results...

Cheers.