dhjdhjdhj

If I create two [vst~] objects, each of which uses the same VST, and I send a message to one of them to 'open' the VST for editing, the VST opens twice and in fact they seem to be sharing the same instance because saving a patch to one of them seems to save to both.

Any idea how to fix this? This is happening with Max 5 (I haven't tried it in Max 6 as Max 6 hung when I was trying to open a VST a second time and so I had to revert back to Max 5 for my project)

Any idea how to fix this? This is happening with Max 5  (I haven't tried it in Max 6 as Max 6 hung when I was trying to open a VST a second time and so I had to revert back to Max 5 for my project)


vst-open-bug

Has anyone else seen this behavior? I'm happy to investigate further if it is unknown but I don't really want to spend time investigating a problem that is already known about.

I can't repro with Max 6. OS, computer model, version of Max, plug-in used?

I can't repro with Max 6.  OS, computer model, version of Max, plug-in used?


Sorry --- I was using Kontakt 5 with Max 6 (release version)

Kontakt 5 has some known issue. I'm not sure this is one of them, but its something that we can look into.

Kontakt 5 has some known issue.  I'm not sure this is one of them, but its something that we can look into.

Will experiment some more then and let you know --- this was the first time I actually tried to use the same VST multiple times in a single patcher.

OK --- this is not limited to Kontakt (nor even NI plugins). It happens with any plugin if I create two [vst~] objects that use the same named VST file.

However, if I make a copy of the underlying VST in the same folder with a different name, so that my second [vst~] uses the copied version, then they are completely independent with no problems.

Sounds like a singleton problem to me, a global list of VST names used as indexes into loaded libraries, perhaps.

(I never liked the singleton pattern, I always got bitten eventually if I used it in my code)

I can't reproduce in Max 6, so if it is Max5-specific, it is highly unlikely that this will be fixed.

Please give it a go with Max 6 and let us know if you are still having problems in this department.

I can't reproduce in Max 6, so if it is Max5-specific, it is highly unlikely that this will be fixed.  

Please give it a go with Max 6 and let us know if you are still having problems in this department.


Can you please post which plug-ins you are seeing this with? We are unable to reproduce here with a handful.

Can you please post which plug-ins you are seeing this with?  We are unable to reproduce here with a handful.  

Hmmm, based on your inability to reproduce, along with the experiments I did subsequently, I'm wondering if this is a problem with abstractions and has nothing to do with the actual plugin used (unless you use the same one multiple times). Attached is my GenericVST abstraction and a separate patcher containing two of them. This is part of a larger project I've been working on to manage a live rig with many external MIDI devices and the idea is to be able to treat VSTs as similarly as possible to external devices in terms of control. For example, you can just feed the standard output of [MIDIParse] into this thing.

The GenericVST patcher takes a single argument, the name of the actual VST to be used.

Here's a trivial patcher that instantiates two GenericVST patchers. If you double-click on one of them, it opens a new patcher which has (among other things) a button to open the VST GUI. You should discover that if you do this and the GUI opens, moving the GUI window exposes another one underneath.

By the way, going on the possibility that invoking the same abstraction with the same arguments was just causing two references to a single instance, I tried adding another parameter (different in each abstraction) but that didn't help.

Take a look at your sends and receives. There is no distinction between abstractions, so all messages get sent to both. send/receive namespaces are global.

Take a look at your sends and receives.  There is no distinction between abstractions, so all messages get sent to both.  send/receive namespaces are global.


But thank you so much --- I should have seen that myself.

I just took another look my patch as I realized that if in fact the send/receives were completely global, then multiple VSTs, even with different names, should have all opened at the same time.

Turns out I did use the VST name as part of the symbol for send/receives which explains completely why only GenericVSTs containing exactly the same name got opened at the same time.

Can you recommend a better naming convention to use for the Send/Receives so that even if the parameter name (the actual VST) is the same in multiple abstractions, only the specific abstraction will be opened. In other words, is there some best practice that can be used to create names that will only be visible in a specific abstraction?

The irony is that when I first built this abstraction, I didn't use send/receive and only put them in later to "clean up" the wires.

i like your whole project. nice patches. i took a quick look at the abstraction for unique identifiers etc:

Wow -- thank you so much --- I took a quick look and appreciate all the comments you put in there. I will have to study it much closer to make sure I understand the changes you made.

I'd like to include your changes in the zip file that I've recently made available on my own site for the larger project (see 

http://deskew.com/component/content/article/19/76.html)

 and would be delighted to credit you if that's ok.

I'd like to include your changes in the zip file that I've recently made available on my own site for the larger project (see http://deskew.com/component/content/article/19/76.html) and would be delighted to credit you if that's ok.


@pid I have been trying to understand your changes and wondering why you are recommending [v] rather than [pv]

The reason I got into trouble with the original patch was of course because I forgot that send/receive names are global.

But I knew that [v] was global and [pv] was 'more' local which is why I used the latter. What's the disadvantage of that decision?

@pid  I have been trying to understand your changes and wondering why you are recommending [v] rather than [pv]

But I knew that [v] was global and [pv] was 'more' local which is why I used the latter. What's the disadvantage of that decision?


hey, sorry i missed this. been busy. glad to have been of help.

the v / pv things were merely that i had rushed the whole thing and was confusing myself, if i remember correctly. so do not take concrete practices from it!

however, the two objects work very differently of course. if all you have to do is 'declare' a variable to be accessed later at any other point in the abstraction, presumably [v] is a little faster and less overhead. but if you need to take advantage of all the [pv] features, use that and can still be used with #0.

The use of [v] rather than [pv] would have screwed me up with multiple patchers just as my not using #0 was screwing me up.

At this point though, I have it working beautifully, thanks to your comments. In fact, I've actually improved it a little to eliminate the need to send the patch name in separately. So now I can just write

to give me an immediately useful VST with a strings patch in Kontakt5. I would save this in a folder called "Synths"

Typically however, I would create a patcher, add that object and some controls to expose relevant parameters for that particular patch (e.g. string legato mode, vibrato rate) and then THAT patcher would become a new abstraction simply called [Strings] in a diferent folder called "Instruments"

That's why I want the feature I mentioned in another thread where Inlets and Outlets could be added automatically. The ability to create a large collection of instruments becomes very efficient and one can then just browse the "Instruments" folder to instantiate whatever is needed.

VST open bug ---