kcoul

Having real trouble on Windows 32-bit 7.2.2 with this issue.

I have a custom folder for some VSTs. They are definitely visible to the Max search path via specifying the folder in File Preferences.

The first time the vst~ object is created with the name of the VST as the argument, the VST loads with all of its inlets/outlets intact.

If the patch is saved and then reloaded, however, the VST object will appear with no red highlight and no errors in the Max console, but all the extra inlets/outlets will be gone, as well as (obviously) the patch connections that were connected to them before.

If you take a letter away from the name of the VST and then readd it (in the vst~ object argument), the VST will reload correctly with all the inlets/outlets again, but then you have to redo all the connections.

I had a colleague with the same issue contact me just now about it. Is this a verified bug in Max 7.2.2 Windows 32-bit? Any workaround, like placing the VSTs in a default folder location of some kind? Or is it an issue only happening to us?

vsts-in-search-path-not-loading-with-all-inletsoutlets

did you already try the most obvious, loadbang - "plug filename"? same problem?

Thanks Roman will give that a shot and report.

No dice. Issue persists in 7.2.3 so I've submitted a formal bug report. Hopefully it'll get addressed as it's really a showstopper!

The issue is definitely within Max itself. I'd tried setting registry entries for default search path for VSTs in Windows and placing the plugins there, using every combination of plug and plug messages with loadbangs, but the only way to get the additional inlets and outlets back again is to intentionally misspell the name of the vst as an argument of vst~ object, and then spell it correctly again (i.e. remove the last letter, lose focus, then add the last letter again).

It means that patches using VSTs with additional inlets/outlets would have to be left opened on a computer that is never shutdown in order to retain those connections...

The issue is definitely within Max itself. I'd tried setting registry entries for default search path for VSTs in Windows and placing the plugins there, using every combination of plug and plug  messages with loadbangs, but the only way to get the additional inlets and outlets back again is to intentionally misspell the name of the vst as an argument of vst~ object, and then spell it correctly again (i.e. remove the last letter, lose focus, then add the last letter again).

It means that patches using VSTs with additional inlets/outlets would have to be left opened on a computer that is never shutdown in order to retain those connections...


I am still facing this issue in the version of Max 8 inside Live 10. It's become a real problem as I need a VST to do the final step of ambisonic decoding from the Envelop for Live package for the 5.1/7.1 surround setups I am working with, and the VST~ object cannot remember that it needs to initialize with 16 inputs and 8 or 16 outputs. The VST~ object will always initialize with only 2 inputs and outputs despite the "16 16" or "16 8" arguments, meaning all the additional connections get broken and need to be fixed manually every time the Envelop Master Bus M4L object is loaded.

Is there any chance of a fix for this issue with the VST~ object or something I could try as a workaround to get it to initialize with the right number of inlets and outlets so the patch doesn't break when loaded?

The VST~ object would be put right into this example patch at the following link, which is programmatically loaded into a poly~ object via the Envelop decoder options dropdown menu (not sure if this is related to the issue):

https://github.com/EnvelopSound/EnvelopForLive/wiki/Implementing-a-Custom-Decoder

Edit: If anyone is interested, the VSTs I am trying to autoload as the decoder endpoint are within this suite, which is pretty new (the AllRAD one that lets you design your own decoders is, anyway). 

Somehow I feel that ambisonics is the single best possible use of Live 10 multichannel routing feature, which (if it works in a black box sort of way) opens up ambisonics to people who otherwise would find it way too complicated to get into otherwise. This AllRAD tool is an extremely powerful and flexible endpoint for Envelop so if we could get it working without these VST~ object issues it'd be a great way to get more people into it!

https://plugins.iem.at/docs/allradecoder/

I am still facing this issue in the version of Max 8 inside Live 10. It's become a real problem as I need a VST to do the final step of ambisonic decoding from the Envelop for Live package for the 5.1/7.1 surround setups I am working with, and the VST~ object cannot remember that it needs to initialize with 16 inputs and 8 or 16 outputs. The VST~ object will always initialize with only 2 inputs and outputs despite the "16 16" or "16  8" arguments, meaning all the additional connections get broken and need to be fixed manually every time the Envelop Master Bus M4L object is loaded.

Is there any chance of a fix for this issue with the VST~ object or something I could try as a workaround to get it to initialize with the right number of inlets and outlets so the patch doesn't break when loaded?

The VST~ object would be put right into this example patch at the following link, which is programmatically loaded into a poly~ object via the Envelop decoder options dropdown menu (not sure if this is related to the issue):

https://github.com/EnvelopSound/EnvelopForLive/wiki/Implementing-a-Custom-Decoder

Edit: If anyone is interested, the VSTs I am trying to autoload as the decoder endpoint are within this suite, which is pretty new (the AllRAD one that lets you design your own decoders is, anyway). 

https://plugins.iem.at/ 

Somehow I feel that ambisonics is the single best possible use of Live 10 multichannel routing feature, which (if it works in a black box sort of way) opens up ambisonics to people who otherwise would find it way too complicated to get into otherwise. This AllRAD tool is an extremely powerful and flexible endpoint for Envelop so if we could get it working without these VST~ object issues it'd be a great way to get more people into it!

https://plugins.iem.at/docs/allradecoder/ 

Ok after some more work it seems that this particular issue relates to having the VST folder in the search path for internal Max 8, at least on Windows. There are issues however with Max crashing internally in some situations, I'll try and isolate the reproduction steps.

Also it seems it is not possible to have an "open" message up at the top of the E4L device that would open the VST object inside of the Max patch. I am guessing when the E4L device is not in Edit mode the message doesn't have a valid context to get through to.

Ok after some more work it seems that this particular issue relates to having the VST folder in the search path for internal Max 8, at least on Windows. There are issues however with Max crashing internally in some situations, I'll try and isolate the reproduction steps.

Also it seems it is not possible to have an "open" message up at the top of the E4L device that would open the VST object inside of the Max patch. I am guessing when the E4L device is not in Edit mode the message doesn't have a valid context to get through to.


I can see now that the issue with the vst object not remembering it's inlets/outlets count is occurring only on Mac and not Windows.

It seems also the vst object will respond to an open message if it's also at the topmost level patcher. Perhaps the fact that it was being hosted inside of a poly object in the original way I was trying to use it contributed to that issue. On Windows, the other issue with that was that the vst was not actually initializing correctly at load time, it had to be re-instantiated to load correctly.

I can see now that the issue with the vst object not remembering it's inlets/outlets count is occurring only on Mac and not Windows. 

VSTs in search path not loading with all inlets/outlets