how to work around midi in VST3?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Also, it seems that you can technically send MIDI events (note on/off, etc., not CC events) via an event output bus, but not every host supports this.

Post

My understanding about the Event Output Bus is that is just the midi outs that your DAW detects, or should detect, as available midi outputs back to the DAW itself..not the same as sending directly to a midi device if that's what you meant. So that in theory, inside the process function you have the good ol' midi buffer...which in VST3 only has Notes and NoteExpressions. Whatever your plugin leaves there should go out the Event Output Bus...just like any other midi output. Its just that with VST3 you can define more than one input and output bus, compared to only one for VST2.

CC's on the other hand, have to be handled specially because they are not on the good ol' data buffer like VST2 days. You can get the incoming ones by looking at parameters, presuming the host knew to place all CC's into parameters prior to the callback. The legacyCC output function that was added, i'm not really sure what it does exactly, but a lot of hosts aren't calling it anyway, so we can't depend on it right now.
Last edited by Dewdman42 on Tue Jan 21, 2020 9:19 pm, edited 1 time in total.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

ps I am not aware of any DAW's or hosts that are ignoring the event output bus with notes right now. Do you know any? I do know that JUCE's support for VST3 does not include multiple event bus, so if a host is based on Juce, then it probably will only see the first event out bus...and it will work at least for that one. I don't know any host that is ignoring notes from the first bus right now. But I'd like to know if so!
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

Thanks for the information. That’s all with the latest VST3 sdk? Just checking... 🙂

Post

As I understand it.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

But what's the use of returning 'unused' midi events if I cannot route them to a different instrument?

Post

I don't understand your question or point I guess.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

Dewdman42 wrote: Tue Jan 21, 2020 9:13 pm My understanding about the Event Output Bus is that is just the midi outs that your DAW detects, or should detect, as available midi outputs back to the DAW itself..not the same as sending directly to a midi device if that's what you meant. [...]
You're saying that I can send MIDI events back to the DAW/host, but not to a different MIDI device/virtual instrument, right? If that's the case, what else should the DAW need unused MIDI events for, if not for sending them to a second instrument?

Post

no, I think we're missing each other somehow but I'm lost as to what you're asking or saying to be honest..

VST3 is not designed for midi thruput. According to Steinberg, VST2 was also not intend for midi thruput either even though many people created midi plugins that are able to function that way. With VST3, Steinberg broke that capability, and they don't care because they don't see it as being an important feature of VST2. They see it as being completely outside the VST api, and also they do not want midi processed inside VST plugins. They are trying to push an abstracted model that removes midi entirely from plugins and has this responsibility laid on DAW's. Anyone making midi VST plugins are basically skating on thin ice outside Steinberg's intention for VST.

There is some limited midi work arounds that some people are trying to use in VST3, but they are basically don't work consistently because not all DAW's are handling this the same way. If you are making plugins that are intended to output midi, you probably should not make it with VST3 honestly. And for non-note midi events, probably you should not be messing with that inside VST plugins either. Just notes and parameters. that is the VST3 way.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

VST2 obviously was a working solution for common problems in music production. I just wonder why Steinberg who was lucky enough to establish a standard does not see that this also creates a certain responsibility!
VST3 solves a lot of problems and has nice concepts pointing into an unknown future, but cutting off existing solutions for real problems (and that only with legal forces), and at the same time claiming it was never their intention to solve those problems is on a scale for ignorance from 1 to 10 a 12 minimum (I’d rather say +infinite...)
It shows clearly, leaving standards to a single company is dangerous! If Juce/Soul (Roli) and all plug-in developers hopefully including Steinberg sit together and define a real as opposed to a quasi standard. I don’t see a problem to get Midi back. It could as well include any other stream of information like OSC or images and video... Usually standards get enhanced not cut down...
Btw. though I never published a plugin, I did sign the VST2 license (just in case). Is it possible to aid developers who did not? Maybe found a company for just that?

Post

FYI: Midi CC Out via LegacyMIDICCOutEvent is now working in Reaper 6.04

Post

This is I think a terrible error from Steinberg to remove native treatment of MIDI-control: Musicians want to plug an instrument to a VST and begin to play not only with notes but also with pitchbend, aftertouch and control (modwheel for example). This is all now impossible or complicated. Musicians want to make music and not always worry about the setup. It must be simple!

Question: where is a good start for developing MIDI-plugins? (please no JUCE)
before time there was no time

Post

JUCE :D

Post

Juce is the easiest way but the problem you have is that you can’t get a vst2 license from Steinberg anymore so for any host that uses vst you will be crippled by vst3 midi limitations. On the Mac you can develop AUmfx plugins for logicpro that are not crippled that way. If it’s only for private use then you can make vst2 plugins with or without juce that will work in vst hosts, but technically speaking steinberg doesn’t allow you to do that, but if you never distribute it then they will have no way of knowing.

Blue cat audio also has one interesting solution which is that you can make midi plugins using their plugNscript product using Angel script. Its GUI capabilities are limited compared to juce, but it can also export standalone plugins that are vst2 without violating any steinberg license, you’re piggy backing on blue cat’s vst2 license. And you can even distribute those exported vst2 plugins to other people that don’t own plugNscript and they will work! But it’s midi API is very crude compared to juce, and so is its GUI capabilities. Quick prototyping though since you don’t have to recompile every change.

If you want to code in c/c++ then you cannot legally develop vst2 plugins period; with or without juce or any other sdk for that matter such as Iplug; unless you previously had a signed vst2 license agreement with Steinberg and they grandfathered you in.

Vst3 is crippled for midi and that is unlikely to ever change because Steinberg has a different philosophy about the purpose of vst tech
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

So much of these problems would have been solved 15 years back if we had a none-profit standardization committee/association that have representatives from major software and hardware makers sitting together and making sensible decisions that fit all pockets and publishing detailed standards. Well that's actually how MIDI was initially made when Dave Smith sat with Roland and Yamaha and made it happen 35 years back.

Something like the IEEE association or ACM. These are the reason why all these electronics, WIFI, 3G, 4G, Ethernet etc... of today works together. Some thing should be at place for music.
www.solostuff.net
Advice is heavy. So don’t send it like a mountain.

Post Reply

Return to “DSP and Plugin Development”