I agree with the point, even if I'm not so convinced by a Render class.
I strongly favor the inclusion of Ctk classes by Josh in the main distro.
They work straightforward, in perfect SC style. They're a sort of equivalent of NRT on the OO side (Have you tried them, Eric?)
Best
-a-
On 3 May 2009, at 08:54, Eric Lyon wrote:
First a big thanks and congratulations to the 3.3 development team. SC is significantly improved, and there seems to be a commitment to increasing both accessibility and functionality. In that spirit, may I suggest that SC could benefit from a better NRT interface, as this would make SC much more enjoyable for audio production work, in addition to SC's obvious strengths as a real-time performance system.
IMO the main problem with the current NRT system is that the NRT specification system is different from the Object format that is customarily used in sclang. So if your synthesis code is written in Object-style SC, then you have to recast it for NRT synthesis, which can be a non-trival task. I'd argue that NRT rendering should be a trivial task for the user. Since at the tail end of its process, sclang is generating OSC messages anyway, it might not be too hard to automate the capture of those OSC messages into a time-stamped score that could then be synthesized glitch-free with sample-accurate timing.
I'd suggest to make the user interface for rendering as simple as possible. For a few models, have a look at NRT synthesis in Csound and Max/MSP. Probably SC could have an even better NRT interface. Below is a sketch of one NRT concept for SC.
This would require designing an class called Render. In order to get NRT synthesis, you'd just add a Render object to your code. The call might look something like this:
Render(outputFile, options, starttime, duration, liveCapture, gate)
Then you'd run your Object-style SC code the same as for live synthesis, but the result would be a sound file with the format you specified in "options".
The first four parameters should be self-explanatory. The reason for the last two is that there are two distinct NRT situtions: first - where all the control and audio information is generated algorithmically, or read from existing files, and no further user input is received once the process starts. For that situation, all you'd need is the logical start time to start writing the sound file, and the duration to write for. In the second, more complicated case, user control input (and possibly audio too) would be coming into SC, so that the Render system would have to both do the audio in real-time as well as it can, and also scarf away time-stamped control input and audio data, for a post-performance rendering. The "liveCapture" boolean would select this mode, and the "gate" trigger would start and stop rendering. Personally, I'd be a happy camper if just the first type of NRT synthesis was implemented; but it would be way cooler to have both.
Thanks for considering it,
Eric
--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--------------------------------------------------
" This is a very complicated case, Maude. You know, a lotta ins, a lotta outs, a lotta what-have-yous."
(Jeffrey 'The Dude' Lebowski)