I am beta testing a DirectX plugin for another programmer (a little startup company) and he is having a heck of a time getting a dropdown menu to work in any Steinberg app, as it crashes as soon as it's used. They told me they found the problem is that Steinberg does something odd that will force them to write their own object control for that dropdown menu to work around Steinbergs proprietary control issues...
Paavo, ever heard of this, or understand what I am trying to even say? Just curious if you have any pointeres I can share with them to, cuz it's giving them a hella bunch of problems, other than that single issue, the plug is super cool and works really well...so it's a real drag that one thing is holding it up.
curiousity kills me
-
Paavo
Dropdown menu plug problem.
Hi Dan,
Sorry but I don't have much insight in the matter. COM can be a real nightmare to work with, particularly if working with the ActiveX part of microsoft stuff. That whole part of the library is a dogs breakfast. In fact, the biggest problem is the continual revising of the "standard" where some supported interfaces are deemed "optional" yet you need them to function. Maybe they've hit one of these.
But you might like to suggest that they also support there plugin as a VST plugin as well as DirectX. The VST api is pretty simple to work with so I don't think they'd have much difficulty creating a VST version of their device. The benefit of supporting both is having something else to fall back on when a customer finds a host where the DirectX variant doesn't work on. My guess is that they can expect to have interoperability issues with some apps for quite some time, particularly if they're doing snazzy stuff with their interface that is a bit out of the ordinary. So a fallback position can be very important when dealing with interfacing to other apps / HW.
A good case in point is the new driver support in HarBal. It took much longer to sort out than I was intially hoping for but having the other interfaces available at least gave some other option of using the product when a given driver interface didn't work.
Hope they sort it out in a timely fashion.
Regards,
Paavo.
Sorry but I don't have much insight in the matter. COM can be a real nightmare to work with, particularly if working with the ActiveX part of microsoft stuff. That whole part of the library is a dogs breakfast. In fact, the biggest problem is the continual revising of the "standard" where some supported interfaces are deemed "optional" yet you need them to function. Maybe they've hit one of these.
But you might like to suggest that they also support there plugin as a VST plugin as well as DirectX. The VST api is pretty simple to work with so I don't think they'd have much difficulty creating a VST version of their device. The benefit of supporting both is having something else to fall back on when a customer finds a host where the DirectX variant doesn't work on. My guess is that they can expect to have interoperability issues with some apps for quite some time, particularly if they're doing snazzy stuff with their interface that is a bit out of the ordinary. So a fallback position can be very important when dealing with interfacing to other apps / HW.
A good case in point is the new driver support in HarBal. It took much longer to sort out than I was intially hoping for but having the other interfaces available at least gave some other option of using the product when a given driver interface didn't work.
Hope they sort it out in a timely fashion.
Regards,
Paavo.