Hi Sciss,
The default NRT performance of Max's control-based clock is even
worse than I expected, and those clocks are notoriously bad.
However, when the NRT driver is set with Scheduler in Overdrive and
in Audio Interrupt, the Max NRT control clock seems to perform
about as well as signal-based clocks, which is to say, just fine.
Cheers,
Eric
----------begin_max5_patcher----------
975.3ocyXkzaqaCD9r8uBBcpsH0PjhZ6cKn8ROzVf1d6gfGnkns4CRjFTTYo
AI+1KWj7RrcrjrfPuHFNRY327Mab7qym4sT7LsxC7EvWAyl857YyrhLBl0re
lWI44rBRk8y7xDkkTtx6N26TzmUV4AKTxW.j0DFG7DSsA72Yan40ETIPK4Oe
jJykrGo2Q34.ij6qyYBvuwUTordqZA32qy1.VRUZAKZ0dAiSyD0b6QDzHbkf
qpX+K0HChV32HdqjVoAFQwD7uIoYJmUgwg5OADAMO8ad.dn4ehWWx3ETk01f
sZhnx1v3qORKA60BL1bp.bxwJRTqZ0TKlX4VtQr76+b.x6.7yIkV76cujQJ7
Lu3s4yMOt6F8CnE.iinjpjBCOmSWQpKTfRQNE7CEh5pW.aoxUBYIgmQ+wyR0
nAR0VRBNJTsSKvPrYI.2GpFkLMTMbAHWqRP8Vve7W+CvFeKAl.bUsjCDbvud
+uTMDBtqbUPXhkkvtET3.HqvwkrJoUUj0zSHqrBJQ50CyFcYyNwFbASsgHAw
1MWNYDdpQCS+Dit4MNMndYK0cnddfGF.e7D4QpIY68V8trd0Jpb2YlYLOc3y
gDVlnPHcm54SeB+jzmTCcfRirKg1knKGQDcFxI9hTvpBAQmG7o+QAqxtNL5R
IVutXWzSmqYzTsvV4.429rGADQWzlYlL1gXJb5SZUeRhfoNv6iTh.JJzUqzk
IDcECGcFCGOfLgJ1Zt40.ukD95I0QGm55.6OXOcvj4oyIYikiNz25gQP+8k7
9D69L04gvooNOT20WCW+QxvCf1Hbma2cYfdVp2exJ0egv.2Uwf9iMmfsrQLr
+4.ICfRFdl9EnkeZrxMftdcPrcI.sHru7Q7vqANlLBWvp5WqA3UYkD2nJQ8O
HIZpIk5xkT40LeyXLGFOz4bFrqxoUUfvAzoL7lZT5tdztSS+Bac5E9SVqyFF
.lFNzVm3IqyoF0BY96fOd43tjSDbUJ.0L0jeR+4.z+OJU3FhXOAoMld1yEds
wqPQt3ELZ.2pb.rztAHNsSi8fsWb9C+TUVvajeLCVIpkYs5scdOvd7mSqTLt
8mu3vO5nuYCKOmxO7xTkr7sBcjdU6jYm0c1UHE2ADg5GhP9g1deAXyRfdRv1
c2HVMCIbUvZLHXO.arEklvKCJgosAa2LXi5.Xw8iYw5veCX0CXtmYs6lBvlL
HvFj3tNDtcysBU+tjC0ShsAdoI1ff3catUrFzEr1yDdbhEkvTq2OD5ua2Mh1
jt.V+Is5TTGS3mNDg5.hBmTDgG+J3enq272l+ePkpEux
-----------end_max5_patcher-----------
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)
_______________________________________________
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/