Dear visitor, you are currently not logged in. Login or Register as a new user .
Hi Ace,
Had a play with your plugin yesterday, looks like it does what I need. As I wrote in another thread - it would be perfect if it was possible to use VC just for total recall/editing/patch management (pretty please Access!). But as long as this isn't possible, your plugin provides the total recall part, and the responsiveness of MIDI is great - playing via VC never felt this good, even in Live mode.
One thing felt awkward to me though, that the plugin itself opens the MIDI devices, preventing the DAW from using them. Would it be hard to modify the plugin so that MIDI is sent to/received from the VST host? The DAW would take care of routing, and device selection problem will go away:
I'll look at the code if you make it available, although I've no idea how to send/receive MIDI from a VST plugin. Hope I can figure it out ))
Again, thanks for your efforts!
Had a play with your plugin yesterday, looks like it does what I need. As I wrote in another thread - it would be perfect if it was possible to use VC just for total recall/editing/patch management (pretty please Access!). But as long as this isn't possible, your plugin provides the total recall part, and the responsiveness of MIDI is great - playing via VC never felt this good, even in Live mode.
One thing felt awkward to me though, that the plugin itself opens the MIDI devices, preventing the DAW from using them. Would it be hard to modify the plugin so that MIDI is sent to/received from the VST host? The DAW would take care of routing, and device selection problem will go away:
From the plugin point of view, they're "normal" midi ports, but the device selection in AceVirus is currently based on the device name (must match "Virus TI synth"). I know it's clumsyI'm pretty sure I'll end up adding a combobox to select the MIDI devices, especially for the lucky people owning several Virus
![]()
I'll look at the code if you make it available, although I've no idea how to send/receive MIDI from a VST plugin. Hope I can figure it out ))
Again, thanks for your efforts!
Hi Boreg,
glad to hear my plugin may be of any use!
And glad even more, to learn that the midi responsiveness seems pretty good!
About your remark on the MIDI devices opening: you clearly have a point. Handling MIDI I/O myself (instead of letting the DAW do it) is not a decision I'm proud of ... indeed, it's a lot of code that I was hoping to avoid. Letting the host do the routing would be a great improvement. In fact, this is what the first version of the plugin was beginning to look like.
The problem is many DAW don't implement sysex part of VST : for example, FL Studio VST implementation only allows sysex sending, and energyXT's allows neither sending nor receiving
In one word : it's extremely hard to write a plugin that works well under all hosts (I think Access developers can confirm!
), the problem being that the VST specification is rather incomplete on some points (AFAIK it does not specify what the DAW should do with sysex coming from a plugin). This is very frustrating
But if your DAW (which one is it BTW?) can do sysex I/O, I could add a device selection with a "virtual device" that would correspond to midi ports of the plugin.
I'll make the source available, under the GPLv3 license, you can be sure of that! It's just a matter of time I re-write my GPL-compatible minimalistic VST SDK because the Steinberg version does not fit. It's not a lot of work. However if someone knows one C++ VST SDK under the GPL license, it could speed-up things
Thanks for testing!
glad to hear my plugin may be of any use!
And glad even more, to learn that the midi responsiveness seems pretty good!
About your remark on the MIDI devices opening: you clearly have a point. Handling MIDI I/O myself (instead of letting the DAW do it) is not a decision I'm proud of ... indeed, it's a lot of code that I was hoping to avoid. Letting the host do the routing would be a great improvement. In fact, this is what the first version of the plugin was beginning to look like.
The problem is many DAW don't implement sysex part of VST : for example, FL Studio VST implementation only allows sysex sending, and energyXT's allows neither sending nor receiving
In one word : it's extremely hard to write a plugin that works well under all hosts (I think Access developers can confirm!
), the problem being that the VST specification is rather incomplete on some points (AFAIK it does not specify what the DAW should do with sysex coming from a plugin). This is very frustrating But if your DAW (which one is it BTW?) can do sysex I/O, I could add a device selection with a "virtual device" that would correspond to midi ports of the plugin.
I'll make the source available, under the GPLv3 license, you can be sure of that! It's just a matter of time I re-write my GPL-compatible minimalistic VST SDK because the Steinberg version does not fit. It's not a lot of work. However if someone knows one C++ VST SDK under the GPL license, it could speed-up things
Thanks for testing!
The problem is many DAW don't implement sysex part of VST : for example, FL Studio VST implementation only allows sysex sending, and energyXT's allows neither sending nor receiving![]()
Yes, I'm aware of that. IIRC, Ableton Live also has a problem with plugins sending sysex.
Anyway, my DAW is Reaper which handles sysex just fine
so having the option to use host's routing would be perfect.
Hi all, the source code to my plugin is available on the following launchpad project :
https://launchpad.net/acevirus/
https://launchpad.net/acevirus/
Thanks mate! I've browsed your code, and it looks very clean and easy to follow.
A couple of questions:
best regards,
Boris.
EDIT: Regarding my second question, it seems I need to implement processEvents() and possibly sendVstEventsToHost().
Still, any tips will be greatly appreciated.
A couple of questions:
- How do I download the source from the launchpad site? I found the links to download individual files, but is there an option to get them all at once?
- Could you give me some tips on sending/receiving MIDI from VST plugin? I know, I should dive into VST documentation, but even the names of relevant functions would be a great boost to me.
best regards,
Boris.
EDIT: Regarding my second question, it seems I need to implement processEvents() and possibly sendVstEventsToHost().
Still, any tips will be greatly appreciated.
This post has been edited 1 times, last edit by "boreg" (Oct 10th 2010, 5:21pm)
To download the code, the only way I know is by using bazaar (which is a code versionning system, like CVS). You can then checkout the full source with the command :
bzr branch lp:acevirus
Feel free to send me patches if you have improvements to submit! I'll be glad to merge them.
Maybe one day eXT will support sysex. The response I got from the main developer of eXT was that sysex was not supported by the VST spec.
bzr branch lp:acevirus
Feel free to send me patches if you have improvements to submit! I'll be glad to merge them.
Maybe one day eXT will support sysex. The response I got from the main developer of eXT was that sysex was not supported by the VST spec.
Please keep in mind that for licensing reasons, I'm not using the official VST SDK.it seems I need to implement processEvents() and possibly sendVstEventsToHost().
Still, any tips will be greatly appreciated.
So you can't rely on the specifications of the VST SDK C++ classes, which are not present in this project.
Similar threads
-
Share your tips and tricks »-
So, how do YOU use the LIVE mode?
(Jul 12th 2010, 11:40am)
-
Feature requests »-
EQ Bypass button
(Mar 24th 2010, 8:11pm)
-
Feature requests »-
Filter Bypass or Oscillator Direct Output
(Feb 21st 2010, 7:05am)
-
Feature requests »-
choose which filter the oscillators run through/ and or filter bypass function.
(Nov 30th 2009, 8:18pm)