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)
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/