On Sun, May 3, 2009 at 6:16 PM, Sciss
<contact@xxxxxxxx> wrote:
to solve the problem of RT versus NRT being treated practically equal boils down (IMO) to
- a new NRT mode for scsynth
- a new Clock class for sclang
the problem is all the posted examples work because they don't expect replies back from the server. but to think of scsynth as a one way communication is of course wrong. currently, scsynth takes a binary OSC files and processes it. what is needed is a new NRT mode that
- sets up a normal OSC socket for scsynth
- so awaits OSC messages and replies with OSC messages (/n_go, /n_end, /done...., /synced, /tr, .... )
- but advances in time as fast as possible but with input from sclang
so sclang runs a special Clock where logical time is not correlated with CPU time.
the whole scenario is quite complex and in this moment i don't have to patience to develop the implications fully. i just imagine that a .wait statement in a routine running on the NRTClock will tell scsynth (via a special OSC message) to _keep on calculating_ audio until _any new OSC reply is generated_, because that new OSC reply could trigger new reactions from sclang.
take a simple example:
SynthDef( \myDiskInPlayer { arg bufNum;
var input;
input = DiskIn.ar( 1, bufNum );
Out.ar( 0, input );
DetectSilence.kr( input, doneAction: 2 );
}).send( s );
r = Routine({
20.do({ arg i; var buf, synth;
buf = Buffer( s, 32768 );
synth = Synth.basicNew( \myDiskInPlayer, s ).register;
s.sendBundle( s.latency, buf.allocMsg( buf.cueSoundFileMsg( myPath[ i ], 0, synth.newMsg( s, [ \bufNum, buf.bufnum ])));
UpdateListener.newFor( synth, { arg upd, node;
upd.remove;
buf.close; buf.free;
}, \n_end );
1.0.wait;
});
}).play( SystemClock )
if you want to allow that example to run seamlessly in NRT, except for changing SystemClock and NRTClock, the following will be required:
the 1.0.wait will send an /nrt_advance message to scsynth with the duration of 1.0 seconds. scsynth continues to calculate audio output for _at max_ 1.0 second. two things could happen:
- all playing synths are still busy streaming diskin audio
-> in this case, the Routine will continue with the next iteration
- any of the playing synths is freed from its DetectSilence UGen
-> scsynth sends the corresponding /n_end message to sclang (along with the correct logical time stamp).
the NodeWatcher will trigger the UpdateListener, this results in the buffer's close and free messages being
sent to the server (and of course, freeing the bufNum in the buffer allocator).
while in this example the reply is not so crucial, imagine that the /n_end triggers the creation of new synths or forking of new routines. another very common case would be SendTrig appearances. the interleaving of the server and client clocks of course is the most challenging task. by the way, this problem has also not been addressed in Max, which in fact is a real disaster when you want to do NRT:
max v2;
#N vpatcher 477 191 1077 591;
#P toggle 369 109 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 370 140 31 196617 dac~;
#P user meter~ 229 175 309 188 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P newex 232 132 65 196617 train~ 1000;
#P button 116 182 15 0;
#P toggle 111 79 15 0;
#P newex 132 136 64 196617 metro 1000;
#P connect 0 0 2 0;
#P connect 1 0 0 0;
#P connect 3 0 4 0;
#P connect 6 0 5 0;
#P pop;
so taking Max/MSP as a role model for a successful NRT solution appears at best as a very adventurous prompt. CSound has an easier stand (and probably is the only convincing NRT solution) because you don't have the server/client problem.
i believe a satisfying NRT solution involves running scsynth with a real OSC socket and full duplex communication, instead of the OSC binary file.
ciao, -sciss-
Am 03.05.2009 um 14:23 schrieb Andrea Valle:
I guess my acid test for good NRT functionality is that you only need a single additional line of code to get an NRT rendering from any audio-generating SC code.
Yes, interesting. Substantially, It's like having a NRT button on the Server GUI (near Record you would have NRTRec)
-a-
Cheers,
Eric
On Sun, May 3, 2009 at 9:30 AM, Scott Wilson <s.d.wilson.1@xxxxxxxxxx> wrote:
There was also a RecordAddr some time ago which did what you said more or less (capture OSC to a score). That was on the swiki I think. I don't know if it works with 3.3, but it would be easy to do I suppose.
I agree about NRT, btw.
S.
On 3 May 2009, at 09:27, Andrea Valle wrote:
Hi Eric, all,
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
--> http://www.cirma.unito.it/andrea/
--> http://www.myspace.com/andreavalle
--> http://www.flickr.com/photos/vanderaalle/
--> http://www.youtube.com/user/vanderaalle
--> andrea.valle@xxxxxxxx
--------------------------------------------------
" This is a very complicated case, Maude. You know, a lotta ins, a lotta outs, a lotta what-have-yous."
(Jeffrey 'The Dude' Lebowski)
--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--> http://www.cirma.unito.it/andrea/
--> http://www.myspace.com/andreavalle
--> http://www.flickr.com/photos/vanderaalle/
--> http://www.youtube.com/user/vanderaalle
--> andrea.valle@xxxxxxxx
--------------------------------------------------
" This is a very complicated case, Maude. You know, a lotta ins, a lotta outs, a lotta what-have-yous."
(Jeffrey 'The Dude' Lebowski)