Midi plugin built in sdk

[steveschow]

One problem that many people have is that new developers cannot acquire vst2 license and legally develop vst2 midi plugins. Vst3 unfortunately has some real drawbacks for midi plugin development.

I assume kushview has a vst2 license. If it were possible to easily develop full juce midi plugin modules that end up linked into kushview element in some way as built in midi plugins, including any and all normal juce processing that would be the case as if it were being developed as vst2 plugin; but not distributed as a vst2, rather as a built in module in element; then it could be possible for people to develop full featured vst2 midi plugins that only can run inside element, but also piggy back on element's Steinberg license, though I guess there would not be a way to sell those, only to donate to the element plugosphere.

In any case I think this should be doable but it would be could to find out how someone could fairly easily integrate a juce-based module that way

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[mfisher31]

For Element-specific plugins/extensions, I'm moving toward Lua. Right now it can be done with the Lua node and/or scripting node, but see #126 . This will be an extension to the new Script Node but allows them to show up as self contained plugins and will live externally from Element so user's can redistribute them.

Or.... I might suggest just writing an LV2 plugin. Mac PC will be getting lV2 support in 0.46. If you want to go this route: https://github.com/lvtk/lvtk <--- C++ wrapper for LV2

[steveschow]

Lua doesn't have enough GUI capabilities. Guess you aren't getting my point. Oh well

[mfisher31]

Gui created with Lua, inside element

[mfisher31]

I've created an interface to directly bind Lua to JUCE objects... and have also made Components inheritable from Lua with custom drawing and event handling. It'll some elbow grease to fully bridge the GUI api, but this is one of my top priorities moving forward.

[steveschow]

Seems like it will be the very best midi and audio "scripting" when its done I will definitely keep an eye on it.

[steveschow]

since you seem to be focusing a lot of attention on Lua now...I would like to make one suggestion...

1. Please consider adding slightly more built in functionality for midi buffer handling. The ability to queue midi events in the future to a timestamp is very crucial. Otherwise scripts will commonly have to implement LUA code that can keep a timestamp based queue in LUA so that in each process block it can look at the queue to see if any events need to be added to the midi buffer of that current process block. A good midi Scripter facility needs to be able to simply in one line schedule an event in the future to a timestamp of some kind.

The only midi Scripter out there that can do that right now is LogicPro's built in Scripter. But its a really important feature for midi processing.

while I'm at it, please make sure there is a way with Element, perhaps in a script too, to specify a latency value for the midi filter.. That way a Script can do lookahead processing.

I could probably come up with a few more little things. I have a lot of experience with LogicPro Scripter... Please feel free to reach out... I see tremendous potential with Element Lua for midi scripting purposes.

But mainly the reason I keep looking at some of the other scripters, like ProtoPlug and BlueCatAudio but then deciding not to use them, is primarily because of no ability to schedule things in the future...which means I would have to write a bunch of script code to do that...which fine, could be done, but it just steers me away back to LogicPro Scripter...or just writing my plugins in JUCE anyway.

Another thing, that won't be that easy but would be very helpful, is if Element could support midi ports in VST3 and AU3. I think probably you are already supporting the ability to host a VST3 or AU3 plugin...and if they are using more then one midi port...then expose them. But the question is...is the Element.VST3 or Element.AU3 plugin ITSELF able to expose to the DAW host multiple midi ports? I doubt it because JUCE currently doesn't support that. I have asked them a bunch of times to add that but get nothing but crickets about it...but its really needed. I'm sure it could be added to a fork of JUCE...but I don't understand enough about the JUCE codebase nor about the VST/AU SDK's to attempt such a thing myself.

[mfisher31]

Thanks for the insight. Going to break these ideas out to tasks. Multiple MIDI ports with juce is going to be a tough one for them to do. One reasion is processBlock only takes one Midi "port" with the single buffer param. So they're looking at redefining the Api to make it happen (or so I assume)

[steveschow]

I haven't been able to get anyone over there to respond to my requests about it for several years now. Julian is mostly working on SOUL now. No response, and no idea if they are even considering it. I think it could be possible to fork JUCE for someone who understands the JUCE framework enough to know how it translates to AU and VST...I currently do not.

Definitely JUCE is needing to make it so that you can code your plugin once, and it would work across AU2, AU3, VST2, VST3, etc. The old AU2 and VST2 approach of a single buffer was perfectly valid since they didn't have multiple ports. Obviously they would want to avoid breaking a lot of JUCE code out there, forcing people to re-code all their plugins to receive different data in their callbacks... so that is a primary problem, unless they can embed the port into the midi event info in some way, but there may not be any spare space left in that structure to do that.

[steveschow]

But anyway, I like that your LUA modules will support midi ports...because at least it should be possible within Element to write scripts that can re-route midi to different cables, going to different instruments, etc..

The big problem that I currently deal with, musically, is that I use VSL VePro7 a lot, as do many film score and orchestral composers. And Its generally very useful in that setup to use multiple midi ports in VePro, so that you can have, for example, hundreds of tracks in the DAW feeding into one single VePro instance(each instance in VePro has its own isolated mixer).

Normally, we can just use VSL's VePro.VST3 plugin, or AU3 plugin in LogicPro. This can then allow you to use hundreds of tracks in the DAW that will sent to the VePro server with port and channel encoded in each midi event and will get routed to the right mixer channel in one single instance.

however, when trying to do various kinds of scripting related to key switching and other tasks...a tool like Element is really important, for one thing, in order to use something like LUA to perform that work, but even if using a third party Scripter...whatever..the point is inside Element you can setup a midi processing chain so that this keyswitch massaging can take place..and believe me there is a lot of stuff like that which often has to be done, including time-based.....and then hypothetically cable that up to the VePro plugin, all inside Element... This could be inside Element (inside VePro), which is currently the only way to process midi plugins in VePro; or it could be in the host DAW...and most DAW's do not provide a straightforward way to chain midi plugins in front of instruments. Usually its more hassle then its worth, if possible at all.

But in any case, the primary problem I'm getting to in this situation...is that since Element does not provide multiple midi ports to the host DAW (due to JUCE), that means it cannot really be used for this purpose of handling up to 48 ports (768 channels) from the host to the VePro server. Inside Element, I believe Element can host the VePro.VST3 and expose all 48 midi ports and all that, but still the host DAW can't make use of it once its inside element...so that negates using it at all for that situation.

hope that makes sense. I realize though.. getting JUCE to handle multi ports simply may not be that easy, and perhaps for backwards compatibility reasons more then any...but there are also some other problems with VST3 midi handling and again, JUCE is behind the curve..as are a lot of host DAW's...so that's yet another entirely different topic not related to multiport at all, but related to the fact that VST3 separates different midi event types into separate streams and thus loses absolute serial ordering for a sequence of different event types that are on the same sample offset.