You’re right, but I’d prefer an iziotope ozone than the original dsp eq. and this is just one example …
The new Dirac will require a VST host I think, and there are some nice VST plugins out there. So what is the easiest (best) way to pipe output from Roon through a VST plugin and from there to a DAC?
On my macbook I use an app called Menubus. There are apps for windows and linux as well but I don’t know how there names.
There are headless (i.e. no GUI) VST hosts, if Roon implemented that it would certainly be better than nothing even if some VST plugins would not work. And it could all run on roonserver, similar to DSP, and then the modified digital stream is sent to endpoint.
It would then be part of the signal path, probably best put between sample rate conversion and convolution/PEQ. Maybe @brian could explain why I am wrong (I always am in these situations) ?
To run a VST as part of the Roon Core and accommodate current + potential future plans, it would have to be more cross-platform than any VST plugins that I’m aware of. Linux support is particularly limited, but it would be very difficult for us to release a major piece of interoperability and leave ROCK and Nucleus out in the cold.
I don’t think that we could confidently market a VST feature that was hobbled with a “headless only” limitation. It would raise questions and breed discontentment. The group of people willing to slog through and use something like that would be a small, technical subset, not our general user base.
I don’t see much of a way to make this work. The compromises are too great, the effort is not small, and the best possible product that we could build inside the constraints is not a very satisfying one.
I used menubus a while back and the engineer paralyzed the development because he was hired by Rogue Amoeba. I think it does not work properly in Mojave anymore. What version of Mac OS are you using?
I’m using High Sierra. I always wait at least half a year with macos updates because of compatibility issues.
I think it is possible to do it properly, but maybe not easy and you have to allow for some limitations. Something like this:
- Implement an VST host app, this app will allow pipeline of VST plugins to be configured, but the VST plugin GUI will not be available unless its run on the same maching that Roon-core is run from. Here is a screenshot how this might look (this is Cantabile Lite, but MIDI stuff can be removed):
- Integrate this app into Roon GUI, with same limitations (or integrate and share GUI between the apps).
- I think VST plugs export something like “configurable parameters” which could be used and set from Roon even if core is on another host, but with a simplified GUI (and some additions to RAAT). Here is how that GUI looks in Cantabile Lite for a convolution VST plugin:
- To use the regular VST plugin GUI, you would have to log into the core host and run the VST host app (from 1) manually, but once everything is configured it would stay that way so no need to do it more than once.
This would mean that if you run Roon GUI and core on same machine, everything would work fully with no limitations, but if run Roon GUI on its own host than you could still setup the VST pipeline and do basic VST configuration, but you would need to log into the core-host to install VST plugins and use the plugin GUIs.
Now this is a rather serious investment in manpower for Roon, but with Dirac needing a VST host in the future, and some other software often used with Roon also require a VST host (I don’t want to tell which), it might still be worth it.
The availability of VST plugins to Linux is not really a “Roon issue”, but there are quite a lot of Linux plugins out there ready to be used as long as Linux is run on a Intel CPU.
Note that the VST issue should not affect Roon endpoints, they could be used exactly as now.
Another simplier solution: implement Windows audio endpoint, one output and one input, which can be set from Roon so Roon sends the audio stream and gets it back, before sending it to an Roon endpoint. Or even simpler, don’t implement the endpoints (everyone can use for example VB-Audio virtual cables), just the settings window in Roon to tell Roon to send/recieve to endpoints.
The biggest problems today with Roon and VST is that its not possible (as far as I know) to combine VST with Roon endpoint. Only on 100% local Roon solutions can you use virtual cables and append VST plugins after Roon but before its sent to DAC.
Using VST today in Roon is this chain:
Music data -> Roon -> VST host with plugins -> DAC (Roon endpoint not supported)
If Roon has support for send/recieve to audio endpoint as an intermediate step, the chain could be like this:
Music data -> Roon -> VST host with plugins -> Roon -> Roon endpoint or DAC
@brian surely something along the last 2 post can be accomplished.
Properly, to us, means:
- VST plugins are fully accessible including native UI, regardless of system configuration
- The UI is always accessed through Roon Remote, like everything else in our world.
- All VST plugins are supported, regardless of system configuration
- In practice, VST plugins actually work
A very typical system for us these days is Nucleus/ROCK+iPad. There is no “log into the core” in this configuration.
We are opposed to requiring a Windows or Mac computer on the network to make this work. The limited configuration parameter UI is uninteresting because it’s not what people expect–user interface is very important to many VSTs.
We’re not stupid about technology–we know that schemes like what you proposed are possible. We just don’t agree with the limitations/compromises, or that the expense of building that product with those limitations would be worth it.
Well, it’s up to you guys. One of your competitor has VST3 support and VST2 in the pipeline.
But how about the second option: enable external software to insert itself into the Roon DSP pipeline? This could for example be a VST host, but also something else (mixer and karaoke? ). An added option for those who like to add something externally to the music, and should be fairly fast to implement.
As I said earlier, this would open up a nice way for people who use a Roon endpoint to use things like VST plugins with the help or for example VB-Audio virtual cables.
On macOS HighSierra Roon–>SoundSource4(by Rogue Amoeba) setup to iZotope Ozone 9. Thats it, very easy.
On macOS HighSierra Roon–> Amarra sQ+ for Mac.
I guess this is more suitable to a Roon extension type of functionality to allow the plugins UI to work. These already have to have a windows or Mac pc to use so it kinda of fits. Not sure if the Roon API is able to access the DSP engine though.
I have tried similar solutions with VST hosts and VB Virtual Cable, but it gets harder once you have an endpoint (I have yet to find a solution)
VB Virtual Cables only seem to work with a fixed sample rate though, so you have to up-sample in Roon to a fixed rate if you have music with different sample rates (or MQA)
Yes, You re right. Amarra SQ+ and iZotope Ozone 9 support samplerate up to 192Khz but they is unstable if Roon change samplerate. I set samplerate to 44100Hz as default and is it ok. I am take
a decision, what I am prefer, high samplerate or equalize music.
I think VST “standard” don’t allow sample rate changes, but you can do an up-sample in Roon to for example 96khz, and also let Roon do first MQA unfold, that way normal CDs and MQAs will all work.
Could a person with the right knowledge do something with the VST that won’t be a problem for Roon ?
I mean if you can’t change Roon, can VST somehow adopt ?
Where is the real problem ?
If your answer point towards impossible, can a black box like a NUC, just place is itself in de DSP processing chain, and with some “magic” from either Roon or the DSP developer, make things happen.
I notice Linux is supported as well.