This is all great news! Is it the case that VST3 is not as duff as most developers seem to suggest?
@brad (and others) - do you know of any VST3 plugins that take midi in and that generate midi out? VST3 (at least the original spec) did not allow that, and development tools like Juce (currently) do not support it. So I’m wondering to what extent Cantabile will support it. I have such plugins but since Juce does not support mini/in out for VST3 there’s little point I guess in trying these? But FWIW @brad, if interested I can shove you a VST3 version of my plugins to test if you want; I’m going to guess Cantabile will not see midi in on 'em (and possibly not even midi out)… but if you wanna give them a shot we can do that.
Or, alternatively, if you want to give me access to a development build I’m happy to test that for you myself!
It’s not great… but I can’t even really put my finger on exactly why. It guess it just feels complex.
Not off hand. This is vague topic according to VST 3 spec. There’s this post which suggests it’s partially possible. Currently Cantabile will provide an output events object to the plugin and will read out any supplied events and forward them as MIDI events to the plugins MIDI output port. However, for VST 3 it’s somewhat limited in that it will only handle kDataEvent, kNoteOnEvent, kNoteOffEvent and kPolyPressureEvent.
The other thing in this area is MIDI effect plugins (as documented in the VST Module Architecture SDK) which I’m not supported at all at the moment.
Sure. Contact me via email.
Happy to do that, but currently don’t have anything in a buildable state
Unfortunately this parameter work is requiring some fairly far reaching changes.
Because parameters now need to be referenced by id, and the plugin can use arbitrary 32-bit values for ids, and because Cantabile needs some of that 32-bit space for it’s own parameters, there’s the possibility for clashes. So I’m currently in the process of updating various places that reference parameter id’s to use 64-bit values and this requires changes that spread through state management and bindings and as well as some other areas.
Also, VST 3 plugins support double precision (64-bit) parameters. VST 2 only supports single precision (32-bit parameters) so I’m making changes to facilitate that at the same time.
There’s a lot of changes here but they’re mostly simple (just changing types), I’m pretty sure they don’t affect saved songs/racks. Also I’m cleaning up and simplifying some of the internal API’s as I go.
First build to include all this will be very experimental.
Anyway, I hope to have things building by tomorrow. (fingers crossed).
Today’s update: everything is building again, parameters seem to be working though I still haven’t found a plugin that actually changes its parameter set at run-time. I might have to write a plugin just to test some of this stuff.
The rest of today was spent testing with some other plugins, trying to track down various issues, emailing plugin developers that seem to be going against the VST3 specs and posting to the VST developer forums to get clarifications on these issues.
Ugh, not fun.
Sounds like good progress. I know it can not be much fun making such a major change, but I think Cantabile will be so much the better for this update, and it would be good to rationalise my plugins to just VST3 installs where supported.
If it’s any consolation, I’m currently battling writing an x.factory Java librarian for my Roland FC300 MIDI foot controller (before I start one for the Yamaha Montage) and its really esoteric MIDI implementation, which is not consistent with the SYSEX specs that I managed to wheedle out of Roland (but with no support on offer)! On the plus side, it is now basically working. On the negative side, I have discovered that the Roland FC300 does not dump everything you program, which is a major problem. So I am busy writing a bug report to Roland.
Ah, the joys of programming…
Java, Roland, inconsistent specs and faulty MIDI implementations - sounds like an all in one insanity pack
Sigh. Another day of debugging… not much progress.
Also, seems quite a few VST 3 plugins are built with Juce and I have some questions about how it works. So today spent some time getting open source plugin Helm building so I can now debug through both the host and plugin sides of the code.
Side effect: I noticed this plugin has the same display issues as a couple of others where in per-window resolution mode the display only occupies a quarter of the display area. So maybe I can finally figure out what’s going on with these plugins and get it sorted.
Juce is probably THE audio development framework at the moment. @brad if you have questions about how Juce does VST3, their forum has a bunch of really helpful folks. I strongly suggest you post your questions there! https://forum.juce.com
It does have that effect on you!
Java is the easy part (been using it for 20 years now and it does live up to its cross platform promise). The big remaining issue for me right now, is that the FC300 allows you to program up to six CC MIDI messages for both of its two expression pedals, and in some songs of mine I have two CCs programmed on a pedal, but the FC300 only dumps the first one for each pedal. Which means that all the backup dumps I have been taking over the years as a backup would never fully restore the pedal if I needed it (which is usually ten minutes before a gig!)
Previously, that would have been a major drag, but right now, I am not to fussed about it (but will report the issue to Roland). Why? Because I will essentially drop down to a single CC per pedal within the FC300 and and I can always generate the extra needed CCs within Cantabile.
Oh nice. And it’s discourse based forum too, even better. Yep, I’ll definitely post some questions there if I get stuck.
For anyone who’s interested in the gory details. This is the kind of detail I’m trying to figure out… plus how to deal with plugins that break the rules.
I spent today fixing the display issue with Juce based plugins when Cantabile is in HiDPI mode. Here’s a discussion about it on the Juce forum. This fixes a bunch of Arturia plugins (since they use Juce) and probably plugins from other devs too. That one’s been bugging me for a while so pleased to have figured it out. Fix will be in the next build - probably next week.
Also, while I was at it, some of you might remember there was an issue with Addictive Keys/Drums where the UI wasn’t drawing correctly. I found a work around at the time, but I spent a couple more hours on it today and finally got to the bottom of what was really going on - it was a problem posting timer messages between threads. You might find the UI in those plugins a bit smoother now since it’ll be running on a higher-resolution timer like they intended.
I hoped to get a bit further with the VST 3 stuff this week, but still happy with progress made. It’s Friday night here in Sydney now - I need a drink.
Fantastic news on the juce stuff. I bought a keylab88, and have been sad I couldn’t use the software that came with it. Thanks a ton for getting to this one. Thousands of new sounds now available to me.
@kirk : out of curiosity, what issues did/do you have with the Arturia software that came with your Keylab88. I’ve been using things like Piano V and Analog lab in Cantabile - both without any issues really…
Only when using 4k display. Check out the link Brad posted for a full description. The plugin interface for all Arturia vsts is shown undersized in a portion of the window, which is obviously wrong. What makes is unusable is that the mouse interface is actually at full size, so the visual interface and mouse interested don’t match. I had believe it was an opengl problem, but maybe @brad has found a solution.
Problem only seems to be in c3 though, so I’m hoping. As of latest experimental build tonight, still broken.
Ok, makes sense, I don’t do 4k
Yep this was only an issue when running at non-standard DPI scaling.
I described the problem in some detail at the above link to the Juce forum. In short Juce’s rendering thread was running in a different DPI awareness context to the UI thread resulting in an incorrectly scaled viewport. The fix I added to Cantabile hooks thread creation and inserts a small stub function that sets up the correct DPI context.
It also happens in Juce’s Audio Plugin Host. Basically it happens in any DPI aware host that doesn’t take measures to work around it. I’m hoping Juce devs will add a fix too.
Just downloaded 3609, and shazam! Arturia plugins scale perfectly. Well done and thank you.
Very grateful for all the work, and for the communication, Brad.