Yep! I know! Iâve been sick and Iâve had a final project due for school. Iâll get it to you!
Put in an issue!
I was able to recreate it today - sorry for the noisy log, I picked a bad synth to load.
Not sure if this is the right thread, but: I am wondering, if it is somehow possible to generate and send MIDI events to the VSTPlugin Ugen at audio rate (such as mc.midiplayer~ in Max)?
Hi, MIDI events can be sent at any rate if scheduled as OSC bundles (the \vst_midi Event type does this automatically).
2 Likes
mc.midiplayer~ accepts audio signals as input and produces (presumably accurately-timed) MIDI messages for vst~ as output. There is no exact analog to this in SuperCollider.
However, messages to the server are timestamped. I confirmed through testing that the timestamp accuracy for VSTPlugin is accurate within control blocks. (I set control block size to 512 â block duration is 512/48000 = 0.01066667 â then I sequenced notes with a non-multiple 0.065 seconds between notes. Because itâs a non-multiple, if timing were quantized to control blocks, youâd see ~0.06 then ~0.07. Instead, the performance of the MIDI notes was consistent, proving that we get sub-control-block accuracy without doing anything special.)
That is, SCâs timing model is better than Maxâs; we donât need Maxâs âaudio-rate sequencingâ workaround for good timing.
hjh
1 Like
Neither does Pd, BTW! I havenât really checked, but I think Max/MSP cannot do this because the message scheduler runs independently from DSP processing. In Pd, on the other hand, the scheduler runs synchronously to DSP processing, so [vstplugin~] can simply use the logical time to generate the necessary offset.
2 Likes
This came as a surprise to me in Pd â I thought Pdâs control messages were quantized to control blocks, but [delay] and similar objects do schedule according to logical time, with sub-block accuracy.
My SC test goes like this:
s.options.blockSize = 512; // ~= 0.01 or 0.011 sec
s.boot;
(
SynthDef(\vst, { |out = 0|
Out.ar(out, VSTPlugin.ar(numOut: 2));
}).add;
SynthDef(\offsetOut, { |out = 0, freq = 440, amp = 0.1|
var sig = SinOsc.ar(freq) * EnvGen.ar(Env.perc(0.001, 0.08), doneAction: 2);
OffsetOut.ar(out, sig * amp);
}).add;
SynthDef(\normalOut, { |out = 0, freq = 440, amp = 0.1|
var sig = SinOsc.ar(freq) * EnvGen.ar(Env.perc(0.001, 0.08), doneAction: 2);
Out.ar(out, sig * amp);
}).add;
)
// prepare VST: run these one by one
a = Synth(\vst);
c = VSTPluginController(a);
c.open("Vital.vst3");
c.editor;
⌠and set up a synth patch with a very short envelope (like 10 ms decay, 0 sustain).
~normalOutBus = Bus.audio(s, 1);
~offsetOutBus = Bus.audio(s, 1);
~vstBus = Bus.audio(s, 2);
a.set(\out, ~vstBus);
(
p = Ppar([
Pbind(
\instrument, \normalOut,
\freq, 880,
\dur, 0.065, // at 44.1 kHz, maybe 0.064 or 0.063 would be better
\amp, 0.1,
\out, ~normalOutBus
),
Pbind(
\instrument, \offsetOut,
\freq, 440,
\dur, 0.065, // at 44.1 kHz, maybe 0.064 or 0.063 would be better
\amp, 0.1,
\out, ~offsetOutBus
),
Pbind(
\type, \vst_midi, \vst, c,
\freq, 220,
\dur, 0.065, // at 44.1 kHz, maybe 0.064 or 0.063 would be better
\amp, 0.8
)
]).play;
)
// record some of that
b = Buffer.alloc(s, s.sampleRate, 3);
{ RecordBuf.ar(In.ar([~normalOutBus, ~offsetOutBus, ~vstBus], 1), b, loop: 0, doneAction: 2) }.play(s.defaultGroup, 1000, addAction: \addAfter);
// wait 1 sec, then
p.stop;
b.write(thisProcess.nowExecutingPath.dirname +/+ "23-0819-vst-timing.wav", headerFormat: "wav", sampleFormat: "int16");
[b, ~normalOutBus, ~offsetOutBus, ~vstBus, a].do(_.free);
Then in the file, channel 0âs notes are quantized to block boundaries, 1âs notes match the equally-spaced timestamps, and 2âs notes come from VSTPlugin.
⌠and conspicuously, in the first channel, occasionally there is a longer time delta (i.e. poor timing has been reproduced) that is not found in the OffsetOut and VST channels, which are in perfect sync (i.e. VSTPlugin doesnât suffer from that problem).
@pikseliahky Conclusion: Itâs done correctly for you, so, donât worry about it.
hjh
2 Likes
That is great, thank you very much for your explanations!
Hi! First time poster here! 
Iâm trying to run the VSTPlugin extension in SC and running into some issues when I run VSTPlugin.search;. Iâm on an M1 mac.
Taking a step back, here are my steps to have gotten this far.
I first tried to download the mac binary for VSTPlugin-0.54 here.
When I extract that into my Extensions folder, follow the steps to workaround macOS Gatekeeper, and compile my class library, I get this error/warning:
*** ERROR: dlopen '/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx' err 'dlopen(/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx, 0x0002): tried: '/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx' (no such file), '/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin.scx' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))'
*** ERROR: dlopen '/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin_supernova.scx' err 'dlopen(/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin_supernova.scx, 0x0002): tried: '/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin_supernova.scx' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin_supernova.scx' (no such file), '/Users/kevin/Library/Application Support/SuperCollider/Extensions/VSTPlugin/plugins/VSTPlugin_supernova.scx' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))'
So I used sc-plugins-build-scripts from this post to build with arm64. Thank you @madskjeldgaard! I copied the resulting folder into my Extensions folder and that allowed it to compile without errors. However, I noticed that there wasnât a plugins folder in there.
In any case, whether I compiled the Extension extracted from the binary or that I compiled with the script, I get this error when I run VSTPlugin.search::
FAILURE IN SERVER /cmd failed
ERROR: Failed to read tmp file!
It looked like the same issue as this but without the same resolution.
Would anyone be able to offer any guidance as to the next troubleshooting steps? Thanks!
1 Like
Hi, when I released VSTPlugin v0.5.4, our CI system did not have a machine that could produce macOS ARM binaries. Luckily, this has changed, but I forgot to upload new binaries to the release page.
I just added links for universal macOS binaries: v0.5.4 ¡ Pure Data libraries / vstplugin ¡ GitLab
Please try and report back!
3 Likes
Glad to hear it works!
1 Like
I am facing the same issue by installing through the released binaries. VSTPlugin lives at /Users/bubo/Library/Application Support/SuperCollider/Extensions/VSTPlugin on MacOS. I authorized the various binaries through the security panel as is the case for most unsigned binaries:
FAILURE IN SERVER /cmd failed
ERROR: Failed to read tmp file!
FAILURE IN SERVER /cmd failed
ERROR: Failed to read tmp file!
Please post the full console output (since the start of the server). Are sure you installed the right binaries?
I authorized the various binaries through the security panel as is the case for most unsigned binaries:
This shouldnât be necessary with the new binaries.
Sure, here you go:
*** Welcome to SuperCollider 3.13.0. *** For help press Cmd-D.
SCDoc: Indexing help-files...
SCDoc: Indexed 2377 documents in 2.15 seconds
-> localhost
Booting server 'localhost' on address 127.0.0.1:57110.
VSTPlugin 0.5.4
read cache file /Users/bubo/.VSTPlugin/cache.ini
Found 0 LADSPA plugins
Number of Devices: 9
0 : ...
9 : ...
"Micro MacBook Pro" Input Device
Streams: 1
0 channels 1
"Haut-parleurs MacBook Pro" Output Device
Streams: 1
0 channels 2
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 512
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
-> VSTPlugin
searching in '/Users/bubo/Library/Audio/Plug-Ins/VST'...
'/Users/bubo/Library/Audio/Plug-Ins/VST/Rnbo PlateReverb.vst3' is black-listed.
found 0 plugins
searching in '/Library/Audio/Plug-Ins/VST'...
'/Library/Audio/Plug-Ins/VST/ADSR Sample Manager.vst' is black-listed.
**'Long list of over 100 plugins all black-listed'**
found 0 plugins
In doubt, I have re-downloaded the latest version v0.5.4 and the result is similar. I also had to authorize the binaries again through the security panel.
Note: The code I use to generate this output is:
s.boot;
VSTPlugin.search;
My machine is a MacBook Pro Intel 2020 on Ventura 13.6.3.
Ok, now it seems that you have correctly installed the binaries.
In doubt, I have re-downloaded the latest version
v0.5.4and the result is similar.
Which version did you download, i.e. whatâs the name of the .zip file?
I also had to authorize the binaries again through the security panel.
This really shouldnât happen. The SC app contains the necessary attributes to allow loading of unsigned and unnotarized plugins. It would be great if you could open an issue on GitHub: Issues ¡ supercollider/supercollider ¡ GitHub
EDIT: I just reopened Allow to load unsigned/unnotarized plugins on macOS ¡ Issue #6132 ¡ supercollider/supercollider ¡ GitHub and added a link to your post.
Long list of over 100 plugins all black-listedâ
Please try the following instructions in the README: https://git.iem.at/pd/vstplugin#macos-1015
I also had to authorize the binaries again through the security panel.
Which binaries exactly?
The zip file name is VSTPlugin_v0.5.4_macOS_universal.zip.
From what I can remember, .scx files. The popup appears when booting the server. Most likely all files from the VSTPlugin/plugins folder.
I followed your instructions and authorized everything under /Library/Audio/Plug-Ins/VST3. After that, I runned VSTPlugin.clear and VSTPlugin.search. Another security popup appeared: the usual one with unauthorized binaries that could be malware. Meanwhile, the scan was still going on and I authorized it mid-process.
VSTPlugin now finds 98 plugins but some of them are still black-listed for no apparent reason, like Uhe Diva or Artura Matrix-12 (even though I have their whole collection installed and authorized). Itâs already a huge progress 
Cool!
Can you do me a big favor and provide some definite proof that you had to explicitly authorize the .scx file(s), i.e. by posting screenshots of the OS popups and security panel. (You probably need to delete and reinstall VSTPlugin for this purpose.)
EDIT: letâs move this to a private thread. Just send me a PM!
VSTPluginnow finds 98 plugins but some of them are still black-listed for no apparent reasonâ
Please open an issue at Issues ¡ Pure Data libraries / vstplugin ¡ GitLab and list the offending plugins. Start a clean search (VSTPlugin.clear; VSTPlugin.search) and copy the relevant lines of the console output.
I have finally found the reason for these security warnings: Allow to load unsigned/unnotarized plugins on macOS ¡ Issue #6132 ¡ supercollider/supercollider ¡ GitHub. I have added appropriate notes to the release page.
Also, I have uploaded new binaries because the old ones accidentally had no amd64 plugin bridge (which would cause probe errors for Intel plugins on Apple Silicon).
2 Likes