From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #382 Reply-To: sc-users Sender: owner-sc-users-digest@lists.io.com Errors-To: owner-sc-users-digest@lists.io.com Precedence: bulk sc-users-digest Tuesday, November 20 2001 Volume 01 : Number 382 ---------------------------------------------------------------------- Date: Sun, 18 Nov 2001 14:44:57 -0600 From: James McCartney <---@---.---> Subject: Re: OSC limits on 11/13/01 2:56 AM, Garry Kling at kling007@earthlink.net wrote: > Hi James, all, > > Forgive me if this question has been asked/answered before, I can't seem to > find any reference to it. What is the maximum OSC packet size for SC2? 1024 bytes >Is this likely to change in SC server/v3? I suppose this may depend on the OS, currently it is still that size. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Mon, 19 Nov 2001 00:16:32 -0800 From: Garry Kling <---@---.---> Subject: Stochastic tools Hey all. I just uploaded some modest tools for stochastic music to the swiki: http://swiki.hfbk.uni-hamburg.de:8080/MusicTechnology/15 It's a set of methods for SequenceableCollection that fills with various distributions, and a set of pattern classes for the same: Pgauss, Pbeta, Pweibull, Pcauchy, Ppoisson, Pbilex It's based on code from "Computer Music" by Charles Dodge and Thomas Jerse. I'll be adding more as time goes on. Please feel free to email me comments, questions, etc... Best, Garry Kling - -- /* * Garry Kling * MATP UC Santa Barbara * kling007@earthlink.net * */ ------------------------------ Date: Mon, 19 Nov 2001 10:01:47 +0000 From: Jem Finer <---@---.---> Subject: Re: what happens to dead Signals ? > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - --MS_Mac_OE_3089008907_1092276_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ok, thanks . . . I assume this means it disappears completely . . . from RAM. ie doesn't hang around clogging up space. Jem on 18/11/01 19:35, felix at felix@crucial-systems.com wrote: It is 'alive' only while the instrument function is executing. it is alive only within the scope of the {} instrument's function. the instrument itself knows only of the function, not what you did with the function. From: Jem Finer <---@---.---> Reply-To: sc-users@lists.io.com Date: Sun, 18 Nov 2001 10:34:21 +0000 To: scmaillist Subject: what happens to dead Signals ? If one creates a Signal in an instrument, which is called from the lib menu, eg : ( Library.put(['recordAndPlay'], {var a; a = Instrument.new(\recordAndPlay, { var signal; signal = Signal.newClear(Synth.sampleRate * 2.0); RecordBuf.ar(signal, AudioIn.ar(1), 1, MouseY.kr(0.5, 1), 0, 1, 1); PlayBuf.ar(signal, Synth.sampleRate, MouseX.kr(0.5, 2.0,'exponential'), 0, 0, signal.size-2); }); a.play }) ); what happens to the signal when the instrument is deleted from the Mixer window - does it disappear via garbage collection or does it stay somewhere in ram until one hits command - full stop ? Thanks Jem - --MS_Mac_OE_3089008907_1092276_MIME_Part Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: what happens to dead Signals ? ok, thanks . . . I assume this means it disappears completely . . . from RA= M. ie doesn't hang around clogging up space.

Jem


on 18/11/01 19:35, felix at felix@crucial-systems.com wrote:


It is 'alive' only while the instrument function is executing.  it is = alive only within the scope of the {} instrument's function.
the instrument itself knows only of the function, not what you did with the= function.


From: Jem Finer <jemfiner@blueyonder.co.uk><---@---.---> Reply-To: sc-users@lists.io.com
Date: Sun, 18 Nov 2001 10:34:21 +0000
To: scmaillist <sc-users@lists.io.com>
Subject: what happens to dead Signals ?

If one creates a Signal in an instrument, which is called from the lib menu= , eg :

(
Library.put(['recordAndP= lay'],
{var a;
a =3D Instrument.new(\reco= rdAndPlay, {
var signal;
signal =3D Signal.newClear(Synth.sampleRate * 2.0);
RecordBuf.ar(signal, Au= dioIn.ar(1), 1, MouseY.kr(0.5, 1), 0, 1,= 1);
PlayBuf.ar(signal,
        Synt= h.sampleRate,
        Mous= eX.kr(0.5, 2.0,'exponential'), 0, 0, sig= nal.size-2);
});
a.play
})
);

what happens to the signal when the instrument is deleted from the Mixer wi= ndow - does it disappear via garbage collection or does it stay somewhere in= ram until one hits command - full stop ?

Thanks

Jem



- --MS_Mac_OE_3089008907_1092276_MIME_Part-- ------------------------------ Date: Mon, 19 Nov 2001 04:30:08 -0800 From: James Reynolds <---@---.---> Subject: G4/iBook benchmarks (was: ASIO performance) Thanks for the info, Sekhar - the 828 benchmarks seem to confirm that ASIO buffer size has a pretty big effect on SC efficiency. Unfortunately the current Mobile I/O driver doesn't have an option to increase the default buffer size of 128, but they say it's in the works. I'm not sure why the "approx. CPU" figures in your benchmarks are low for smaller buffer sizes. In my tests I just increased "n" until the CPU maxed out (and/or the machine froze ;-) Here are the benchmarks I ran, when I get a chance I'll check out the Swiki and see if I can figure out how to post them there. The high iBook Klang performance is interesting, and confirms what Jeremiah posted earlier. Equipment: Metric Halo Mobile I/O (firewire ASIO), MacOS 9.2.1, sample rate 44.1KHz, blocksize 64, G4 Cube/450/1.5GB, iBook/600/384 benchmark machine driver buffer "n" Osc G4 soundmanager 2048 500 Osc iBook soundmanager 512 470 Osc G4 ASIO 128 410 Osc iBook ASIO 128 340 Klang G4 soundmanager 2048 2500 Klang iBook soundmanager 512 3800 Klang G4 ASIO 128 2500 Klang iBook ASIO 128 3100 > James Reynolds writes: >> Can anyone post benchmarks for other ASIO drivers (especially the MOTU >> 828, also a firewire unit) > > http://swiki.hfbk.uni-hamburg.de:8080/MusicTechnology/214 > > It would be great if you could add benchmarks for your interface > there. > > - sekhar > > -- > C. Ramakrishnan cramakrishnan@acm.org > > ------------------------------ Date: Mon, 19 Nov 2001 11:36:54 -0500 From: felix <---@---.---> Subject: Re: what happens to dead Signals ? > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - --MS_Mac_OE_3089014614_4575987_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit yes, the little dwarf comes out of his hole and drags off the corpse. From: Jem Finer <---@---.---> Reply-To: sc-users@lists.io.com Date: Mon, 19 Nov 2001 10:01:47 +0000 To: Subject: Re: what happens to dead Signals ? ok, thanks . . . I assume this means it disappears completely . . . from RAM. ie doesn't hang around clogging up space. Jem - --MS_Mac_OE_3089014614_4575987_MIME_Part Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: what happens to dead Signals ?
yes, the little dwarf comes out of his hole and drags off the corpse.

From: Jem Finer <jemfiner@blueyonder.co.uk><---@---.---> Reply-To: sc-users@lists.io.com
Date: Mon, 19 Nov 2001 10:01:47 +0000
To: <sc-users@lists.io.com>
Subject: Re: what happens to dead Signals ?

ok, thanks . . . I assume this means it disappears completely . . . from RA= M. ie doesn't hang around clogging up space.

Jem


- --MS_Mac_OE_3089014614_4575987_MIME_Part-- ------------------------------ Date: Mon, 19 Nov 2001 11:32:58 -0800 From: Ioannis Zannos <---@---.---> Subject: Re: Stochastic tools Garry, you forgot to say which one of the libraries it is that is yours. It was the link "Stochastic". I edited the pages slightly to reflect the fact. Iannis - ------------------------- Garry Kling wrote: > > Hey all. I just uploaded some modest tools for stochastic music to the > swiki: > > http://swiki.hfbk.uni-hamburg.de:8080/MusicTechnology/15 > > It's a set of methods for SequenceableCollection that fills with various > distributions, and a set of pattern classes for the same: > > Pgauss, Pbeta, Pweibull, Pcauchy, Ppoisson, Pbilex > > It's based on code from "Computer Music" by Charles Dodge and Thomas Jerse. > > I'll be adding more as time goes on. Please feel free to email me comments, > questions, etc... > > Best, > Garry Kling > > -- > /* > * Garry Kling > * MATP UC Santa Barbara > * kling007@earthlink.net > * > */ ------------------------------ Date: Mon, 19 Nov 2001 13:35:30 -0800 From: James Reynolds <---@---.---> Subject: updated patch for measuring SC latencies I had trouble getting reliable measurements with Julian's patch and the Mobile I/O, but I think I resolved the problem by changing a couple parameters - I lowered the pulse frequency, and shortened the pulse width. If I'm not mistaken, the high pulse frequency resulted in the timer not triggering on the most recently generated pulse, but on the one generated a few cycles earlier (if you put a "measured".post; inside the first Sequencer.ar, you see that the first few cycles don't produce a time measurement). And the wide pulse width resulted in multiple triggers per pulse (which is apparent if you lower the pulse frequency without reducing the pulse width. A 1-second pulse frequency at 0.01 pulse width lets you see 3 or 4 measurements per pulse). By using LFPulse.ar(1, 0.001) I got an input-to-output time of 23 to 24ms with the Mobile I/O, at its default buffer size of 128. This seems a bit longer than it should be, so maybe I need to investigate further. Updated code (SC2 version): Synth.scope({ var in, out, lastTime; out = LFPulse.ar(1, 0.001); in = AudioIn.ar(1); Sequencer.ar({ lastTime = thisSynth.time; "measured ".post; 0.0}, out); Sequencer.ar({ (thisSynth.time - lastTime * 1000).post; " ms".postln; 0.0}, in.abs > 0.1); [out, in] }); ------------------------------ Date: Tue, 20 Nov 2001 22:42:02 +0100 From: "a.c.van.kampen" <---@---.---> Subject: Re: what happens to dead Signals ? > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - --MS_Mac_OE_3089140922_1873104_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit it will find it, smoke it out of it's holes, and bring it to justice. yes, the little dwarf comes out of his hole and drags off the corpse. From: Jem Finer <---@---.---> Reply-To: sc-users@lists.io.com Date: Mon, 19 Nov 2001 10:01:47 +0000 To: Subject: Re: what happens to dead Signals ? ok, thanks . . . I assume this means it disappears completely . . . from RAM. ie doesn't hang around clogging up space. Jem - --MS_Mac_OE_3089140922_1873104_MIME_Part Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: what happens to dead Signals ? it will find it, smoke it out of it's holes, and bring it to justice.

yes, the little dwarf comes out of his hole and drags off the corpse.

From: Jem Finer <jemfiner@blueyonder.co.uk><---@---.---> Reply-To: sc-users@lists.io.com
Date: Mon, 19 Nov 2001 10:01:47 +0000
To: <sc-users@lists.io.com>
Subject: Re: what happens to dead Signals ?

ok, thanks . . . I assume this means it disappears completely . . . from RA= M. ie doesn't hang around clogging up space.

Jem




- --MS_Mac_OE_3089140922_1873104_MIME_Part-- ------------------------------ Date: Tue, 20 Nov 2001 22:56:14 +0100 From: "a.c.van.kampen" <---@---.---> Subject: simple question hi list, i get a uncommon midinote mapping, not equaltempered, which is what i want for now. what did i do wrong? did i put the .midicps in the wrong place? ( SinOsc.ar( Plug.kr( MIDIController.kr(1, 1, 0, 127, 'linear') ).midicps , 0, 0.4 ) }.play ) i also tried converting the midic min and max to cps inside the function, which doesn't work. thanks, jan-kees ------------------------------ Date: Tue, 20 Nov 2001 07:51:08 -0600 From: James McCartney <---@---.---> Subject: Re: simple question on 11/20/01 3:56 PM, a.c.van.kampen at kampen2@chello.nl wrote: > Plug.kr( > MIDIController.kr(1, 1, 0, 127, 'linear') > ).midicps MIDIController.kr IS a Plug already, so there is no need to wrap it in a Plug. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ End of sc-users-digest V1 #382 ******************************