KVR Audio

grymmjack · Post by **grymmjack** » Sat Feb 11, 2012 3:41 am

Hi.

Considering getting into plugin coding using C++ but only really interested if SysEx is doable using VST v2.4.

What am I up against, and is this a fools errand?

Thanks in advance!

arakula · Post by **arakula** » Sat Feb 11, 2012 6:45 am

SysEx is doable... but there are quite some hosts that don't implement this feature, or only in a limited way (for example, there were Cubase versions which could only do SysEx with up to 16 bytes), so don't expect that your PlugIn will be universally usable.

grymmjack · Post by **grymmjack** » Sat Feb 11, 2012 5:56 pm

Thanks.

4damind · Post by **4damind** » Sat Feb 11, 2012 6:24 pm

All developers having a workaround because of this restrictions.

1.) Instead of sysex, transmit controller messages if the plug-in is something like a hardware controller/patchmanager. This works with devices with not too many controller data. But this needs eventually some routing for the user so the plug-in can send and receive controller messages.

2.) Only handle loading/saving of sysex files, the user must use another (standalone) tool to receive/transmit data.

3.) Implement a own sysex handling with some settings where the user can select the midi devices to use.

grymmjack · Post by **grymmjack** » Sun Feb 12, 2012 3:37 am

Thanks 4damind.

aciddose · Post by **aciddose** » Sun Feb 12, 2012 4:40 am

if you have any option, it's a much better idea to go with NRPNs in almost every case.

even sending whole presets can be managed quite efficiently by setting up the NRPN (98, 99) and then sending out data to data entry (6). since midi has the ability to drop all data except the new 7+1 bits you send it means you get almost full bandwidth AND you have both parameter and channel selection.

it's also guaranteed to work with any device that will transmit CCs correctly, which includes pretty much everything.

sysex is, for the purposes of transmitting control information or blocks of data, pretty much obsolete.

grymmjack · Post by **grymmjack** » Mon Feb 13, 2012 2:03 pm

aciddose; Thanks. I don't have an option. I am already using CC's (and NRPNs) in Max4Live. I guess some context would help; I'm attempting to create VSTi/VST editors for my hardware gear, that don't suck and are complete to the spec including sysex.

Up until now I've been doing it without sysex, and I am missing out on some of the deeper editing that I am OCD and perfectionist enough about to be driven mad by it

For example on microKORG, the delay type, on MS-2000 the swing value for the MSEQ# lines. I've got CC's and NRPN's already working in MAX, but because Ableton Live completely ignores inbound SysEx through it, and requires OSC, it's kind of a pain in the ass, hence going native might be best way to go. I have been getting into Renoise as well, and perhaps lua is an option too. Also Renoise has native OSC integration, which kind of simplifies that part if I need to make OSC client/servers for even my native plugins to work right. I know it can be done because novation did it with Ultranova, and I think Korg did it with the R3 or MicroX something or other. So it's just a matter of getting there

You can look here for my M4L work so far:

microKORG: http://www.kvraudio.com/forum/viewtopic.php?p=4532880

MS-2000: http://www.maxforlive.com/library/device.php?id=900

These dead end at sysex. I am aware of the OSC client/server work around in MAX, and I'm considering that as well, but for now what I'm thinking is just bite the bullet, make some MIDI VSTi plug-ins, and get right at the hardware, hence this thread topic.

I would like very much to emulate to the maximum degree the relationship I have with my hardware just as I do my software plugins. The convenience of software is too huge to miss, and the dedicated processing and sounds of external hardware is too worthwhile not to pursue.

So being glutton for punishment I'm thinking about it...

I've looked at FLStudio Dashboard, no SysEx support there. I've looked at MIDIQuest and SoundQuest, and those mostly work, but they aren't plug-ins. The plug-in version of those things I've heard is not perfect; and I'm of the opinion that I can do a good job emulating the look and feel to further enhance that native integration or total integration (if you're a virus owner, I am not) aspect of this pursuit. I've got quite a lot done on MAX4Live and I'm very happy with most of this work, it's just the little fiddly bits I cannot access driving me nuts. I've considered SynthEdit, and emailed Chris and he said that I could do some of this with SE but to create messages I'd need modules or something. I'm not fond of SynthMaker very much, even though I know FLStudio uses it quite successfully on the sysex front, I've never had good luck with those sysex SM plug-ins in FLStudio, or any SM plug-in except 1 or 2 (even when Atomsplitter and I made them and so I'd prefer to skip SM altogether). I know a little about CTRLR, but when I downloaded and used the MS-2000 plug-in, it was not able to reach some parameters either, which could mean that the designer of that panel didn't implement everything or perhaps CTRLR is unable to do sysex through their VST wrapper.

I know enough about programming to know that once the initial problems are solved, it should be not too difficult. What I'd like to do is perhaps start with my MS-2000, and then microKORG and get those editors built and perhaps sell them for a small profit. If the sales warrant it, as I extend my own hardware collection, I could then create other native plug-in editors for each I own.

I've been looking for a reason to get back into C++ and this seems like a great way for me. I have a very fixed goal, and very rigid path to get there which will hopefully keep me on task

Thanks for your help.

obiwanjacobi · Post by **obiwanjacobi** » Mon Feb 13, 2012 7:28 pm

How will those plugins communicate with the hardware device? Aren't all midi ports locked by the host application the plugin is running in?

I also have some hardware that I would love to write some editing software for but the issue I described above, always kept me away from building a plugin.

MidiQuest never really worked for me. Always some error when loading information over MIDI into the program.

I'd be interested in how you're doing implementing these plugins.

BTW: If you ever consider building a generic editor (like MidiQuest), I have a prototype-idea lying around that could help...

4damind · Post by **4damind** » Mon Feb 13, 2012 7:53 pm

obiwanjacobi wrote:How will those plugins communicate with the hardware device? Aren't all midi ports locked by the host application the plugin is running in?

The midi device/driver must be support multi-clients without this it doesn't work.

Caco · Post by **Caco** » Mon Feb 13, 2012 8:16 pm

Hey Rick, if you want to keep things simple then just build it all with Sensomusic Usine. Usine has a Sysex Editor and can even export your patch as an independent VST if you want

aciddose · Post by **aciddose** » Tue Feb 14, 2012 12:30 am

you can also just route the output of the controller to the right port easily enough in most hosts, if not all.

that's what i do. it's easy of course to get drivers to wrap your hardware to allow them to support multiple clients and do mixing of the different ports as desired; it's easy to handle midi yourself and deal with events and so on directly; it's easier to just use the existing capabilities of the host that you need to be running in anyway.

for example, if you wanted to have a stand-alone version you could just write a mini vst host with input/output for midi and pre-route the plugin as desired.

this makes the most sense of any approach, it's modular and re-uses existing systems to the max while being compatible with the manual implementation with zero overhead.

grymmjack · Post by **grymmjack** » Tue Feb 14, 2012 1:38 am

obiwanjacobi wrote:How will those plugins communicate with the hardware device? Aren't all midi ports locked by the host application the plugin is running in?

I also have some hardware that I would love to write some editing software for but the issue I described above, always kept me away from building a plugin.

MidiQuest never really worked for me. Always some error when loading information over MIDI into the program.

I'd be interested in how you're doing implementing these plugins.

BTW: If you ever consider building a generic editor (like MidiQuest), I have a prototype-idea lying around that could help...

Well as a plugin they would receive on MIDI channel sent, for example.

I am not trying to build a MQ type of thing but I'd definitely create wrapper code to make the stuff reusable. Thanks for your offer though.

I'm still learning what options there are. Usine is new one

grymmjack · Post by **grymmjack** » Tue Feb 14, 2012 1:39 am

4damind wrote:
obiwanjacobi wrote:How will those plugins communicate with the hardware device? Aren't all midi ports locked by the host application the plugin is running in?
The midi device/driver must be support multi-clients without this it doesn't work.

Why? If its through the software VST would it not just use this and not need redundant parallel connection? This is how M4L works at least.

grymmjack · Post by **grymmjack** » Tue Feb 14, 2012 1:41 am

Caco wrote:Hey Rick, if you want to keep things simple then just build it all with Sensomusic Usine. Usine has a Sysex Editor and can even export your patch as an independent VST if you want

Caco long time friend

Can Usine created stuff be fully skinned up with custom controls? If so I'll definitely check that out. Part of the fun is the programming part is the design work

grymmjack · Post by **grymmjack** » Tue Feb 14, 2012 1:47 am

aciddose wrote:you can also just route the output of the controller to the right port easily enough in most hosts, if not all.

that's what i do. it's easy of course to get drivers to wrap your hardware to allow them to support multiple clients and do mixing of the different ports as desired; it's easy to handle midi yourself and deal with events and so on directly; it's easier to just use the existing capabilities of the host that you need to be running in anyway.

for example, if you wanted to have a stand-alone version you could just write a mini vst host with input/output for midi and pre-route the plugin as desired.

this makes the most sense of any approach, it's modular and re-uses existing systems to the max while being compatible with the manual implementation with zero overhead.

I am already doing this with some success in M4L the problem is the gear I own requires sysex. Live ignores sysex at input hence OSC work arounds.

The goal is a 2way connection manifest in a plugin. Wiggle knob on hardware wiggles software and software settings do vice versatile sans physical movements. I can achieve this with some effort in a rigged way using ,y M4L devices and midi map the knobs but Ableton does not remember these. I have worked around this by assigning cc and nrpn thru modules in M4L but it's kludge.

I want a plugin, routed automatically with a beautiful interface and named VST parameters for automation

SysEx using VST v2.4