[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Request for SC 3.4 - a better NRT interface
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/