Betaversion of update for all MeldaProduction effects to 3.00 including VST3 support released!

[MeldaProduction]

1. Preset Change via MIDI Program Change does not work for the VST3 version of the plugins. However, it works okay for the VST2 version.

Well, there is the problem with VST3 standard... Steinberg really made MIDI crazy ugly piece of s***, many things are even impossible. I'll see what I can do.

Yes, VST3 has some unexpected limitations as to which MIDI messages can be recognized by the plugin. However, I think there should be a possibility to make use of the new VST3 "Program Lists" concept to facilitate this functionality. I suppose that in VST3 it should not be done directly via MIDI but via some automation parameters instead. Maybe it is implemented already now in your VST3 plugins, however, I forgot to see which automation parameters do your VST3 plugins expose to the host. And I believe that the host can transform the incoming Program Change messages to the corresponding automation parameters responsible for switching the "Program Lists". So, this should be a workaround, I think

--
Miloslav

Miloslav, I'm afraid this is the time I have to say no to something - in this case it is the program change in VST3. The "program lists" could probably solve this, but honestly it's like super complicated crazy something to do something simple and I believe Steinberg will eventually find out (after all devs f** them off with this, which already happened actually ), that they will have to provide normal MIDI messages (which there are actually, just Cubase does not transfer them).
So please if you want to use Program change, use VST2.4 version. VST3 doesn't help anyway.

[valsolim]

Miloslav, I'm afraid this is the time I have to say no to something - in this case it is the program change in VST3.

Okay, no problem, I understand Somewhere on the Cubase.net forum I have read that the "VST3.1" update is on its way so maybe Steinberg is going to remove this insane MIDI filtering. I hope so because it's really ridiculous

Best regards
--
Miloslav

[ristof]

So MReverb hasn't been installed as VST3? I'll check it out. Generally I don't like VST3 either. Steinberg did it just to mask Cubase easier to develop I believe and the only advantage I know is side-chaining & GUI resizing. And there are also several flaws compared to 2.4.
Anyway according to Steinberg, Common Files is THE folder for the plugins, though if you use to with specific host, you can install it anywhere basically .

VST3 allows closer integration with the system (cubase) kernel via Steinberg SKI.

[MeldaProduction]

You mean the remote thingy? Yes that's true, however I kind of understand the need for it. It makes most plugins very hard to develop, sometimes almost impossible and generally this can easily be solved with software like Remote desktop for windows (which is part of Windows since XP).

[ristof]

Hi,

SKI is purely for audio, all the other stuff is relative "fluff" but is useful providing there is a holistic implementation, ie across the board preset format including sound selection, controllers and so on.

Maybe not so useful for a sound sample workstation but indeed can help with synthesis etc., good thing for you is you've started on the path since there will come a time when VST 2.4 support is dropped from Steinberg products, indeed VST 2.3 would likely be on the cards now.

[MeldaProduction]

Yes, I guess. It's just a little sad, how Steinberg did it. Generally I like the way VST3 is done, but I cannot get over the MIDI implementation and the need for an extra library. For example, all MeldaProduction plugins are completely the same binaries for all VST, VST3 and AU. So it's basically wasting space.

[ristof]

For example, all MeldaProduction plugins are completely the same binaries for all VST, VST3 and AU. So it's basically wasting space.

Well since you are an expert in the field of software development I have a question if you will...

.. is it correct that all plugins be they DXi/RTAS/AU etc., are in some way derived from the VST specification, ie C+ header files and are compiled for various applications?

I know many are against VST3 since it cannot natively compile a VST 2.4 library and each version must be compiled on it's one, in other words 2 versions are necessary, one being VST3 SDK based and another using the VST 2.4 SDK with the later producing binary code for all other (non-vst) plug in formats.

Best regards

[ristof]

P.S. In the Studio One manual (hint StudioOne) it talks about being "future proof" in regard to midi, in that implementing the aforementioned standard is slow and inefficient, which personally I tend to agree, not that it in reality it is necessary to deprecate all former methods from the spec, but I guess things like fxb/fxp must go the way of the dinosaur and be killed off or phased out.

[MeldaProduction]

Well, about VST/AU/RTAS... - they are not all the same. It's just that VST was first AFAIK. But it's true, that the functionality is basically the same andwe would be very fine with just one . The reason there is so many is that every company that came with something new was just lazy enough to use another company standard / too self confident / marketing reasons perhaps.
None is perfect - AU is extraovercomplicated, undocumented and full of hybrid constructions obviously made because of the poor design. VST is a creation of some guy in a garage, so the SDK looks like from high-school, though it is simple and works, it just doesn't handle multiple busses very well. VST3 fixes that but adds some weird constructions, which are a step back in my opinion etc...

Generally they should all do the same, it's just made by a different guy and therefore has different disadvantages .

About the MIDI - I agree that it is archaic, in MDrummer it is not used at all, and everything is 64-bit (as opposed to 7-bit MIDI). However the VST3 contains an interface for sending raw MIDI, it's just not used for it, probably to force developers not to use MIDI and rather use the new clumsy methods. But since every other interface uses raw MIDI, it is more than probable, that the plugins are using raw MIDI as well. So this kind of reminds me the stupid Apple marketing - making developers' lives a mysery unless they use their technologies ONLY...

[ristof]

The reason there is so many is that every company that came with something new was just lazy enough to use another company standard / too self confident / marketing reasons perhaps.

Interesting analysis, maybe you work for a magazine co

About the MIDI - I agree that it is archaic, in MDrummer it is not used at all, and everything is 64-bit (as opposed to 7-bit MIDI). However the VST3 contains an interface for sending raw MIDI, it's just not used for it, probably to force developers not to use MIDI and rather use the new clumsy methods.

So is it true therefore that these (vst3) plugins cannot receive old-school midi data and must instead be fed something different?

If so is that why you are saying that all MIDI in MDrummer is 64 bit but that with VST3 things like program changes are ignored and that the data itself must be in another format in order for the plugin to understand?

Thanks for the in-depth knowledge here nowhere else would it be discussed so openly not even in steinberg mailing list.

[MeldaProduction]

So is it true therefore that these (vst3) plugins cannot receive old-school midi data and must instead be fed something different?

Yes. The funny thing is, there is MIDI transfer interface in the VST3 format, it's just used only for Sysex or something. That makes me believe, Steinberg simply needed it for Cubase, because Cubases uses more accurate values than MIDI. And of course most other host devs refused to do it.
Anyway there could be both data - accurate and standard MIDI. I don't know why they did it this way... Probably again to save their own time...

If so is that why you are saying that all MIDI in MDrummer is 64 bit but that with VST3 things like program changes are ignored and that the data itself must be in another format in order for the plugin to understand?

Well, it has nothing to do with MDrummer, which used 64-bit values from the beginning. You may have also noticed it provides several additional features for each note, so basically there is no way to export MDrummer loops to MIDI without loosing information.

And wen it comes to the plugins, it wouldn't be a problem to "change data format". We are using 64-bits anyway, so whatever. The trouble is the way VST3 provides the data. I'll show it on an example:
Our effects can map any MIDI controller including pitch bend (which is not really a controller, who knows why) to any automatable/modulable parameter. VST2 (and other interfaces) send MIDI messages, which can be easily decoded and if a controller has changed, it can easily be found. In VST3 however, each MIDI controller is treated as a parameter, so each plugin has to create 128 additional completely useless parameters, map them to every controller on every channel and the listen to the changes. And you don't want to know how it is with program changes .

In Czech we have a saying - "why doing it easily when you can make it hard" .

[ristof]

In Czech we have a saying - "why doing it easily when you can make it hard" .

You know there's another Checz developer who makes the Togu Audio Line, another talented soul who seems to know how to make best on what they have, ie., VST 2.4.

I asked him once not for VST3 but for DSP based plugins since I think that would be major good, and by the same token if such as yourself could make a drum synth, you'd all be paid and I could buy and get support that way.

BTW do you have a demo drum synth program?

Sorry to be OT

[valsolim]

You know there's another Checz developer who makes the Togu Audio Line

Just a small clarification: Patrick Kunz from Togu Audio Line is not a Czech, but a Swiss. Maybe you have been misled by the similarity of the internet domains: CZ is Czechia, CH is Switzerland.

--
Miloslav

[MeldaProduction]

You know there's another Checz developer who makes the Togu Audio Line

Just a small clarification: Patrick Kunz from Togu Audio Line is not a Czech, but a Swiss. Maybe you have been misled by the similarity of the internet domains: CZ is Czechia, CH is Switzerland.

--
Miloslav

Hehe that's a good point .

[MeldaProduction]

I asked him once not for VST3 but for DSP based plugins since I think that would be major good, and by the same token if such as yourself could make a drum synth, you'd all be paid and I could buy and get support that way.

BTW do you have a demo drum synth program?

Sorry to be OT

I don't understand - MDrummer contains pretty much the most powerful drum synthesis engine I'm aware of. Just check the MDrummer Small (which contains demo).