mc.vst~ bug
Hi,
There seems to be a bug in the vst~ (and mc.vst~) object. Inputs 5 and 6 do not work, and the output patch does not look correct.
The plugin used in the screenshot (spatial mic converter) works perfectly in Nuendo.
THANKS
Inputs 5 and 6? But [vst~] only has outlets?
Can you be a bit more specific here, because I've been using [vst~] quite extensively myself, especially with RNBO debugging and also using Max in combination with Reaktor, and I've never experienced outlets not working.
Now, I know you're talking about "inputs" but that doesn't tell me anything either. What inputs?
See, the screenshot you're sharing only seems to indicate that you're not using the node correctly. If you check its reference page you'll see that you can't just use an endless amount of arguments as you've done ("1 2 3 4 5"?). The first argument is to determine the number of out- and in-lets, the second is the VST itself. Like I said, check the reference page.
By default [vst~] has 2 audio signal inlets, and I can rest assure you that those work. Now, you can expand on the number of out- and in-lets by using an argument, but then it'll depend on the VST you're using if this is going to be supported. Also: this mostly affects the outlets, not inlets.
So could you elaborate a little bit?
(edit: note to self: don't use (enter) to add new links, sorry about a hasted post).
Sorry for a double post, but this seemed like a better idea than to just edit my previous one.
Definition of a bug is that it needs to be reproducable, and since it's been a while since I last messed with [vst~] I figured that I might as well check this out too. Also because I suddenly realized that I have an awesome new way to look into all this... See, I'm a vivid user of both Ableton Live and FL Studio; I'm a Live user first and foremost and use 'FLS' to expand on it, it provides a VSTi which allows me to use it directly from Live.
Which means it should also give me one heck of a testing environment.
So I "did" something ;)
And well, I don't notice anything wrong with the way [vst~] behaves. First I figured I'd use [kslider] to provide MIDI input, and check how the VST's outputs behaves. Then I realized that you were talking about inputs, so I added Reaktor as a multi channel effect to check that out too.
Just to clarify a bit... I used kslider to provide some MIDI input, and fabricated a quick means to add the note off as well. In 'FLS' I set up the Layer device which can play multiple channels at once; so both Flex and MiniSynth. I then copied the Flex signal onto mixer channel 5 and sent that right back into Max (vs. using the master channel). So 2 audio outputs, where the second goes out #5.
This is all ad-hoc, here I suddenly recalled that you were talking about "inputs". So I added Reaktor's surround FX, made sure to use 6 inlets and 5 outlets (like with FLS) and well, I then set up some signal checks in Reaktor as well. I visualized the first 2 audio input signals as reference, then did the same for the 5th inlet. Because it wouldn't be conclusive if I added both signals to one spectrum I decided to re-route the 6th inlet back out #3 and use the Max [levelmeter] to show what's happening there.
I think my screenshot says it all: no bugs.
on Mac max 8.6.2 there are no problems to route 8 channel input through
plugin.
could problem be only on windows or that plug related ?
Definitely no bugs here, but more important for now: I think I know what might be causing OP so much trouble... totally glossed over this myself at first: mcs.vst~
When using mc / mcs nodes then the audio channels get jammed into one single connection: mc stands for multi channel afterall. [mcs.vst~] for example has 1 "mc channel", meaning that you don't get to pick your inlets, but they expand automatically.
And if you don't use mc nodes as intended then "bad things" can happen.
Seriously: I wasn't paying attention and tried to hook up an [mc.vst~] outlet to my trusty [live.gain~] node (vivid M4l user here) and wham... Max crashed. Seems a bit excessive, but I can easily understand if OP experienced something similar and thus concluded that something was wrong.
@source audio
doesn´t your screenshot show very well that it does not work for mcs? ;)
vst~ 8 8 should show 8 intel... infidel... inlets and 8 outlets.
Hi,
This plugin (screen shot) is a 2nd order ambisonic A to B converter. it therefore has 8 inputs and 9 outputs. I use it regularly with Nuendo.
With the mcs.vst~ object, viewing the input meter of this plugin indicates that there is nothing on inputs 5 and 6.
The outputs are not consistent.
I also tested the compass plugin (sparta) which also does not work with the vst~ object.
Thanks,
François
With all due respect.. still seems like a local issue to me.
(edit)
Let's try to tuen this around: what is it you're trying to achieve here? You're trying to do something which doesn't work. Let's forget about [vst~] and focus on that: what doesn't work?
Shelluser,
OK, it's the vst~ object that doesn't work as it should!
I just want to point it out here.
Hi, here mcs.vst~ is running with 32 in to 16 out channels
Max 8.6.2
Macbook pro M1
@Roman: I guess that the screenshot shows that is working. The meters are horizontal, like mine;-)
@Francois
OK, it's the vst~ object that doesn't work as it should!
I just want to point it out here.
Well, I guess we'll have to disagree on that. Some of the others did tests on Mac, I myself checked Windows. The node works as expected, all according to the documentation.
Can't really help you without knowing any more details.
The meters are horizontal, like mine;-)
not that i had any experience with mcs.* stuff, but (mc) polyphony and having multiple channels are two different kind of things, and in mc.vst~ object you would want to have e.g. 8x(8 channels) of such an encoder.
more than 2 IOs always were a bit problematic, and there were all kind of issues in various host programs on mac & win with this damn reaktor for 25 years.
but i am a bit irritated that the sparta plug-ins also do not work in vst~ in max 8?
Regarding SPARTA, and please correct me if I'm wrong, but here is my understanding of things:
If you use SPARTA v1.6.2 (or earlier), which support up to 64 channels, then the plugins should work fine in Max. If you use SPARTA v1.7.0 (or later), which now support up to 128 channels, then the plugins will crash in Max.
The crash is not related to any of the actual SPARTA signal processing. The crash occurs due to JUCE's "VST<->Host interfacing". Essentially, the following is being played out:
SPARTA: "Hey Max, these plugins support up to 128 discrete channels :) "
Max: "Hey SPARTA, that's great! I can do that no problem!"
SPARTA: "Awesome! Remember though, the plugins will need to be provided with 128 buffers"
Max: "They will have them! : )"
Then at run-time: [Max instead provides only 64 buffers, so inside of JuceVSTWrapper::internalProcessReplacing(), the following line leads to memory reading/writing out-of-bounds when i>63: memcpy (chan, inputs[i], (size_t) numSamples * sizeof (FloatType)); , which leads to the crash...]
Only Max seems to have this issue:
- Rolling back to older REAPER versions (before it supported up to 128 channels) - No problem with latest 128ch supporting SPARTA plugins. They are simply capped at 64 channels.
- Using Plogue Bidule - No problem
- Nuendo - No problem (but capped at stereo in/out... Just used it for testing)
So I'm fairly confident that Max has an issue here, and that it can be resolved by Max providing such plugins with 128 buffers (even if it then ignores those extra 64 channels).