[chuck-dev] Patching core files to provide VST support.

Ge Wang gewang at CS.Princeton.EDU
Wed May 30 21:36:39 EDT 2007

Hi Robin!

First of all, this sounds awesome!  We are game.  Below are the details.

> I don't image that the external Ugens have been fixed yet, have they?

Not yet, but we (in particular Matt Hoffman) have been working on that!

> If not, would you be interested in taking a patch that re-enables  
> them?

We are interested nonetheless - please send if you got it.

> My own personal burning desire: support for VST in chuck. My personal
> feeling about chuck right now: the fixed list of audio-rate ugens is
> constraining, wonderful as STK is. Chuck sequencing and precision in
> conjunction with commercial-grade VSTs would be a killer combination.


> And to that end, I'm willing to contribute some effort to bring up the
> external ugens. For licensing reasons, you wouldn't want VSTs to be
> internally implemented, I think, because you'd pick up the Steinberg
> licensing requirements.

Cool - that makes sense.

> Pieces of work that I'd see as being necessary. (I've reviewed the
> relevant sources in about the timeframe, and I'm guessing that
> the general gist of the sources remains the same).

Your summary is right on, with the addition of needing to manage  
asynchronous I/O devices (MIDI, OSC, HID) on internal buffer boundaries.

> How stable are the core sources right now? If I take a week or two  
> to do
> this what are my chances of facing a merge nightmare once I'm done?

The code is not quite stable at the moment as we (Rebecca Fiebrink  
and I) are adding a whole new section into the language devoted to  
audio analysis (we are pretty deep in the audio processing spine code  
at the moment).  We are totally stoked about the possibilities, but  
the code could use some stablization before starting another system- 
wide change.

> Is now a good time to do this kind of thing? Are you interested?

The bottom line is that we are totally interested, both for the VST  
aspect, and for the block-based chuck which has the potential to be  
REALLY fast without sacrificing the "strongly-timed" precision!  In  
terms of timing, later this summer might be better to undertake this  
project.  We'd love to collaborate on making this happen then.

> Is this more of a help than a hindrance at the present time?

Never a hinderance.  Your energy and contributes are incredible and  
always appreciated here!!  You rock.

Let's meet and dive into this, after the next release, which will  
hopefully have some new crazy things in it!

Thanks again, Robin!


More information about the chuck-dev mailing list