[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] VstPlugin.sc - a class to load VST plugins in SC



I’ve been here for 17 years!!!

Sam

On Jan 14, 2019, at 9:49 AM, christof.ressi@xxxxxx wrote:

Hi Sam, glad to see you here :-) Christof
 
Gesendet: Montag, 14. Januar 2019 um 15:11 Uhr
Von: spluta@xxxxxxxxx
An: sc-users@xxxxxxxxxxxxxxxx
Betreff: Re: [sc-users] VstPlugin.sc - a class to load VST plugins in SC
Christof,
 
This looks incredible! I am going to try it out today.
 
Was is inspired by the piece of mine you played where you had plug the outs of your interface to the ins to plug sc into reaper to get vst plugins? Haha. Either way, this is a amazing, and we have needed this for years.
 
Sam
 
On Jan 14, 2019, at 4:45 AM, christof.ressi@xxxxxx wrote:
 
Hi, try the .git-ci/get_vst.sh shell script! It downloads the sdk from an older snapshot of the juce github repo. :-)
 
Gesendet: Montag, 14. Januar 2019 um 11:03 Uhr
Von: mail@xxxxxxxxxxxxxxxxx
An: sc-users@xxxxxxxxxxxxxxxx
Betreff: Re: Aw: [sc-users] VstPlugin.sc - a class to load VST plugins in SC

This is a very cool project.

I'm struggling to find the vst-sdk anywhere. Does anyone have the link?

Cheers

On 14/01/2019 02.18, christof.ressi@xxxxxx wrote:
OK, I've finished implementing the alternative version where the VstPluginUGen directly reads and writes from/to audio busses. Personally, I think it's more flexible and easier to use. What do you think?

Here's the repo:

https://git.iem.at/pd/vstplugin/tree/supercollider2

Here are the test binaries:

Windows (64 bit): https://drive.google.com/open?id=1altTlQG-d6Owv2Q_m0WqsU6oK8iNX_bD
macOS: https://drive.google.com/open?id=1RuH8l-jWPpnrs79L0cmsR5F0Xbwd2O-A

Christof
 
Gesendet: Sonntag, 13. Januar 2019 um 17:47 Uhr
Von: christof.ressi@xxxxxx
An: sc-users@xxxxxxxxxxxxxxxx
Betreff: [sc-users] VstPlugin.sc - a class to load VST plugins in SC

hi, I've been developing a Pure Data external for loading VST plugins (https://git.iem.at/pd/vstplugin) and it has been working quite well so far. Now here's my first attempt at porting it to SuperCollider:

https://git.iem.at/pd/vstplugin/tree/supercollider

see the README for a quick overview and how to build the project.

Here are binaries you can test in case you don't want to build from source:

Windows (64 bit): https://drive.google.com/open?id=1nIFdK0oArsCUBoXfH6mP548ZCagsDmsD
macOS: https://drive.google.com/open?id=1KZJHwWd-sLpA1JG7TieHX488as2yqHuU

for more detailed information and examples checkout the VstPlugin class help file.

---

Here's a short explanation of the current implementation:

The VstPluginUGen class is responsible for loading VST plugins on the server but it's only used internally. The VstPlugin class provides the actual high level interface by wrapping a VstPluginUGen in a synth, hiding all the necessary messaging between server and client behind instance methods.

Right now, the class method 'makeSynthDef' is responsible for creating the necessary SynthDef for all VstPlugin instances which share a certain number of inputs and outputs (+ whether output is replacing or accumulating). In the SynthDef's UGen graph function, an instance of VstPluginUGen.ar takes its input from In.ar and outputs to either Out.ar or ReplaceOut.ar, depending on the 'replace' argument. Using a single Node for each plugin helps tremendously with the OSC messaging (because I need to know the SynthIndex of VstPluginUGen within the UGen graph function), also you can freely move individual plugins within the graph, changing your FX chains after the plugins have been loaded.

I *could* get rid of 'makeSynthDef' if VstPluginUGen would directly read and write to audio busses (without the help of UGens like In and Out). In this case we'd only need a single SynthDef for all VstPlugin instances regardless of number of input and output channels and it could be created internally. If you think the current 'makeSynthDef' solution is too messy/confusing, I could totally do that!

---

I have to say that my expertise is really Pd and I'm only a casual SuperCollider user, so I'm open for any kind of suggestions!

Best, Christof



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/
 
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/
-- 

Best Regards,
Mads Kjeldgaard <http://madskjeldgaard.dk>

 

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/
_______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: https://listarc.bham.ac.uk/marchives/sc-users/ search: https://listarc.bham.ac.uk/lists/sc-users/search/