[chuck-users] OT: Reader Internals, PD and Super Collider for Accessible, Conventional Modular Environment

[altern]

> A: first you nee to create in supercollider  language a synthdef, just a
> compiled crossplatform  description of connections of UGens in the 
> supercollider scsynth. Once this is compiled you can forget about 
> supercollider and the scsynth can load and control that synthdef.
> V: Thanks for the summary, this looks like a good environment to build
> on. However, it would still probably take a great deal of work, so if
> there's an easier route, in terms of bad lazyness, I'd rather take that.
> This talk abou the various synth environments let me reading up on Pure
> Data PD, however. I seem to enjoy the philosophy and real time nature of
> it, it is well documented and there's experimental VST support, too. And
> I know C for the low level stuf.
> 
> The only major gripe I have is the graphical environment. The good
> things are that it is easy to get started in, it uses standard menus,
> and I can set up MIDi and audio graphically OK. However, most of the
> panel widgets it uses and the graphical signal path aren't really
> keyboard and programmatically screen reader accessible.
> 
> Given that PD is described as a data flow language is there a textual,
> human readable and writable format, in which I could do PD patches
> without the graphics? Put another way, what did the author use for
> debugging before the GUI? At least there's some kind of exchange format
> for Max. So I could probably write perl scripts around that, as a
> desperate measure. Can I run PD on the command line as well?

I dont really know answer to this questions. I just use PD so I am not 
sure how it works behind. I know it is possible to code extensions in C 
but thats all.