From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #59 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 Monday, September 6 1999 Volume 01 : Number 059 ---------------------------------------------------------------------- Date: Sat, 4 Sep 1999 09:33:32 -0700 (PDT) From: Richard Karpen <---@---.---> Subject: Re: Authorization fails I'm interested in the site license idea? What is the cost for that? Richard Karpen =============================================================== Richard Karpen Professor, Music Composition and Computer Music Director, Center for Advanced Research Technology in the Arts and Humanities (CARTAH) Box 353680 University of Washington Seattle, WA 98195 Phone: (206) 543-7130 FAX: (206) 685-9499 email: karpen@u.washington.edu www: http://faculty.washington.edu/karpen =============================================================== On Sat, 4 Sep 1999, Ronald J. Kuivila wrote: > Hi all, > > In the academic context, the current copy protection scheme is > fantastic. We have a site license, so SC can be put on any machine. > Inevitably, problems arise and the key code gets passed around. The six > month expiration makes this reasonable. The goal here is to make more SC > users who then buy copies of SC (kind of a pyramid scheme, I suppose...). > > > RJK > > > ------------------------------ Date: Sat, 4 Sep 1999 11:38:52 -0600 From: James McCartney <---@---.---> Subject: Re: Authorization fails At 10:33 AM -0600 9/4/99, Richard Karpen wrote: >I'm interested in the site license idea? What is the cost for that? > >Richard Karpen $900 --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Sat, 4 Sep 1999 13:54:12 -0400 (EDT) From: David Crandall <---@---.---> Subject: Re: Authorization fails Darn, and here I was thinking this is working pretty good... Please don't let em turn you into Opcode... A one man band like this is pretty revolutionary, I think, and the world needs more of them. dc ------------------------------ Date: Sat, 04 Sep 1999 14:59:23 -0400 From: Mic Berends <---@---.---> Subject: Re: Authorization fails supercollider is far beyond shareware, and way far much lots better than you would get from a larger team-oriented development house - we love our one-man band! what are you comparing to? it's 10x more polished than anything that exits ircam et al. the only thing is that james never has an official release, and we're constantly in a beta cycle. it would be nice to have an "official" release, in which the feature set is locked down and the bugs have be extinguished to the fullest extent of the law. and then produced of course the beta or development release which pushes the envelope and we all talk about here and crashes your computer all over the place. my preference would be to set up a mail bot; fear of bouncing mail is a lame excuse. if you want to retain control like expiry gives you just say so and bugger the lot of ya! next best thing is dongle, which i like very much. secure, you can move from computer to computer, you don't have to write the reg code on your hand in ink and run from room to room, etc. i never understood why people complained so much; also they can't be more than $20 each, eh? the inventor of PACE slash InterLok will surely burn in hell. Cheers, Mic. supercollider for audio mel for graphics perl + miva for web tcl for interfaces really, i wanted to stop coding ages ago. perhaps i should unify my api and go back to c. - -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v ^ Mic Berends : in the end, : Tomorrow Maximum v ^ MINDESIGN limited : there can be : Heaven Kissing EP v ^ http://www.mindesign.com/ : only one. : available now. v ^<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------------------------------ Date: Sat, 4 Sep 1999 15:11:14 -0600 From: James McCartney <---@---.---> Subject: Re: Authorization fails At 12:59 PM -0600 9/4/99, Mic Berends wrote: the only thing is that james >never has an official release, and we're constantly in a beta cycle. it >would be nice to have an "official" release, in which the feature set is >locked down and the bugs have be extinguished to the fullest extent of >the law. I hope it is a long time before the feature set is locked down. I have a to-do list that probably extends for a few years. > my preference would be to set up a mail >bot; fear of bouncing mail is a lame excuse. I'm not in fear of bouncing mail, it is just that it does no good to send to a bad address. > next best thing is dongle, which i like very much. secure, >you can move from computer to computer, you don't have to write the reg >code on your hand in ink and run from room to room, etc. i never >understood why people complained so much; also they can't be more than >$20 each, eh? I don't want to ship dongles internationally. International shipping is very expensive for any reasonable time frame. Dealing with shipping used to take way too much of my time. Electronic distribution is the way to go. Dongles don't work well for site licenses. If a dongle breaks or is lost you have to wait much longer to get it replaced than getting a new serial number. Then there is the connection problem: serial, ADB, or USB. It also then becomes a hardware support problem as well, when someone changes machines, Apple releases new machines, I/O specs change, etc. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Sun, 5 Sep 1999 00:21:41 +0100 From: Arie van Schutterhoef <---@---.---> Subject: Re:(OT) encouragement >supercollider is far beyond shareware, and way far much lots better than >you would get from a larger team-oriented development house - we love >our one-man band! what are you comparing to? - -SuperCollider might be a nice name... >it's 10x more polished than anything that exits ircam et al. - -And it doesn't crash during performances... >I hope it is a long time before the feature set is locked down. >I have a to-do list that probably extends for a few years. - -Thank god for that! >A one man band like this is >pretty revolutionary, I think, and the world needs more of them. - -May we should start a James McCarney Software Development Fund... greetings AvS <<<<<<<<<<<<<<<<<<<<<<<<<-////||\\\\->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Arie van Schutterhoef artistic director Schreck Ensemble # -laboratory for live electro-acoustic music- # The Netherlands e-mail:arsche@stad.dsl.nl http://www.xs4all.nl/~schreck/ Tel: 00-31-71-5612287 Fax: 00-31-70-3859268 <<<<<<<<<<<<<<<<<<<<<<<<<-////||\\\\->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------ Date: Sat, 4 Sep 1999 20:52:18 -0400 (EDT) From: "Ronald J. Kuivila" <---@---.---> Subject: grim reaper and SC on the morbid note of James' potential demise...perhaps licensed SC users should be in your will, James. (Key code only, if the source were provided as well it might become a case for Perry Mason!) Seriously, plenty of commercial software with hundereds of programmers disappears so Being A Real Bizness is not much of a guarantee. However, I do wonder if there would be a way to make the interpreter open source while keeping certain classes (like specific UnitGenerators) closed. This would encourage connectivity hacking and creation of extensions (my only serious gripes at the moment) while protecting the crucial intellectual property. (Example extensions: unit generators really designed to process FFT's. For example: FFT channel specific dynamics processing. Subject: Re: grim reaper and SC At 6:52 PM -0600 9/4/99, Ronald J. Kuivila wrote: >closed. This would encourage connectivity hacking and creation of >extensions (my only serious gripes at the moment) while protecting the >crucial intellectual property. > > (Example extensions: unit generators really designed to process FFT's. >For example: FFT channel specific dynamics processing. based on little more than a comb filter w/ adjustable attack and decay.) There will be ugen plug ins. Also I have implemented a new spectral rate .sr for processing spectra as a large block without the streaming latency between ugens. There is still some details that need to be taken care of to finish it. And as for my demise, things are taken care of.. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Sat, 4 Sep 1999 20:42:55 -0600 From: James McCartney <---@---.---> Subject: Re: crash bang wallop At 7:36 AM -0600 9/4/99, finer@easynet.co.uk wrote: >James, > >You said ; > >>Sequencer needs an initial value, so it calls the function when >>starting once, to get an initial output value. >>Sequencer passes in an event counter, which you can check and >>only generate a note if the event counter is > 0. > >I tried to implement this as follows - problem is it seems to crash the machine. > >Is there any obvious reason for this ? OMS saturation? You probably need to use a Trig to limit the rate that you send data out. Also for efficiency, you should not create a MIDIPort every time you want to send something. Create one and then use it each time: mport11 = MIDIPort(11); ... Sequencer.kr({arg count; ... mport11.control(1,0,0); ... --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Sun, 5 Sep 1999 16:13:25 +1000 From: Graeme Gerrard <---@---.---> Subject: Re: Authorization fails On 4/9/99 at 3:11 PM, asynth@io.com (James McCartney) wrote: Yes, I can see that dongles in labs would be a problem. And it may be that university labs are a signficant customer. I was just thinking of my own situation. I use the same computer all day everyday. I have only one dongle rather than a great chain of them. The one man band comment may have been misunderstood. I bought a great little sound editor a few years ago called SoundMaker, written by Alberto Ricci. (He also wrote a piece of shareware called Sound Effects). There was an open architecture for writing effects and there were some real cool spectral and granulation effects, also a great little list, just like this one, with enthusiastic users. I have no idea what happened, but Ricci seems to have just pulled the plug on the software a couple of years ago - no support, no upgrades; dead end. Because I paid for and have a serial number which doesn't expire, I can still use the program and the effects. I reckon if a predatory company like Microsoft try to pull a scheme like SC has, they would be out of business. > > I don't want to ship dongles internationally. > International shipping is very expensive for any reasonable time frame. > Dealing with shipping used to take way too much of my time. > Electronic distribution is the way to go. > Dongles don't work well for site licenses. > If a dongle breaks or is lost you have to wait much longer to get > it replaced than getting a new serial number. > Then there is the connection problem: serial, ADB, or USB. > It also then becomes a hardware support problem as well, when > someone changes machines, Apple releases new machines, I/O specs > change, etc. > > --- james mccartney james@audiosynth.com http://www.audiosynth.com > If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > - -- Graeme Gerrard Resonant Multimedia ------------------------------ Date: Sun, 5 Sep 1999 12:54:14 +0100 From: finer@easynet.co.uk Subject: Re: Authorization fails >Darn, and here I was thinking this is working pretty good... >Please don't let em turn you into Opcode... A one man band like this is >pretty revolutionary, I think, and the world needs more of them. > >dc I'd have to add my vote here - one of the few things that's NOT given me a problem as regards computers is the password authorisation scheme. This whole SC1 to SC2 free upgrade and the level of support has always struck me as an amazing deal. jem ------------------------------ Date: Sun, 5 Sep 1999 15:47:05 +0100 From: finer@easynet.co.uk Subject: simultaneous delayed transmission In this patch my laptop receives a message via midi from my G3 to play a note . It then sends a message basck for the G3 to play a note. For some reason though thisSynth.sched(0.5,{m.noteOn(1,60,64);"//note on".postln}); thisSynth.sched(2.5,{m.noteOn(1,60,0);"//note off".postln}) are sent at the same time so one hears nothing (as note on and note off are sent simultaneously) ( //receive from Midi from G3, play a note and send a message back // to G3 to play a note e = Env.new([0, 0.1, 0.1, 0], [0.2, 0.1, 0.2], 'linear', 2); m = MIDIOut(0); Synth.scope({ Voicer.ar({ arg voicer, i, synth, deltaTime, channel, note, velocity; // "MIDI received !".postln; if (note == 60,{"//sending midi".postln; thisSynth.sched(0.5,{m.noteOn(1,60,64);"//note on".postln}); thisSynth.sched(2.5,{m.noteOn(1,60,0);"//note off".postln}) } ); EnvGen.ar(e, SinOsc.ar((note ).midicps)); }, 1, // one audio output channel 1, // listen to MIDI channel 1 2 // max voices. If too many voices are triggered, then voice stealing occurs. ) }) ) I was wondering why ? This test works fine. ( //TEST - send midi to G3 m = MIDIOut(0); Synth.play({ thisSynth.sched(0.5,{m.noteOn(1,60,64)}); thisSynth.sched(2.5,{m.noteOn(1,60,0)}); FSinOsc.ar(56,0); }) ) Thanks jem ------------------------------ Date: Sun, 5 Sep 1999 10:17:49 -0600 From: James McCartney <---@---.---> Subject: Re: simultaneous delayed transmission At 8:47 AM -0600 9/5/99, finer@easynet.co.uk wrote: >In this patch my laptop receives a message via midi from my G3 to play a >note . It then sends a message basck for the G3 to play a note. > >For some reason though thisSynth.sched(0.5,{m.noteOn(1,60,64);"//note >on".postln}); > >thisSynth.sched(2.5,{m.noteOn(1,60,0);"//note off".postln}) >are sent at the same time so one hears nothing (as note on and note off are >sent simultaneously) Do not schedule things in a Spawned synth, because it ends before the scheduled events happen. Schedule them in the outer synth. ( //receive from Midi from G3, play a note and send a message back // to G3 to play a note e = Env.new([0, 0.1, 0.1, 0], [0.2, 0.1, 0.2], 'linear', 2); m = MIDIOut(0); Synth.scope({ arg outersynth; Voicer.ar({ arg voicer, i, synth, deltaTime, channel, note, velocity; // "MIDI received !".postln; if (note == 60,{"//sending midi".postln; outersynth.sched(0.5,{m.noteOn(1,60,64);"//note on".postln}); outersynth.sched(2.5,{m.noteOn(1,60,0);"//note off".postln}) } ... --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Mon, 25 Oct 1999 14:21:26 +0100 From: rkuivila@mail.wesleyan.edu Subject: Re: grim reaper and SC >There will be ugen plug ins. >Also I have implemented a new spectral rate .sr for processing >spectra as a large block without the streaming latency between ugens. >There is still some details that need to be taken care of to finish it. Interesting. Part of the problem in handling spectral data is that one wants to be able to view it as both a bunch of parallel channels (for spectral dynamics processing) and as a vector (for peak extraction, spectral centroid, etc). Would the parallel channel view be some kind of control spectral rate (.ksr?) or is there some other way of looking at this? Another problem is that you may want to use both views in the same processing. RJK PS: >And as for my demise, things are taken care of.. > Chuck Norris, perhaps? ------------------------------ Date: Sun, 5 Sep 1999 13:25:05 -0600 From: James McCartney <---@---.---> Subject: Re: grim reaper and SC At 7:21 AM -0600 10/25/99, rkuivila@mail.wesleyan.edu wrote: >>There will be ugen plug ins. >>Also I have implemented a new spectral rate .sr for processing >>spectra as a large block without the streaming latency between ugens. >>There is still some details that need to be taken care of to finish it. > >Interesting. > >Part of the problem in handling spectral data is that one wants to be able >to view it as both a bunch of parallel channels (for spectral dynamics >processing) and as a vector (for peak extraction, spectral centroid, etc). >Would the parallel channel view be some kind of control spectral rate >(.ksr?) or is there some other way of looking at this? I'm not sure what the implication of the distinction you're trying to make is. You can do some kinds of spectral dynamics processing now just by using a delay line that is equal to the fft length. There is no reason why a spectral rate unit generator could not do any kind of per bin dynamic processing you wanted. I see no reason for yet another kind of rate. >Chuck Norris, perhaps? huh? --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Sun, 5 Sep 1999 20:14:26 -0400 (EDT) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: grim reaper and SC > > I'm not sure what the implication of the distinction you're trying > to make is. You can do some kinds of spectral dynamics processing > now just by using a delay line that is equal to the fft length. > There is no reason why a spectral rate unit generator could not > do any kind of per bin dynamic processing you wanted. I see no > reason for yet another kind of rate. Simple spectral dynamics can be done with comparisons and functions like +, -, etc. (as in the example code in the FFT file). This works because the comparison function does not need to keep any state around. Forms of processing that involve some state (slew limiting or peak following) have to have as many copies of that (differing) state as there are bins. This could be done as a channel expansion where the FFT is looked at as an array of individual channels. So the FFT would be a 1024 channel array of frame rate functions. So, applying a compander to the FFT in this multi-channel mode would be done by using a (currently imaginary) .ksr constructor. What I am interested in doing is having a 'fatigue' processor that gradually attenuates bins that have been loud for a long time. Probably the attentuation should be based on critical bands rather than bins. So, I need to extract amplitude estimates, smear the peaks, and use the inverse of the smeared spectrum to scale the current FFT. I want this to have fast attack and slow decay for manipulating microphone feedback. > > >Chuck Norris, perhaps? > > huh? He has the necessary qualifications to be your bodyguard (in the Perry Mason scenario). And he's a Texas Ranger! ------------------------------ Date: Sun, 5 Sep 1999 20:26:03 -0600 From: James McCartney <---@---.---> Subject: Re: grim reaper and SC At 6:14 PM -0600 9/5/99, Ronald J. Kuivila wrote: >Simple spectral dynamics can be done with comparisons and functions like >+, -, etc. (as in the example code in the FFT file). This works because >the comparison function does not need to keep any state around. Forms of >processing that involve some state (slew limiting or peak following) have >to have as many copies of that (differing) state as there are bins. This >could be done as a channel expansion where the FFT is looked at as an >array of individual channels. So the FFT would be a 1024 channel array of >frame rate functions. So, applying a compander to the FFT in this >multi-channel mode would be done by using a (currently imaginary) .ksr >constructor. > >What I am interested in doing is having a 'fatigue' processor that >gradually attenuates bins that have been loud for a long time. Probably >the attentuation should be based on critical bands rather than bins. So, >I need to extract amplitude estimates, smear the peaks, and use the >inverse of the smeared spectrum to scale the current FFT. > >I want this to have fast attack and slow decay for manipulating microphone >feedback. There is no reason this cannot be done with using .sr --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Mon, 06 Sep 1999 09:58:24 +0200 From: Alberto de Campo <---@---.---> Subject: Re: Authorization fails Dear Graeme, > I bought a great little > sound editor a few years ago called SoundMaker, written by Alberto Ricci. (He > also wrote a piece of shareware called Sound Effects). There was an open > architecture for writing effects and there were some real cool spectral and > granulation effects, also a great little list, just like this one, with > enthusiastic users. I have no idea what happened, but Ricci seems to have just > pulled the plug on the software a couple of years ago - no support, no > upgrades; dead end. Because I paid for and have a serial number which doesn't > expire, I can still use the program and the effects. SoundMaker is alive and well: www. micromat.com distributes a version 1.0.3. The only thing I really miss with it is real-time playback of 24bit files. Best, Alberto ------------------------------ Date: Mon, 6 Sep 1999 11:08:14 +0100 From: finer@easynet.co.uk Subject: Internet Streaming/Interploation/thisSynth Two questions : 1. Supposing one wanted to send some music out over the internet - is there a way of NOT having to convert SC raw digital signal data into analog and then back into some other digital form for streaming ? ie straight to streaming. 2. While playing back a sample in Playbuf at a rate of 0.5 a mathematically enclined friend asked if SC performs any kind of polynomial interpolation when playing back samples slowly to make them sound better ? Sounded like a rather cpu intensive task to implement oneself (should one want to ). . . . . . or is this just a load of old rubbish. Thanks, Jem ------------------------------ Date: Mon, 6 Sep 1999 22:55:42 +1000 From: Graeme Gerrard <---@---.---> Subject: Re: Authorization fails On 6/9/99 at 9:58 AM, alberto@create.ucsb.edu (Alberto de Campo) wrote: Sorry, but Soundmaker IS dead, in the sense that version 1.03 was released about 2 years ago. There have been no updates since then, and there will not be any updates. I am trying to think of a piece of software in that category that I still use. (though Max updates are pretty slow:) It's a tribute to your namesake Alberto Ricci, that u think it is still useful, but the audio world seems to have moved on. SC2 is a pertinent example. > SoundMaker is alive and well: > www. micromat.com distributes a version 1.0.3. > The only thing I really miss with it is real-time playback of 24bit files. > > Best, Alberto > - -- Graeme Gerrard Resonant Multimedia ------------------------------ Date: Mon, 6 Sep 1999 22:58:45 +1000 From: Graeme Gerrard <---@---.---> Subject: Re: grim reaper and SC On 25/10/99 at 2:21 PM, rkuivila@mail.wesleyan.edu wrote: > Chuck Norris, perhaps? More like Nostrodamus. rkuivila is writing from the future! - -- Graeme Gerrard Resonant Multimedia ------------------------------ Date: Mon, 6 Sep 1999 12:44:25 -0400 From: Mark Ballora <---@---.---> Subject: states, processes and data passing We are creating a project which processes a live violin player via SC. There are different processes which are active at different times. They are triggered by a checkbox on a GUI. The checkboxes are called proc1, proc2, proc3, etc. At a level above individual processes, we want to establish states, which will activate some subset of the processes available. We have implemented state activation by polling a radio button. The radio buttons are called state1, state2, state3, etc. So we have this: synth.trepeat(0, 0.05, { if ( (state1.kr > 0), { proc1.kr=0; proc2.kr=1; proc3.kr=1 ... } { if ( (state2.kr > 0), { proc1.kr=1; proc2.kr=0; proc3.kr=0 ... } { if ( (state3.kr > 0), { ... } )} )} )} ); I suspect there's a tidier way to do this. The nested ifs can be crazy-making, as can having to explicitly turn each process on or off. Plus, we are running into problems passing data to the processes, such as the following: One process is harmonization. We have a PitchShift.ar within a Pause. We would like to have the pitchRatio change as part of different states. It would be a bit kludgy to have as many PitchShift-within-Pause combinations as we have states, each with a different pitchRatio argument. It would be tidier to be able to call a list of pitchRatio values with each activation of the PitchShift. Since TSpawn has the iterator argument, i, we tried putting a TSpawn within a Pause, like so: Pause.ar({ var harmParms; harmParms=#[ [0.5, 0.25, 1.3], [ 2.0, 2.5, 2.8], ... ]; TSpawn.ar({ arg tspawn,i; Mix.ar( PitchShift.ar( AudioIn.ar, 0.1, harmParms.clipAt(i), 0, 0.004)) },1, nil, proc5.kr) }, proc5.kr) Also kludgy, since we have the redundant use of the trigger for the Pause and the TSpawn; not ideal since TSpawn is really meant for finite events in EnvGens, not continuous audio in; and ultimately not functional since it's within a Pause, and the last set of pitchRatios gets re-activated each time we call the state again, so the harmonization is cumulative, not iterative. In short, I think we've painted ourselves into a corner with this setup. There must be some better way to set up states which are groups of processes, and pass data to them. But for the moment, we're stuck in our corner. ------------------------------ Date: Mon, 6 Sep 1999 13:49:09 -0400 (EDT) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: grim reaper and SC > > > >What I am interested in doing is having a 'fatigue' processor that > >gradually attenuates bins that have been loud for a long time. Probably > >the attentuation should be based on critical bands rather than bins. So, > >I need to extract amplitude estimates, smear the peaks, and use the > >inverse of the smeared spectrum to scale the current FFT. > > > >I want this to have fast attack and slow decay for manipulating microphone > >feedback. > > There is no reason this cannot be done with using .sr I guess I should wait for examples in the release. (I suppose what I will need to do is explicitly construct a list of delayed copies of the FFT buffer and pass that to the control rate ugens, but then how do I reassemble the result into an FFT buffer?) RJK ------------------------------ Date: Mon, 6 Sep 1999 12:56:12 -0600 From: James McCartney <---@---.---> Subject: Re: grim reaper and SC At 11:49 AM -0600 9/6/99, Ronald J. Kuivila wrote: >> > >> >What I am interested in doing is having a 'fatigue' processor that >> >gradually attenuates bins that have been loud for a long time. Probably >> >the attentuation should be based on critical bands rather than bins. So, >> >I need to extract amplitude estimates, smear the peaks, and use the >> >inverse of the smeared spectrum to scale the current FFT. >> > >> >I want this to have fast attack and slow decay for manipulating microphone >> >feedback. >> >> There is no reason this cannot be done with using .sr > >I guess I should wait for examples in the release. There will need to be UGens to support what you want to do. The problem with passing you every bin value, is that there is no way it would be fast enough. >(I suppose what I will need to do is explicitly construct a list of >delayed copies of the FFT buffer and pass that to the control rate ugens, >but then how do I reassemble the result into an FFT buffer?) I don't know what this has to do with control rate.. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Mon, 6 Sep 1999 13:24:38 -0600 From: James McCartney <---@---.---> Subject: Re: states, processes and data passing At 10:44 AM -0600 9/6/99, Mark Ballora wrote: >We are creating a project which processes a live violin player via SC. > >There are different processes which are active at different times. They >are triggered by a checkbox on a GUI. The checkboxes are called proc1, >proc2, proc3, etc. > >At a level above individual processes, we want to establish states, which >will activate some subset of the processes available. We have implemented >state activation by polling a radio button. The radio buttons are called >state1, state2, state3, etc. So we have this: > >synth.trepeat(0, 0.05, { if ( (state1.kr > 0), > { proc1.kr=0; proc2.kr=1; proc3.kr=1 ... } > { if ( (state2.kr > 0), > { proc1.kr=1; proc2.kr=0; proc3.kr=0 ... } > { if ( (state3.kr > 0), > { ... } )} )} )} ); > >I suspect there's a tidier way to do this. It is not even legal. You shouldn't allocate a UGen in a synth task. It will never execute because it has no Synth. You can only allocate UGens in the ugen graph function of the Synth. Functions within that function such as sched tasks are called after the Synth has been constructed. To get the value of a ControView, you should use 'value' not 'kr'. You'd be better off making action functions for your radio buttons. And I don't know what proc1.kr=0; proc2.kr=1; proc3.kr=1 is supposed to be doing. You can't assign to a UGen, it is a value not a variable. I'm not sure exactly what you're trying to do, but here's a guess. ( var w, p, z; w = GUIWindow.new("panel", Rect.newBy(128, 64, 195, 163)); RadioButtonView.new( w, Rect.newBy(10, 17, 128, 20), "0.5", 0, 0, 1, 0, 'linear'); RadioButtonView.new( w, Rect.newBy(10, 41, 128, 20), "0.75", 0, 0, 1, 0, 'linear'); RadioButtonView.new( w, Rect.newBy(10, 65, 128, 20), "1", 1, 0, 1, 0, 'linear'); RadioButtonView.new( w, Rect.newBy(10, 89, 128, 20), "1.5", 0, 0, 1, 0, 'linear'); RadioButtonView.new( w, Rect.newBy(10, 113, 128, 20), "2", 0, 0, 1, 0, 'linear'); [0.5, 0.75, 1, 1.5, 2].do({ arg x, i; w.at(i).action = { arg view; if (view.value==1 && p.notNil, { p.source = x }); }; }); play({ z = SinOsc.ar(800, 0, 0.1); p = Plug.kr(1); PitchShift.ar(z, 0.02, p, 0, 0.0001) }); p = nil; w.close; ) OR perhaps this: ( var w, p, z; w = GUIWindow.new("panel", Rect.newBy(128, 64, 195, 163)); CheckBoxView.new( w, Rect.newBy(10, 17, 128, 20), "A", 0, 0, 1, 0, 'linear'); CheckBoxView.new( w, Rect.newBy(10, 41, 128, 20), "B", 0, 0, 1, 0, 'linear'); CheckBoxView.new( w, Rect.newBy(10, 65, 128, 20), "C", 1, 0, 1, 0, 'linear'); CheckBoxView.new( w, Rect.newBy(10, 89, 128, 20), "D", 0, 0, 1, 0, 'linear'); CheckBoxView.new( w, Rect.newBy(10, 113, 128, 20), "E", 0, 0, 1, 0, 'linear'); 5.do({ arg i; w.at(i).action = { arg view; if (p.notNil, { p.at(i).source = view.value; }); }; }); play({ z = SinOsc.ar(800, 0, 0.1); p = []; Mix.arFill(5, { arg i; q = Plug.kr(w.at(i).value); p = p.add(q); Pause.ar({ var s; s = SinOsc.ar( SinOsc.ar( SinOsc.ar(0.5.rand, 2pi.rand, 15.0.rand, 40.0.rand), 2pi.rand, 400.0.rand, 2000.0.rand ), 2pi.rand, 0.1 ); Pan2.ar(s, SinOsc.kr(1.0.linrand, 2pi.rand)); }, q); }); }); p = nil; w.close; ) --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: < ------------------------------ Date: Tue, 26 Oct 1999 16:29:31 +0100 From: rkuivila@mail.wesleyan.edu Subject: Re: grim reaper and SC Hi James, >>(I suppose what I will need to do is explicitly construct a list of >>delayed copies of the FFT buffer and pass that to the control rate ugens, >>but then how do I reassemble the result into an FFT buffer?) > >I don't know what this has to do with control rate.. Hmmm, perhaps I am not understanding something here. I am thinking of the FFT as a vector of 'samples' with the size of the FFT determining the 'control rate'. Processing individual FFT bins is then processing a subsampled copy of the FFT at 'control rate'. So, slewing a specific FFT bin might look like: Slew.kr(delay.ar(FFT, binNum/SampleRate, binNum/SampleRate), upSlope, downSlope); This seems syntactically pretty horrible and certainly inefficient, so I was proposing the introduction of an additional scheduling mode, .ksr: Slew.ksr(FFT,upSlope, downSlope); .ksr would imply performing whatever the ugen operation is on each element of the sample vector independently. So, adding this mode to a given Ugen is adding a special case where the runtime of the Ugen iterates over states as well as samples (and stateless computations would not require any change at all). Since KSR computations would return a full FFT's worth of samples they could be freely combined with FFT stuff done at SR rate. RJK PS: When externals become possible, I would love to take this on (although I would definitely try to wheedle you out of the relevant Ugen code to extend...) ------------------------------ Date: Mon, 6 Sep 1999 16:30:57 -0400 From: Mark Ballora <---@---.---> Subject: Re: states, processes and data passing >>There are different processes which are active at different times. They >>are triggered by a checkbox on a GUI. The checkboxes are called proc1, >>proc2, proc3, etc. >> >>At a level above individual processes, we want to establish states, which >>will activate some subset of the processes available. We have implemented >>state activation by polling a radio button. The radio buttons are called >>state1, state2, state3, etc. So we have this: >> >>synth.trepeat(0, 0.05, { if ( (state1.kr > 0), >> { proc1.kr=0; proc2.kr=1; proc3.kr=1 ... } >> { if ( (state2.kr > 0), >> { proc1.kr=1; proc2.kr=0; proc3.kr=0 ... } >> { if ( (state3.kr > 0), >> { ... } )} )} )} ); >> >>I suspect there's a tidier way to do this. > >It is not even legal. You shouldn't allocate a UGen in a synth >task. It will never execute because it has no Synth. >You can only allocate UGens in the ugen graph function of the >Synth. Functions within that function such as sched tasks are >called after the Synth has been constructed. To get the value >of a ControView, you should use 'value' not 'kr'. Oops. I goofed in copying the code into email. Sorry. :-( proc1.kr, proc2.kr, etc, are triggers for Pause processes. I do use 'value'. state1.kr, state2.kr ... are radio buttons. Synth.play({ synth.trepeat(0, 0.05, { if ( (state1.value > 0), { proc1.value=0; proc2.value=1; proc3.value=1 ... } { if ( (state2.value > 0), { proc1.value=1; proc2.value=0; proc3.value=0 ... } { if ( (state3.value > 0), { ... } )} )} )} ); Pause.ar({ something }, proc1.kr) + Pause.ar({ something else }, proc2.kr) + ... }) The idea is that each radio button -- state1, state2, etc. -- switches on a certain number of processes. So radio button 1 will activate a Pause which contains the harmonizer process with a pitchRatio array of maybe #[1.2, 1.3, 1.4], by setting proc1.value to 1; it also activates another Pause which plays a SinOsc by setting proc2.value to 1, and switches all the other Pauses off. Radio button 2 will play an audio file and ring modulate the input, again by setting two pause triggers to a value of 1. Radio button 3 will activate the harmonizer Pause again, but this time with a pitchRatio array of #[2.2, 2.5, 2.7]. So conceptual level one is easy. Make a GUI with a bunch of checkboxes, each of which acts as a trigger to a Pause containing something. The GUI has checkboxes and radio buttons. In developing the piece we use the checkboxes and experiment by mixing and matching process combinations. For performance, we've got a set of states stored, which are activated by the radio buttons. Along the lines of something like Robert Rowe's Cypher program. It's moving to level two, the states, that's my problem. That is, activating more than one of these Pauses, and at the same time pushing data into them. I'm not sure that polling a radio button in a trepeat is the optimal way to do it. As for passing data, I could have several Pauses which contain a PitchShift, each with its own trigger and its own pitchRatio array, but it would be easier just to have one PitchShift/Pause, and change the pitchRatio each time I use it. Hope that's clearer. Sorry for the confusion. ------------------------------ Date: Mon, 6 Sep 1999 13:33:50 -0700 (PDT) From: Richard Karpen <---@---.---> Subject: Re: grim reaper and SC I have added some extensions to Csound's phase vocoder that have turned out to be very useful to a number of composers and that might work in real-time in SC, depending upon how they're used. One such UG ("pvread") just reads a single analysis bin and returns two vectors; one for frequency and one for amplitude. These can then be used as inputs to oscilators, filters, whatever. Another UG ("pvadd") allows one to choose a range of bins and uses simple additive synthesis based on the data. It can be pretty quick especially if one is not re-synthesizing lots of bins. Some very nice sounds have come from these two units. They have other functionality for gating accoring to amplitude and frequency differences between bins as well that I think could work with SC in real time (maybe with a G4 anyway). It would be great to have some of this functionality at our fingertips in SC. Richard Karpen On Tue, 26 Oct 1999 rkuivila@mail.wesleyan.edu wrote: > Hi James, > > >>(I suppose what I will need to do is explicitly construct a list of > >>delayed copies of the FFT buffer and pass that to the control rate ugens, > >>but then how do I reassemble the result into an FFT buffer?) > > > >I don't know what this has to do with control rate.. > > Hmmm, perhaps I am not understanding something here. I am thinking of the > FFT as a vector of 'samples' with the size of the FFT determining the > 'control rate'. Processing individual FFT bins is then processing a > subsampled copy of the FFT at 'control rate'. So, slewing a specific FFT > bin might look like: > > Slew.kr(delay.ar(FFT, binNum/SampleRate, binNum/SampleRate), upSlope, > downSlope); > > This seems syntactically pretty horrible and certainly inefficient, so I > was proposing the introduction of an additional scheduling mode, .ksr: > > Slew.ksr(FFT,upSlope, downSlope); > > .ksr would imply performing whatever the ugen operation is on each element > of the sample vector independently. So, adding this mode to a given Ugen > is adding a special case where the runtime of the Ugen iterates over states > as well as samples (and stateless computations would not require any change > at all). > > Since KSR computations would return a full FFT's worth of samples they > could be freely combined with FFT stuff done at SR rate. > > > > RJK > > PS: When externals become possible, I would love to take this on (although > I would definitely try to wheedle you out of the relevant Ugen code to > extend...) > > > > > > ------------------------------ End of sc-users-digest V1 #59 *****************************