May 5, 2017 at 16:38 #3177ecksrhaeMember
Has anyone tried running live professor on a Linus operating system? Or even knowledge of how it does/might behave on a (technically unsupported) OS? I’m considering using KX studio to try to reduce as much of the load and hopefully latency as possible in the system.May 8, 2017 at 08:33 #3753
Interesting. I’m not sure how you can make it run on a linux system. More to the point how many plugins are there for linux actually?May 8, 2017 at 14:40 #3754alexsalmonaaudioMember
Having spent some time in Linux playing with various audio goodies I would agree that there is a potential for very low latency with ALSA drivers BUT I also agree that there is not as many commercial plugins for Linux. There are quite a few very nice LV2 plugins for Linux and supposedly VST is an architecture that can potentially work on any platform (someone I’m sure will correct me on if there are already a vast amount of VST plugins for Linux). In theory you COULD use something Wine for running the VSTs for windows but as I understand it, its not very stable (specially on something like Waves plugins). With all that said I think the best use for Linux would be something like what Waves does which is use a Linux OS running on a headless PC on its soundgrid network for DSP processing of its plugins. If there was a way to do the same with LiveProfessor and throw the number crunching to a remote networked PC and only run the interface locally that would be great. Since the cost of putting a soundgrid system together is pretty high if your working on a lower budget. Just my 2 cents.May 8, 2017 at 18:56 #3755ecksrhaeMember
That’s actually a very insightful, thanks AlexSalmonsAudio! I was not sure of the plugin situation for linux myself, but setting up a separate high speed "cruncher" processor sounds like a winning proposition given the resources and ability… would that end up using ALSA drivers from the linux system, or the drivers of the interfacing Win/Mac system? Apologies for broad questions – I’m not able to actively play around with this at the moment.May 9, 2017 at 07:48 #3756
Thank for that update Alex.
I have been thinking about this for some time. I could compile LiveProfessor for Linux, that would be relatively easy. And using linux you can do all sorts of tricks to get latency down, and even make cpu cores only work for audio etc.
BUT. again, it would be useless because there are "no" plugins.
What waves does, is they have their own plugin "platform" or format if you like. then they create wrappers for VST/AU/VST3/AAX and so on.
So they can run their plugins on a linux or on a soundgrid server or what ever. but not as VST or AU plugins.
A plugin written only as Windows, vst will need to be rewritten to work on linux.
This is unless you use a framework like Juce.com to write your plugins, that would be more like the waves approach.
Bottom line, if someone can provide a list of high-standard plugins for linux I would consider supporting the OS. The other way would be that we created these plugins ourself but that is another question entirely.May 18, 2017 at 20:21 #3752alexsalmonaaudioMember
Hey guys. Sorry was swamped at work and just got around to seeing this… Thanks for the clarification Nikolai! That explains a lot as at why sometimes waves plugins can be very unstable. I guess its the price to pay for flexibility.
Here is another idea then… What if we flipped the table and we ran ran the plugins on a windows machine BUT LiveProfessor runs as a service at startup so the machine can pretty much run headless. Then we could have a "Remote Interface" piece of software that essentially controls the interface remotely from another machine (basically no overhead because its not really "processing anything locally"). This could mean that you could essential compile the "Remote Interface" for some really lightweight hardware like a Raspberry Pi. Which then allows for a very tiny box for front of house to remote control the "Processing Engine" on stage. Does that make sense? This also would allow for potentially multiple "Processing Engines" to run on a network and use something like Dante to toss the audio around from point to point. Each Windows "Processing Engine" would run a copy of LiveProfessor with no interface its just running the DSP part of it and the "Remote Interface" could control multiple "Processing Engines" from one place. This way if you want very elaborate processing chains for your project you can split them out to multiple machines. As customers we could purchase one licenses for the "Remote Interface" and then purchase a license for each DSP "Processing Engine" that we need. I hope this makes sense. I think it would be a very cool distributed processing system.
Also Nikolai I think your Mixer plugin is an awesome start to creating your own virtual mixing console. I think over time it could rival Waves own LV1 mixer if it got integrated into LiveProfessor itself and maybe even integrate everything I discussed here into a full mixing system. I know I went off the deep-end here but if you would like help developing this I would be happy to contribute however I can. I am not a coder (I have written my own bash script based software for audio for various things) but I can certainly supply ideas and perform testing if you need it.May 19, 2017 at 08:41 #3751
Yes a system like that would be ideal.
There is one big challenge though, the plugin GUI.
So the way plugins work is that they are loaded as one single app. the UI and DSP are connected very tight.
So for the remote/master to be able to see and change the UI of the plugins running on the satellites, we would need to open the UI on the satellite and then use something like VNC or similar to get access to the UI.
You could of course control the plugin using OSC from the remote, but I think everybody wants to see the ui with meters etc.
Would have to investigate if this is technically doable in a way that is transparent to the users.
Two other major features I’m planning that would be connected or related to this, is some sort of remote app that can control key features of LP.
And also add some functions to allow a backup or redundant rig to stay in sync with the main system. (and then have some external piece of gear actually doing the audio switchover)
Design input is always welcome
You must be logged in to reply to this topic.