Easy way to create/edit/use VSTs. In return, can you help me reproduce bugs?
Hey guys, I have been working on a redesign of a system I use for live performance. Although my system is at a point where it has been 100% reliable under Max 5.1.9, I have never been able to depend on it in Max 6 due to occasional/intermittent crashes. Max 6.1.7 is the best so far and I'd love to switch to it permanently.
I've extracted a small piece of it, the part that allows you to easily create an arbitrary number of VST~ instances within an arbitrary number of poly~ objects, load VSTs, edit them, and play them from keyboards, all possible with minimum patching. Almost everything is done behind the scenes using wireless objects.
For example, a picture of a single patcher that does this stuff is attached. As described in the tutorial, the goal of these objects is to make it really easy to control an arbitrary collection of VSTs with simple to construct patchers for each song in your playlist.
Background and a tutorial on how this patcher works can be found here.
If anyone is interested in playing with this stuff and game to try and crash it, I would be really interested in your feedback. An archive of the objects is also attached to this post.
Really? Nobody interested in a really easy to use multi-vst hosting environment?
Given all the questions I see about using VSTs and and poly~, I figured this would be useful to others.
Thanks for sharing the patch DHJ, I've not had a chance to look at it yet but will do so soon. :)
Has anyone had a chance to try out this VST environment?
Must admit I'm rather surprised that nobody is interested in this --- given the number of forum postings I"ve seen from people looking to manage VSTs in Max, I would have expected this stuff to be of more interest in the community.
I'm still really stuck as this stuff works perfectly in Max 5 but I am able to produce intermittent crashes with Max 6.1.7 and I'm desperate to find others seeing the same problem so as to try and help the Cycling74 people track it down.
Very frustrating.
Sorry, I don't come here that often... but its definitely of interest, interesting for me also from a 'design perspective'
Ok, Ive run it up, and played with it for 30 minutes(approx), max 6.1.7 (32 & 64 bit), changed vsts etc... and I didn't get any problems.
I only connected up the keyboard...I didn't try the CC routing, as I noticed PB didn't appear to be working, despite being sent from keyboard, and your sendmsg, i didnt seem to get them to FM8... didnt look too hard as to why :)
Is there something specific you do to crash Max?
btw: i do have warnings in the Max log about not finding quebec, or finding PatcherTools etc (perhaps some javascript files not included in archive?)
newobj: quebec: No such object
js: can't find file PatcherUtils
js: can't find file ControlAbstractionBorderColor.js
js: js: no function patcherNameAtLevel [PatcherUtils]
Ooops, I guess the Max option to list externals and all patchers doesn't include javascript files. The quecbec.mxo is from Nicolas Danet. I'm attaching all three files here as the quecbec file is an older one than what he has currently available.
I'm pretty sure that at least some of what's going on is timing/race condition dependent which is why it's a problem to reproduce.
If you have time, try feeding a metro + makenote (see attached) into one of the VSTs and have a rate of 170ms and duration of 150ms then just leave it running for a while. I've seen that break Max over times ranging from a few minutes to an hour (sigh)
cool, its running now.... no issues after 5 mins, but will leave it running for an hour or so :)
Much appreciated --- again, I'm pretty sure it's timing dependent so changing the rate and duration may impact things --- real-time stuff is really hard to reproduce.
Also, it's not clear to me how various audio devices impact the issue --- I've been able to crash this on an iMac with internal audio card, and on a laptop with (last year) MOTU 828 MkIII and (this year) an RME UCX
ok, been running over 100 mins now, no sign of any issue - still pinging away happily at FM8 given the timing you supplied...
( I assume you have had it crash with FM8? so its not plugin specific)
yeah realtime is a pain to debug, different setups also have quite a bearing (# cores, load etc, software loaded, previous versions etc)...
I can try something else if you wish, if you can come up with a test case. (hard for me, as Ive no idea what you think has provoked the issue)
EDIT: ok just over two hours now... I don't think this is going to break it, think we need something a bit more to provoke it.
any suggestions?
Could you try changing the rate of the metro?
actually for the last 30 mins Ive been running both VST instances with a randomly changing metro and note duration, of between 50-300ms. still no issue.
OK --- well, thank you for taking the time to test it.
no problem, btw, for a bit of fun, for last 20 mins I've been sending in 3 different random notes also at different (random) duration/intervals, and still ok.
last test, Im going to run for 30 mins or so, with Aalto and Kaivo which both are pretty heavy cpu users,
so perhaps the stress on CPU will induce an issue... i'll post back if they have an issue.
(otherwise assume not)
are you having problems with vst~ generally, or just within a poly?
anyway, if you have another test to run, just let me know.
Mark
EDIT: ok, another 40 mins of running kaivo/aalto, 3 notes to each, with random note, random interval, random duration.(random duration/intervals 50-300ms) - sorry, doesnt look like its going to crash for me
btw, have discovered a small bug... not sure if its FM8 or Max, or poly related ...
if you minimise a VST UI ( yellow button), and then reshow it with your 'bang' (which i assume sends open), then it will bring up the VST UI, but will be unresponsive to mouse events, window is still updating, and VST is still working.
to 'fix' you have to take the focus to a different window and then back, then the VST UI will 'reappear', but this time will be responsive to mouse events.
(perhaps a known issue?)
One other thing to try is to send several notes at the same time.
The problem does not seem to be poly~ related, just vst~ related. I started having problems with all my patchers as soon as I tried using Max 6 (before I even discovered the poly~) and although the number of times I see crashes has reduced a bit as newer versions of Max have been released, I have not enjoyed the reliability that I get with Max 5 where I'm confident of 100% reliability in a live performance setting, tried and tested.
My sense is that there's both an underlying VST~ issue and a JUCE issue, crashes implicating the latter occur from time to time when I save an abstraction that's deeply nested, based on what I've seen in the stack traces.
I don't know what has changed in Max 6 but I can't go on the road with it.
ok, i changed the test so was sending in 3 sets of trichords, still no issues...
I also tried with the internal soundcard (iMac), as id been using my Focusrite Sapphite Pro 14 (FW) previously, still no issue.
Id really start to wonder if its something about your setup? (odd though that you had issue on multiple computers)
something weird, like you had Max 5 previously installed? (I've only ever used 6)
something else you always have installed? drivers?
The reason I say this, is I'm sure a huge number (majority?) of Max users use vst~, so even with a small % chance of it occurring,
that would lead to a quite a large number of reports... which I don't see here (not that I've looked too hard!).
the issue as you said early on, is theres a enormous number of possibilities that could trigger the issue.
i guess try to get some others to try it, might be I'm just 'lucky'
By the way, pitchbend should work fine --- what are you sending into the pitchbend inlet? It should just be single values between 0 and 127 (low resolution) with 64 being the center.
nah, its ok, I hadn't look at the patch in detail... its simply not hooked up in the 'main tutorial patch'.
anyway, just been through the whole patch this morning, took some time.. as there is a lot of it :)
really nice ideas, and I can see you've put alot of work into getting the poly~ stuff working well with vst~.
I also quite like the way it hangs together using send/receive with the naming used for routing,
makes things a bit difficult to follow when you don't know whats going on, but once you know the flow,
it makes things easier as there aren't that many wires scattered all over the screen.
(I assume send/receive doesn't have any performance penalty, as wires are just a UI element?)
certainly got me thinking about how I can going to do something similar...
Actually what I posted is only a tiny piece of my environment. I was trying to keep it as basic as possible to make it easier to figure out what might be causing crashes.
There's a deeper reason for that naming convention --- there is a complete persistence overlay that uses a Javascript dictionary (i.e. basic map) to store names and values and the same naming system so that sliders, dials and other adjustable parameters get saved automatically with nothing needed other than to specify a parent name in a bpatcher argument. I found this much more convenient than the pattr stuff which I never really understood anyway.
Glad you like the design, the innards are certainly complicated but the goal was to make it easy to USE and modify at the front end and I think I've accomplished that quite well.
You have me wondering whether I should blow away the OS from my hard drive and install a complete fresh system from scratch and only install Max and the VSTs and audio drivers on it to see if that addresses the issue.
haha, he does not manage to chrash it. noob. :D
Ive no problem being noob :)
anyway, good news that you can (obviously) crash it using @DHJDHJDHJ stuff... going to save him rebuilding stuff to test out his setup,
and your patch that reproduces it (and stack trace) will be very valuable to @DHJDHJDHJ and Cycling74.
looking forward to seeing your patch, and seeing how it crashes my Max :)
@Roman --- are you saying that YOU managed to crash it? If so, could you please send me or post the stack trace (just the thread that crashed) so I can see if it's the same thing I've seen? What I really need is a way for Cycling74 to be able to see these crashes occurring.