Max 8 (standalone app) as a reliable VST host?


    Oct 17 2018 | 7:13 pm
    I have been trying to build a VST-host Standalone app with Max 7. It turned out, however, that the outcome cannot match something like Vienna Ensemble pro. Firstly, playback stressed the computer resources way more than a dedicated VST-host, although I tried to play with the settings. Secondly, it was not as reliable and caused crashes from time to time. That is whyI abandoned the idea of hosting the VSTs inside a self built host and kept using VEpro. It would, however, still offer a lot of advantages to be able to do this. Now, with the arrival of Max 8, I read there are a quite some enhancements regarding the efficiency of the code. Is it worth trying this once more? I am not talking about merely loading some synths or samplers. I am referring to load a huge bunch of Kontakt instruments and those samples will easily use up 80% of 128gb of Ram on that PC. I need the ability to activate and deactivate Kontakt instances remotely (via Midi or OSC). So, all of this has to be very stable and be as effective in voice streaming as VEpro. Is that a waste of time to even expect a self-built system to work as well as a dedicated host? Even, if it was possible to get it to work as well ... wouldn't updates of the VSTs force you to revisit the whole thing time and time again?
    How about features like VEpros audio and midi over lan? For Midi, there are enough external solutions. But how about transferring real-time audio via network from Max to Cubase (both from the same PC, where Cubase is loaded, but also from an additional Sample PC with only Max?). This last paragraph is optional, as I could use Madi cards for that purpose. I am just trying to narrow down how to conceptualize my whole composing rig. With VEpro, I know it runs very reliably and I wouldn't want to try building a VST host based on Max once more only to find out it will never run as good as VEpro. :-) I am looking forwards to hearing what experiences you might be able to share, as well as

    • Oct 17 2018 | 7:49 pm
      Yeah ... the thing is, I do want more than VEpro can offer me, but not at the price of being unstable or not running as efficiently. :-) The most prominent advantage of a DIY host would be that I could make the midi bidirectional, meaning, Midi (and OSC) could also be routed from the host to the main PC or Cubase. That would make some really unsolvable problems (due to limitations of both Cubase and VEpro) doable. I am willing to learn, of course. I am not new to Max. I have been using it to successfully build a standalone app to process all incoming midi including Lemur and a complex template control, that updates the control surface dependent on what track is selected in Cubase. I happily admit that I do not have a lot of experience in many aspects of max. I have never done anything involving video as well as a lot of other aspects of Max. Yet, I did this test with just a few software instruments something like two years ago. And just loading some Kontakt patches sometimes made Max crash. I am willing to put a lot of work into that, but I would rather abandon that, if it would mean struggling with the functionality forever. I would only like to do it, if it can be set up in a way that it will work as well as VEpro, once the concept is right. If you say, such a reliable and efficient host can be built with Max, I am happy to try! Where would I start? Which aspects would you focus on? Anyway, the main reason I ask is, what is Max version 8 bringing to the table?
    • Oct 17 2018 | 8:30 pm
      If you have done a patch in Max 7, just load it and see how it behaves in 8. That would give you an idea. If its not as stable as you need it, still send in a bug report... 8.5 might tackle it. I think there are not many "heavy load" users with 128 GB of ram, but Cycling would always be interested to make Max as stable as possible...
    • Oct 17 2018 | 10:06 pm
      the new option to use the VST3 versions of your plug-ins can solve the one or other problem, but it can also bring some new problems.
      back in the days when VST 2.1 came out you could see steinberg plug-ins which didnt work properly in steinberg hosts, go figure. so dont think there will ever be a host program without trouble.
      the massive CPU overload is, in my experience more a problem of effects than instruments. but i guess that you need to run this stuff live? so that going down to a vector size of ten miles isnt really an option for you.
    • Oct 17 2018 | 10:16 pm
      VST3 is not really an option, as Kontakt is only available in VST2 and as far as I know Kontakt 6 will not be available as VST3 either. It is not for live use, but for composing. It still needs to be playable, though, and to much latency is not good. I guess it is the same situation as last time. I would probably take forever to make it run and any Pluginupdate may wreck functionality. My profession is composing and not spending each and every day to enable me to do that. :-) If there would be just one guy here who sucessfully built a host for a huge Kontakt template and used it for a long time without to much trouble, I would be willing to spend time on that. Otherwise, it is probably better to give up on that part and focus on what is possible with the midi routing. Maybe @DHJDHJDHJ has something to say about it ...?
    • Oct 18 2018 | 12:51 pm
      Not sure why you guys are calling me --- I did write a VST host in Max 5 that worked very well. But as Max evolved (6 and 7) , it (Max) became less reliable to the point where we finally gave up a few years ago and developed a commercial audio plugin host called Gig Performer (https://gigperformer.com) . It supports VST and VST3 plugins (and AU plugins on the Mac version) and it's targeted to live performance musicians. It has OSC support so you can send messages to it from Max (and vice versa) to play the plugins, control them and so forth. That's nice in the Windows world as you don't have to deal with virtual MIDI ports, etc. I use it in that manner quite often, particular with legacy stuff, i.e, I just replaced the VST abstractions in my Max system with OSC calls to Gig Performer.
      (Edit: I should have added that anyone interested can connect to our user forums at https://community.gigperformer.com for more info)
    • Oct 18 2018 | 1:17 pm
      Thanks for confirming that I am not just not skilled enough to make Max perform reliable as a plugin host. I had the same experience as you described. I will do the trial of GigPerformer and see, if it does what I need. Not sure, as my requirements are quite different to a live keyboarder. But it may do what I need.
    • Oct 18 2018 | 1:40 pm
      GP is not just for keyboard players. Many people use it in conjunction with Ableton Live and other just systems. If you tell me what you're trying to do, I can tell you quickly whether GP is a reasonable solution for you, possibly combined with Max.
      This link will give you info about communicating with GP from Max via OSC so you can send "MIDI" messages or plugin parameter messages (host automation) to it. Also, when you OSC enable plugins in Gig Performer, then Max can automatically be notified via OSC whenever you change a parameter in a plugin so you can get feedback right into Max if you need that.
    • Oct 18 2018 | 1:54 pm
      What I need is a few things: - The ability to load and unload VSTs remotely via Midi from Cubase - feedback from each host when a track is record enabled or selected (Cubase can send a message to each port/channel, like a dedicated CC to inform the host) - the host needs to be able to return the midi input of ONLY the selected track (channel port) via a dedicated return midi port - this will be sent to max which will give me midi feedback of each parameter for the lemur interface - probably a lot more I cannot think of right now, as the devil is always in the detail :-)
    • Oct 18 2018 | 1:57 pm
      Oh, and most importantly, I need a host where there are a lot of users doing big templates with Kontakt Instruments. The host must remain absolutely stable when a lot of ram is used up (I am talking about 128-256gb per machine with up to 90% being used by loaded samples). Also, it should be able to run on the main machine along with Cubase with no trouble (PC). Right now, I still have a Mac Pro, but I am going to go for Windows soon.
    • Oct 19 2018 | 11:10 pm
      Since I started 'separate strings'-recording of guitars, I think I tested almost all AU/VST hosts currently on the market. Here I deal with a plugin number multiplied by 6, since each of the 6 strings get their own plugin chain. All in all, around 50 plugins per setup is common and this is just the first stage and just for one instrument, a guitar with a hexaphonic piezo or humbucker pickup. Usage is live performance, additionally mixed with other audio source, effects and MIDI instruments.
      Short personal shootout of the most interesting AU/VST hosts I tried on a MacBook Pro:
      • Apple Logic: Beyond a certain number of plugins (depending on the type) it simply bogs down and becomes unusable for live applications. CPU problem. Only workaround is disabling unused parts, which requires a lot of work (= programming) in the Logic Environment.
      • Apple Mainstage: Does not like many third party plugins. CPU issues. Since Kontakt was mentioned – So far I learned from other users, Mainstage and Kontakt are no friends.
      • Max/MSP: Does not like many AU/VST plugins in a patcher. Annoying with loading and caching plugins via the vst~ object. Max would have been my favorite but I experienced remarkable instability and sometimes odd behavior. Not much better with Max 8.
      • Harrison Mixbus: Technically top, great sound, but overall too much CPU usage for many plugins in a live performance.
      • Hosting AU: Too weak, not a serious DAW, just a little helper.
      • AudioMulch: Would be great, but I am afraid this application is slowly dying. Did not dare to use it as a base for future work.
      • Waveform (Tracktion): Looks good, but I did not like the routing system for bigger patches and it has no performance advantages beyond a certain plugin count.
      • Gig Performer: A winner. Good performance, CPU usage, latency, controllability. Unfortunately (for me) the huge and auto-scaling Mickey-Mouse-Graphics make the usage of many plugins in one patch almost impossible. Maybe I did something wrong, but I simply had not enough workspace.
      • Plogue Bidule: Well, finally I am back home ... one of the oldest apps is my number 1. Best performance with many plugins, great controllability and internal modulation plus the obvious additional power due to built-in engine and object library.
      Please note: I neither have nor tried Cubase, Reaper, Pro Tools, Studio One, AuLab. I would recommend Plogue Bidule as a host for many plugins and Gig Performer for a medium plugin count. Bidule is a beast on it's own, but once you got the idea about modulations and controlling, you can easily use it as a host to support another DAW. I use the Bidule standalone together with Logic.
    • Oct 20 2018 | 12:36 am
      Peter, thanks for the comments about Gig Performer. I'd really appreciate it if you would visit our forums to discuss this in more detail. Your use is certainly an "outlier" compared to what other guitarists using Gig Performer seem to require but we'd love to know more about what you're trying to do.
      It's true that we need to support "containers" and scrolling to make it easier to support really large numbers of blocks (I myself typically use about 10-35 per rackspace), but in the meantime, you could just create six separate GP instances with 8 plugins and manage each string completely separately (create a rackspace for one string, export it and then import it into 5 other instance)
    • Oct 20 2018 | 3:16 am
      I am not within the target group for Gig Performer and don't think that I would be of great help, suggesting functions not appropriate for your users. I am more in experimental music and sound design, rather working in patches with internal dependencies than switching patches. I would use Max, but it does not work for me in this case. As a plugin host I prefer Bidule for it's plugin handling, the parameter linking and the library of active objects.
    • Oct 23 2018 | 1:59 pm
      I just wonder how does Bidule compare as plug-in to the standalone? There must be a reason you prefer to combine Logic and Bidule the way you do... (Assuming its easier to make connections and save settings within the same environment...)
    • Oct 23 2018 | 3:20 pm
      I had performance problems with the Bidule plugin when it contains a lot of plugins itself. I think this is not the fault of the plugin but rather the fact that a host runs in a host and beyond a certain point the two cannot share the load properly. At least this is my theory and probably only applies to my machine and my plugins.
    • Oct 23 2018 | 5:54 pm
      I have come to realize that using something as Max as a DIY host is not suitable for professional work. First and foremost, a VST host for professional work must be 100% reliable. Only with a widely used product such as the major DAWs or VEpro that is the case. Smallet products like Gig Performer are probably good, too, if you are performing live. I habe Bidule as well and I am currently investigating the possibility to host a Bidule plugin for every midi port within VEpro to send back the desired feedback to Max, however, VEpro has already crashed two times with Bidule loaded. Otherwise, VEpro has been very reliable even with huge load ... I guess, with software it always is a risk to combine stuff hardly anyone is using in that way. The probability of bugs just seems to increase exponentialy ... which makes it so damn hard to make any custom solution work well! :-)
    • Oct 23 2018 | 7:34 pm
      I can't speak to other hosts given that the fundamental reason we developed GP was to build a totally reliable host specifically for live performance.
      It's still possible for errant plugins to crash us (we don't isolate plugins in their own memory spaces yet) and you'd be horrified if you saw how some plugins are implemented (think: gui stuff in the process block, improper locking of resources, yukky). I can't tell you how much time we've had to spend "protecting" ourselves from some bizarre plugin behaviors....sigh
      Having said that, why don't you just network your system and distribute plugins on different hosts if your concern is overwhelming a host? I know we have quite a few users using DAWs, VEpro and Gig Performer all running on different machines and that seems to work very well for them.
      Also, if you're working with Max and Gig Performer, you can always use OSC instead of MIDI to communicate between them.
    • Oct 23 2018 | 7:56 pm
      Well, it is all rather complicated to explain. It's all about a composing template with Cubase and hosts with lots of VIs. But since the host should work as set up once, all project specific data to each instrument must be saved and recallable in Cubase via midi and automation. I have exactly the same problem with all this software that is supposedly work together, but in reality it really does not, because everybody seems to cook their own soup ... Just one example: Orchestral Tools Berlin Orchestra have their own Kontakt script to manage all the CC distribution to parameters etc. This actually is great, but it does not enable you to use plugin automation on any parameter (sigh ...)! So, for this library, I have to use CC and other midi data exclusively. For another library, only a few parameters like CC1 are available with midi, while others are exclusively available for automation. This is just one of countless examples, why it seems impossible to find one workable solution for all libraries. That is why I really would like to use a host like max, where I actually could route and transform all of that data as it is needed. Actually, VEpro is quite good for what I want. It just lacks some flexibility to mange problems as I just described. Well, once again it seems like it is better to forget about some features that could actually be great, but are just to complicated to implement. Cubase, unfortunately does not support OSC, yet. ave I thought about switching to reaper? Sure! But I cannot re-learn all of that - at least not for now. I am always on the search for ways to improve my workflow, but tomorrow, I need to start another composition job, so, the whole process will get interrupted again. Boy, I just wish one of these companies like Steinberg would offer a good solution for composers. But todays software always seems to be directed towards to many customers with completely different preferences ...
    • Oct 23 2018 | 7:59 pm
      Thanks - it's always useful to understand what different people are trying to do.
    • Nov 23 2018 | 1:20 pm
      Hey Together, I have a similar need. I want to make a vst~host as a standalone application and save the settings of a plugin. at the moment the plugin has to be reloaded with the "plug"-message. the bad thing is that in my case the plugin also needs to load an audiofile. this task can´t be adressed from outside.
      when I´m working in the normal max patcher all settings are saved with the whole patch. I assumed that this is also the case with max standalone apps. I also have the feeling that some initialisations with eg. loadbangs are not working the same way. could that be?
      Is it somehow possible to save vst~ settings, which are recalled from the standalone app? how to do that?
      I tried making an snapshot but no success sofar.
      Happy for help!
    • Nov 23 2018 | 4:06 pm
      the generic "workaorund" for that is to load an vst effect preset, au preset, oder plug-in specific format preset file from disc, instead of saving the initial (or selected) preset via your patch.
    • Aug 14 2019 | 9:02 am
      FRiFLo
      Have you found any solution? I am in the same situation. Kontakt (OT) and VEP and max8 .
    • Aug 14 2019 | 9:18 am
      My work around is that I quickly gave up trying to use Max as Plugin host for my purposes. The thing is: for a composing rig you need as much stability as possible and in that sense Max is clearly not the first choice in that matter. This is by no means me complaining! It is the nature of a program that enables you anything that does not fit together with the most stable thing. So, as I need flexibility, but above all reliability, I did not investigate Max as a VST host any further.