From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #18 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 Thursday, December 3 1998 Volume 01 : Number 018 ---------------------------------------------------------------------- Date: Tue, 1 Dec 1998 10:45:50 -0600 From: James McCartney <---@---.---> Subject: future stuff Digidesign has provided me the materials necessary to use their Direct IO drivers, so this support will be forthcoming. I will support CNMAT's Open Sound Control. There are a number of possible forms this could take and I have not decided the best way to do it yet. Ville Pulkki of Helsinki University of Technology has provided me with the code to his Vector Base Amplitude Panning (VBAP) algorithm. This allows panning in a geodesic spherical arrangement of speakers. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Tue, 1 Dec 98 18:17:54 +0100 From: Michael <---@---.---> Subject: Re: future stuff Hello James, Does this mean that SC will address the AudioMedia III (which if I understand correctly can be run by Digidesign's Direct IO drivers)? Michael Bransome still in Stockholm ------------------------------ Date: Tue, 1 Dec 1998 11:47:57 -0600 From: James McCartney <---@---.---> Subject: Re: future stuff At 11:17 AM -0600 12/1/98, Michael wrote: >Hello James, > >Does this mean that SC will address the AudioMedia III (which if I >understand correctly can be run by Digidesign's Direct IO drivers)? yes. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Wed, 2 Dec 98 00:18:56 +0100 From: Michael Bransome <---@---.---> Subject: Re: future stuff That's good news - thanx! ------------------------------ Date: Wed, 2 Dec 1998 10:09:13 -0600 From: James McCartney <---@---.---> Subject: [fwd] Om: SC2.0d29 now available Is anyone else having this problem? >From: Per Grunditz <---@---.---> > > Reply to: Om: SC2.0d29 now available >>SC2.0d29 is now available via ftp. >> >> >>ftp://www.audiosynth.com/pub/updates/SC2d29.sea.bin > >Is something wrong with ftp://www.audiosynth.com/? >Have been trying for two days and I only get 50 - 100 bytes/sek. >I have a 128 kBps internet connection and I do not have problems >downloading from other servers. >/Per ------------------------------ Date: Wed, 2 Dec 1998 11:13:29 -0500 (EST) From: "Ronald J. Kuivila" <---@---.---> Subject: comments on GUIUtils specifics: 1. Bravo! This package has really helped me get started with SC2. I have learned quite a lot about programming in Supercollider from looking at the code for GUIUtils. 2. there is minor bug in ParameterWindow.sc: deletesetting { if ( currentsetting.value > 0, { settings.removeAt(currentsetting.value.asInteger); currentsetting.maxval_(settings.size - 1); //**minor bug: // (currentsetting.value min: setting.size -1) currentsetting.value_(currentsetting.value min: (settings.size -1)); this.loadsetting; }); } 3. I am noticing a problem with 'orphaned' synthesis code loading down the system. Any easy fix? Some SC needs: 4. On my 8500, I notice a pretty severe performance penalty with lots of sliders. My impression is krate (ca. 1 kHz) is too fast for input polling (100 - 200 Hz would suffice). Would it be possible to introduce an "event rate" for i/o devices? For example, would it be possible to have a synth task evaluate a tree of unit generators? 5. How about a ControlView that implements an OpCode-style "numerical" (i.e., a number box where clicking and dragging changes value). A minor design rant: 6. I want to raise some design questions about ControlViews. Part of the power of SuperCollider is that it keeps synthesis decoupled from the GUI. It seems to me that ControlViews break this approach. The "connect" method illustrates the point. Connect is used to implement a dual interface (slider and button) to a data value. It is incredibly useful. But the implementation involves the slider and the button setting each other's values. It would be cleaner to implement this as two GUI's to the same underlying data. Another example is the case of controlling many channels of the same underlying synthesis algorithm. It would be nice to be able to have a single GUI window with a list of synthesis instantiations attached as an alternative to a separate window for each instantiation. ( My preferred control interface is a combination of a MIDI keyboard, a fader box, and a graphics tablet. The keyboard is used to map the faders and tablet to different synthesis channels and different parameters and to select presets as "targets" for interpolation or as straight-ahead presets. So, once the presets are defined, the need for the GUI goes away entirely.) RJK ------------------------------ Date: Wed, 2 Dec 1998 18:21:00 +0200 From: laurson@amadeus.siba.fi (Mikael Laurson) Subject: Questions I am planning to buy in the near future a sound card (currently I am using only the Mac DA-converters with SC2). What is the best choice? Is it Sonorus Studio + DA/24 converters? Will SC2 be able play 24 bits? What about the Wacom tablet. Should one buy directly the A4-size tablet as it includes also a 4D mouse? Or should one choose only the smallest (and cheapest) one (A6)? I am in the process (finally) of rewriting some old SC2 code of mine (version d22). My aim is to make some physical modelling instruments and for this I will need classes for String and Stringinstrument. The closest SC-example in this direction is probably the "Griot modeling" example. A String will consist of a delayline + other parameters such as base pitch, feedback scaler, lowpass filter, excitation sample, etc. A Stringinstrument will basically be a collection of strings and would have methods for pluck, pizzpluck, bow, etc. Also it would handle the interaction between strings ("symphatetic" effects). Typically I would create an instrument only once and send then various excitations to the strings (just like in the "Griot modeling" example). The difference is, however, that I should be able to send continuos-control information after the excitation to the strings, such as vibrato, change the feedback-scaler, change the low-pass filter cut-off frequency, etc. It is not clear to me what is the best way to achieve this in the current system. Below is one test which basically works. This is of course a greatly simplified version of what I try to achieve (I use here only a SinOsc oscillator instead of a delay-line). My point is here only to find an efficient way to trigger events that use the poll and set methods. I create a global SinOsc whose frequency is controlled by an envelope using the pollfn. Events are triggered every 2 seconds: (var output, tspawn, sig, env, fund, fr, fenv, ae, pe, frref; var ctrlrate, dur, pollfn, nofnotes, dtime, attacktime; ctrlrate = 0.01; dur = 1.5; dtime = 2; nofnotes = 5; attacktime = 0.01; { arg synth; fund = 440; frref = Ref.new(fund); fr = ControlIn.kr (frref); sig = SinOsc.ar(fr.value,0,0.3); ae = Env.new([0,1,1,0],[attacktime,0.8,0.1],'linear'); pe = Env.new([fund,fund+100,fund],[0.5,0.5],'linear'); pollfn = {TSpawn.ar({ arg argTSpawn, j, synth2, frenv; set(frref, poll(frenv)); sig }, 1, nil, 0)}; Spawn.ar({arg spawn, i, synth2; env = EnvGen.kr(ae,1,0,1,0, dur); fenv = EnvGen.kr(pe,1,0,1,0, dur); output = value(pollfn); tspawn = output.source; synth2.repeatN(0, ctrlrate, floor(dur/ctrlrate), { tspawn.trigger(fenv) }); env*sig; }, 1, dtime,nofnotes); }.play; ) Although this example works there are several problems. Firstly, this scheme seems to be slow (this depends very much on the ctrlrate value). Secondly, there is a strange side effect: if I change the attacktime parameter to smaller values, say 0.001, the sine-wave is heavily distorted. Finally this scheme seems to be quite complex. Is there a simpler way to achieve the same result? Here is another try (but with the same problems than the previous one): (var sig, env, fund, fr, fenv, ae, pe, frref; var ctrlrate, dur, pollfn, nofnotes, dtime, attacktime; ctrlrate = 0.01; dur = 1.5; dtime = 2; nofnotes = 5; attacktime = 0.01; {fund = 440; frref = Ref.new(fund); fr = ControlIn.kr (frref); sig = SinOsc.ar(fr.value,0,0.3); ae = Env.new([0,1,1,0],[attacktime,0.8,0.1],'linear'); pe = Env.new([fund,fund+100,fund],[0.5,0.5],'linear'); Spawn.ar({arg spawn, i, synth; env = EnvGen.kr(ae,1,0,1,0, dur); fenv = EnvGen.kr(pe,1,0,1,0, dur); Spawn.ar({ set(frref, poll(fenv)); sig }, 1, ctrlrate, floor(dur/ctrlrate)); sig*env }, 1, dtime,nofnotes); }.play; ) Mikael ================================ Mikael Laurson Hollantilaisentie 1 A 2 00300 Helsinki 33 Finland E-mail: laurson@siba.fi ================================ ------------------------------ Date: Wed, 02 Dec 1998 17:35:38 +0100 From: "Iannis Zannos" <---@---.---> Subject: Download speeds from audiosynth.com (Re: [fwd] Om: SC2.0d29 now available) It took me some 15 minutes this morning to download SC2.0d29. This is longish, but it was "rush-hour" on the data-bahn (ca 10:30 am). I tried downloading twice, and left both download processes running. That seemed to boost up speed to an average of 1500/2000 Bytes/sec with occasional peaks above. Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 - ---------- >From: James McCartney <---@---.---> >To: "sc-users" >Subject: [fwd] Om: SC2.0d29 now available >Date: Wed, 2 Dec 1998 5:09 PM > > >Is anyone else having this problem? > >>From: Per Grunditz <---@---.---> >> >> Reply to: Om: SC2.0d29 now available >>>SC2.0d29 is now available via ftp. >>> >>> >>>ftp://www.audiosynth.com/pub/updates/SC2d29.sea.bin >> >>Is something wrong with ftp://www.audiosynth.com/? >>Have been trying for two days and I only get 50 - 100 bytes/sek. >>I have a 128 kBps internet connection and I do not have problems >>downloading from other servers. >>/Per > > > > ------------------------------ Date: Wed, 2 Dec 1998 11:38:41 -0400 From: kbabb@escape.com (Kenneth N Babb) Subject: Re: [fwd] Om: SC2.0d29 now available >Is anyone else having this problem? > >>From: Per Grunditz <---@---.---> >> >> Reply to: Om: SC2.0d29 now available >>>SC2.0d29 is now available via ftp. >>> >>> >>>ftp://www.audiosynth.com/pub/updates/SC2d29.sea.bin >> >>Is something wrong with ftp://www.audiosynth.com/? >>Have been trying for two days and I only get 50 - 100 bytes/sek. >>I have a 128 kBps internet connection and I do not have problems >>downloading from other servers. >>/Per I downloaded SC2.0d29 without problem on Monday 11/30. Regards, Kenneth Babb ------------------------------ Date: Wed, 2 Dec 1998 11:06:40 -0600 From: James McCartney <---@---.---> Subject: Re: comments on GUIUtils >4. On my 8500, I notice a pretty severe performance penalty with lots of >sliders. My impression is krate (ca. 1 kHz) is too fast for input >polling (100 - 200 Hz would suffice). The "polling" merely consists of reading an address, so there is negligible speed penalty based on the control rate. That address is updated by the control when it changes. >Would it be possible to introduce >an "event rate" for i/o devices? This is not necessary. I think you may have misinterpreted where a speed penalty comes from. Many unit generators have to use a more expensive algorithm if a particular parameter is modulated than when it is a scalar. I think that may be where your penalty comes from, not from the control. >For example, would it be possible to >>have a synth task evaluate a tree of unit generators? I don't understand what you are thinking of. You can of course run any code in a synth task. > >5. How about a ControlView that implements an OpCode-style "numerical" >(i.e., a number box where clicking and dragging changes value). There is one already: NumericalView > >A minor design rant: > >6. I want to raise some design questions about ControlViews. Part >of the power of SuperCollider is that it keeps synthesis decoupled from >the GUI. It seems to me that ControlViews break this approach. > > The "connect" method illustrates the point. Connect is used to >implement a dual interface (slider and button) to a data value. It is >incredibly useful. But the implementation involves the slider and the >button setting each other's values. It would be cleaner to implement this >as two GUI's to the same underlying data. That example was written before the Model-View dependancy stuff was implemented. You can do what you describe. > > Another example is the case of controlling many channels of the same >underlying synthesis algorithm. It would be nice to be able to have a >single GUI window with a list of synthesis instantiations attached as an >alternative to a separate window for each instantiation. Hmm, having Spawn do dependancy notification would slow it down a lot. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Wed, 2 Dec 1998 11:15:06 -0600 From: James McCartney <---@---.---> Subject: Re: Questions At 10:21 AM -0600 12/2/98, Mikael Laurson wrote: >I am planning to buy in the near future a sound card (currently I am using >only the Mac >DA-converters with SC2). >What is the best choice? Is it Sonorus Studio + DA/24 converters? >Will SC2 be able play 24 bits? I find I get better performance from the Korg card. The Sonorus card's sound input takes more CPU than I think it should. I will try and resolve this with Sonorus if possible, but that's how it is now. >What about the Wacom tablet. Should one buy directly the A4-size tablet as it >includes also a 4D mouse? Or should one choose only the smallest (and >cheapest) one (A6)? They're marketed in inches over here.. I have not compared them. I went for the largest 12x18 inch in order to have space for two devices. The 9x12 and 12x18 both use up a serial port, which means you can have a modem or a printer but not both with the Wacom connected. The smaller ones go into the ADB port. I'll have a look at your example.. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Wed, 2 Dec 1998 12:23:25 -0500 (EST) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: [fwd] Om: SC2.0d29 now available I just downloaded w/0 difficulty. RJK ------------------------------ Date: Wed, 2 Dec 1998 11:27:30 -0600 From: James McCartney <---@---.---> Subject: Re: comments on GUIUtils >That example was written before the Model-View dependancy stuff was >implemented. >You can do what you describe. Oh, I may not be responding to the right thing. I thought you were refering to the linking example in the gui examples file, but I guess you are referring to GUI Utils. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Wed, 2 Dec 1998 12:35:57 -0500 (EST) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: comments on GUIUtils > Many unit generators have to use a more expensive algorithm if a > particular parameter is modulated than when it is a scalar. > I think that may be where your penalty comes from, not from the control. > > >For example, would it be possible to > >>have a synth task evaluate a tree of unit generators? What I was imagining was to use sched to have polling at a slower rate. I ran the simple sine wave included in the example parameter window and it was taking 25% of the cpu...that seems like a lot for frequency amplitude and pan. > >A minor design rant: > > > >6. I want to raise some design questions about ControlViews. Part > >of the power of SuperCollider is that it keeps synthesis decoupled from > >the GUI. It seems to me that ControlViews break this approach. > > > > The "connect" method illustrates the point. Connect is used to > >implement a dual interface (slider and button) to a data value. It is > >incredibly useful. But the implementation involves the slider and the > >button setting each other's values. It would be cleaner to implement this > >as two GUI's to the same underlying data. > > That example was written before the Model-View dependancy stuff was > implemented. > You can do what you describe. I'll check it out. Is there an example hiding somewhere? > > > > Another example is the case of controlling many channels of the same > >underlying synthesis algorithm. It would be nice to be able to have a > >single GUI window with a list of synthesis instantiations attached as an > >alternative to a separate window for each instantiation. > > Hmm, having Spawn do dependancy notification would slow it down a lot. ------------------------------ Date: Wed, 02 Dec 1998 19:08:42 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: comments on GUIUtils / new version is on the way Ron, thanks for the encouragement on GUIUtils it is a running project for me, because I use it for testing and tweaking new algorithms. A new version was completed yesterday, which I plan to send in to James when I clean up the commented debug code, in 2-3 days. Some of the features of the new version address your comments, so I will answer them here: >2. there is minor bug in ParameterWindow.sc: It has been fixed in the new version, as you suggest. >3. I am noticing a problem with 'orphaned' synthesis code loading down the >system. Any easy fix? Do you mean fragments of code left there for no purpose? If so please point them out so I can remove them. So far I am aware only of working code or examples. The library should compile without problems. >4. On my 8500, I notice a pretty severe performance penalty with lots of >sliders. My impression is krate (ca. 1 kHz) is too fast for input >polling (100 - 200 Hz would suffice). Would it be possible to introduce >an "event rate" for i/o devices? For example, would it be possible to >have a synth task evaluate a tree of unit generators? Right, that was a major problem, and here is what I did for it: The new version of GUIUtils introduces LabeledArrayV as a subclass of ArrayV which allows you to add a auto-sizing text label to each NumericalView. I use such labeled numerical-view arrays as value sources for multitudes of parameters which are not continuous but, polled (eg. by Spawn, TSpawn or task). Since ArrayV and LabeledArrayV do not create k-rate controllers, one assigns to sliders only those parameters which actually need to be continuous, the rest is done with parameters LabeledArrayV. The NumericalView instances which form a LabeledArrayV always update predefined value slots in a cache array from which they can be polled whenever needed. My new examples need so many parameters it would be unrealistic to handle them in another way. The change is small and easy but the solution is light-weight and works well. Another related point is that one can at any moment assign new values to variables which act as sources of controllers punctually in tasks (see Synth.help, message ".source"). I have not tried it out but it looks like an interesting way of marrying continuous with discrete control and may open up avenues of freedom in that domain. >5. How about a ControlView that implements an OpCode-style "numerical" >(i.e., a number box where clicking and dragging changes value). As far as I know this is exactly the case with NumericalView. Works perfect. Can You describe any difference to OpCode-Style or any problems? By the way: You can tab to change focus between consecutive views and then type in a new value for a NumericalView. To finish the data entry, type the enter key. Works super when one wants to jump to a new numerical value. >6. I want to raise some design questions about ControlViews. Part >of the power of SuperCollider is that it keeps synthesis decoupled from >the GUI. It seems to me that ControlViews break this approach. > > The "connect" method illustrates the point. Connect is used to >implement a dual interface (slider and button) to a data value. It is >incredibly useful. But the implementation involves the slider and the >button setting each other's values. It would be cleaner to implement this >as two GUI's to the same underlying data. Short answer: ControlViews do not automatically create .kr control sources, but can do so if you whenever you need them to. The mechanisms for connecting the number underlying a ControlView into one's synthesis algorithm are mostly transparent. Longer: If I remember correctly, the "connect" method you mention is my own addition to ControlView made for GUIUtils. If it is adopted in the SC proper release, all the better (James, please correct if necessary). The point you make about separating the "Controller" from the "Model" is theoretically interesting. The praxis is, a Slider or a Numerical View always display and change a number (Integer or Real). So to couple them permanently to a number as kind of "private model" will not harm. What one does with that number in synthesis is ones own business, so to speak. The model variable, the dependents mechanism provided in Object, plus the "action" mechanism, and finally the optional creation of controllers on ControlViews are good tools. In fact the update mechanism used in the ArrayV class members described above is an example of how to couple GUI controls to synth parameters without "Controller" instances. There may be more refined ways for creating value interdependencies like via writing / reading to referenced slots of arrays but I think these are still beyond the scope of problems that have yet been dealt with in SC. Perhaps in the future... I do not know yet how much the above tools suffice to do what you describe in your next very interesting comments: > Another example is the case of controlling many channels of the same >underlying synthesis algorithm. It would be nice to be able to have a >single GUI window with a list of synthesis instantiations attached as an >alternative to a separate window for each instantiation. Am working on connecting a bundle of synth-algorithms to a common control source dynamically. I think SoundModel can be the starting point for this. (This is NOT for the next release, possibly for the one after that). I am not sure what you mean with " >list of synthesis instantiations attached as an >alternative to a separate window for each instantiation." Do you mean: a window with a list of algorithms, each of which may be started separately, and is controlled by the controls of a single GUI window? > ( My preferred control interface is a combination of a MIDI keyboard, a >fader box, and a graphics tablet. The keyboard is used to map the faders >and tablet to different synthesis channels and different parameters and to >select presets as "targets" for interpolation or as straight-ahead >presets. So, once the presets are defined, the need for the GUI goes away >entirely.) Sounds quite a powerful setup. I still have a use for GUIs in any case, if only because an appropriate visualization is valuable feedback for checking the relationship of your input with the resulting sound. Not that sliders and NumberBoxes are all there is to a GUI - richer and subtler means may be worth exploring (like 2d or 3d shapes). But this is also a matter of ideology and style, so what one does depends on the situation and project at hand. Cheers, Iannis PS: More points in the next release are some bug fixes, making ArrayV really work, including saving settings, and making SoundLib capable of storing palettes, (for hierarchically nested libraries). Sorry if I rant too much in advance, hope to post the actual update very soon. Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 - ---------- >From: "Ronald J. Kuivila" <---@---.---> >To: sc-users@lists.io.com >Subject: comments on GUIUtils >Date: Wed, 2 Dec 1998 5:13 PM > > > deletesetting { > if ( currentsetting.value > 0, { > settings.removeAt(currentsetting.value.asInteger); > currentsetting.maxval_(settings.size - 1); > //**minor bug: > // (currentsetting.value min: setting.size -1) > currentsetting.value_(currentsetting.value min: (settings.size -1)); > this.loadsetting; }); > } deletesetting { if ( currentsetting.value > 0, { settings.removeAt(currentsetting.value.asInteger); currentsetting.maxval_(settings.size - 1); currentsetting.value_(currentsetting.value min: settings.size - 1); this.loadsetting; }); } >3. I am noticing a problem with 'orphaned' synthesis code loading down the >system. Any easy fix? > >Some SC needs: > >4. On my 8500, I notice a pretty severe performance penalty with lots of >sliders. My impression is krate (ca. 1 kHz) is too fast for input >polling (100 - 200 Hz would suffice). Would it be possible to introduce >an "event rate" for i/o devices? For example, would it be possible to >have a synth task evaluate a tree of unit generators? > >5. How about a ControlView that implements an OpCode-style "numerical" >(i.e., a number box where clicking and dragging changes value). > >A minor design rant: > >6. I want to raise some design questions about ControlViews. Part >of the power of SuperCollider is that it keeps synthesis decoupled from >the GUI. It seems to me that ControlViews break this approach. > > The "connect" method illustrates the point. Connect is used to >implement a dual interface (slider and button) to a data value. It is >incredibly useful. But the implementation involves the slider and the >button setting each other's values. It would be cleaner to implement this >as two GUI's to the same underlying data. > > Another example is the case of controlling many channels of the same >underlying synthesis algorithm. It would be nice to be able to have a >single GUI window with a list of synthesis instantiations attached as an >alternative to a separate window for each instantiation. > > ( My preferred control interface is a combination of a MIDI keyboard, a >fader box, and a graphics tablet. The keyboard is used to map the faders >and tablet to different synthesis channels and different parameters and to >select presets as "targets" for interpolation or as straight-ahead >presets. So, once the presets are defined, the need for the GUI goes away >entirely.) > > > >RJK > > ------------------------------ Date: Wed, 2 Dec 1998 13:09:27 -0500 (EST) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: comments on GUIUtils Hi James, I think what I am claiming is that it would be preferable to have control data encapsulated with the synthesis alogrithm it controls rather than with the interface widget that provides access to the data. I imagine this would take the form of a wrapper class for synthesis closures and their control parameters. Presumably the constructor would take the closure and a list describing its control parameters and their preferred graphical representation. RJK ------------------------------ Date: Wed, 02 Dec 1998 19:21:54 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: comments on GUIUtils (Ronald Kuivila wrote:) >What I was imagining was to use sched to have polling at a slower rate. >I ran the simple sine wave included in the example parameter window and it >was taking 25% of the cpu...that seems like a lot for frequency amplitude >and pan. Sort of a common problem. Had to build a variable-rate poller for continuously polling and displaying an over 20 control-channel MIDI device on SC1. It saved a lot of power. Although .kr may be as cheap as James says, there will still be uses for variable rate polling for other uses like kind of "massively parallel systems" - any system with really many interconnected control threads. Wonder if there is someone willing to bid for the task. Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 ------------------------------ Date: Wed, 2 Dec 1998 16:12:40 -0500 (EST) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: comments on GUIUtils / new version is on the way > >3. I am noticing a problem with 'orphaned' synthesis code loading down the > >system. Any easy fix? > > Do you mean fragments of code left there for > no purpose? If so please point them out so I can > remove them. So far I am aware only of working > code or examples. The library should compile > without problems. What happens is that CPU performance gets bogged down and I have to restart SC to get rid of load. I am assuming that this is due to synthesis code conitnuing to execute, but that could be naive on my part. > >4. On my 8500, I notice a pretty severe performance penalty with lots of > >sliders. My impression is krate (ca. 1 kHz) is too fast for input > >polling (100 - 200 Hz would suffice). Would it be possible to introduce > >an "event rate" for i/o devices? For example, would it be possible to > >have a synth task evaluate a tree of unit generators? > > The new version of GUIUtils introduces LabeledArrayV > as a subclass of ArrayV which allows you to add a > auto-sizing text label to each NumericalView. This sounds like exactly what I need - I'll look forward to seeing the code. > >5. How about a ControlView that implements an OpCode-style "numerical" > >(i.e., a number box where clicking and dragging changes value). > > As far as I know this is exactly the case with NumericalView. > Works perfect. Can You describe any difference to OpCode-Style > or any problems? This was a newbie faux pas on my part, I had not noticed the NumericalView... > > Another example is the case of controlling many channels of the same > >underlying synthesis algorithm. It would be nice to be able to have a > >single GUI window with a list of synthesis instantiations attached as an > >alternative to a separate window for each instantiation. > > Am working on connecting a bundle of synth-algorithms to > a common control source dynamically. I think SoundModel > can be the starting point for this. (This is NOT for the > next release, possibly for the one after that). > I am not sure what you mean with " > >list of synthesis instantiations attached as an > >alternative to a separate window for each instantiation." > Do you mean: a window with a list of algorithms, > each of which may be started separately, and is > controlled by the controls of a single GUI window? By a "synthesis instantiation" I mean an executing block of synthesis code and its local variables. The dream is that ParameterWindow would have a "run another copy" button which would would allow arbitrarily many copies of the synthesis code to execute, each with their own distinct control parameters. Then a "select instance" button would move you from instance to instance. Selecting a particular instance would cause the ParameterWindow's sliders to be updated with the current state of that instance. The list of presets would probably exist as class variables of whatever class encapsulates the synthesis code and its control parameters. RJK ------------------------------ Date: Thu, 03 Dec 1998 08:46:22 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: comments on GUIUtils / new version is on the way Ron wrote: > >What happens is that CPU performance gets bogged down and I have to >restart SC to get rid of load. I am assuming that this is due to >synthesis code conitnuing to execute, but that could be naive on my part. You can see how many UGens (i.e. continuously evaluated processes) are running at the upper right part of the SC performance display bar. When you switch sounds of regularly, by checking the corresponding RUN box off, then the UGen count should be 1. If you close a window while synthesis is running, it will continue running. Closing a window will not automatically stop the synthesis. Other than that, the code works consistently. >By a "synthesis instantiation" I mean an executing block of >synthesis code and its local variables. >The dream is that ParameterWindow would have a "run >another copy" button which would would allow arbitrarily many copies of >the synthesis code to execute, each with their own distinct control >parameters. Then a "select instance" button would move you from instance >to instance. Selecting a particular instance would cause the >ParameterWindow's sliders to be updated with the current state of that >instance. > >The list of presets would probably exist as class variables of whatever >class encapsulates the synthesis code and its control parameters. Interesting suggestions, will consider. Thanks. Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 ------------------------------ Date: Thu, 03 Dec 1998 08:57:46 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: Questions Mikael Laurson wrote: > >I am planning to buy in the near future a sound card (currently I am using >only the Mac >DA-converters with SC2). >What is the best choice? Is it Sonorus Studio + DA/24 converters? >Will SC2 be able play 24 bits? I am using the Korg 1212 also (like James) as of late. Some hints: The series ships with jitter because of an "unclean word clock" which causes incompatibilities with many ADAT ADDA converters. CreamWare A8, A16 is one, Apogee have told me they do not support Korg 1212 either. Korg will perform a jitter correction modification for free, but I found it does not solve the problem. Probably best to use a regular ADAT by Alesis, like some here have reported. I have noticed "klirr" or other distortion when using the built-in DAC of the Korg with a sampling rate of 48 K, with sound frequencies above 14K. Use 41 K sampling rate. Other than that, Korg 1212 is very easy to set up and use, and thus recommendable. Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 ------------------------------ Date: Thu, 03 Dec 1998 10:32:09 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: Questions Michael, I have given a look at your code and find some problems, which I will look at again. In the meanwhile, I think it would help the design if you gave a clearer description of which parameters you are trying to change, and how. You say: > >The difference is, however, that I should be able to send continuos-control >information >after the excitation to the strings, such as vibrato, change the >feedback-scaler, >change the low-pass filter cut-off frequency, etc. > >It is not clear to me what is the best way to achieve this in the current >system. I suggest a) give a clear (block diagram or pseudocode equivalent) schematic description of - - the algorithms main blocks - - parameters going into each block, - - The connections of each block b) Describe which parameters you wish to control with continuous signals and how (which parameter ranges, oscillator or mouse or both ...) Suggest doing this with one example at least. Till next, Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 > >Below is one test which basically works. This is of course a greatly >simplified version of >what I try to achieve (I use here only a SinOsc oscillator instead of a >delay-line). >My point is here only to find an efficient way to trigger events that use >the poll and set methods. > >I create a global SinOsc whose frequency is controlled by an envelope using >the pollfn. >Events are triggered every 2 seconds: > >(var output, tspawn, sig, env, fund, fr, fenv, ae, pe, frref; > var ctrlrate, dur, pollfn, nofnotes, dtime, attacktime; > ctrlrate = 0.01; > dur = 1.5; > dtime = 2; > nofnotes = 5; > attacktime = 0.01; >{ arg synth; > fund = 440; > frref = Ref.new(fund); > fr = ControlIn.kr (frref); > sig = SinOsc.ar(fr.value,0,0.3); > ae = Env.new([0,1,1,0],[attacktime,0.8,0.1],'linear'); > pe = Env.new([fund,fund+100,fund],[0.5,0.5],'linear'); > pollfn = {TSpawn.ar({ arg argTSpawn, j, synth2, frenv; > set(frref, poll(frenv)); > sig > }, 1, nil, 0)}; > Spawn.ar({arg spawn, i, synth2; > env = EnvGen.kr(ae,1,0,1,0, dur); > fenv = EnvGen.kr(pe,1,0,1,0, dur); > output = value(pollfn); > tspawn = output.source; > synth2.repeatN(0, ctrlrate, floor(dur/ctrlrate), { >tspawn.trigger(fenv) }); > env*sig; > }, 1, dtime,nofnotes); >}.play; >) > >Although this example works there are several problems. Firstly, this >scheme seems to be slow >(this depends very much on the ctrlrate value). >Secondly, there is a strange side effect: if I change the attacktime >parameter to >smaller values, say 0.001, the sine-wave is heavily distorted. >Finally this scheme seems to be quite complex. >Is there a simpler way to achieve the same result? > >Here is another try (but with the same problems than the previous one): > >(var sig, env, fund, fr, fenv, ae, pe, frref; > var ctrlrate, dur, pollfn, nofnotes, dtime, attacktime; > ctrlrate = 0.01; > dur = 1.5; > dtime = 2; > nofnotes = 5; > attacktime = 0.01; >{fund = 440; > frref = Ref.new(fund); > fr = ControlIn.kr (frref); > sig = SinOsc.ar(fr.value,0,0.3); > ae = Env.new([0,1,1,0],[attacktime,0.8,0.1],'linear'); > pe = Env.new([fund,fund+100,fund],[0.5,0.5],'linear'); > Spawn.ar({arg spawn, i, synth; > env = EnvGen.kr(ae,1,0,1,0, dur); > fenv = EnvGen.kr(pe,1,0,1,0, dur); > Spawn.ar({ > set(frref, poll(fenv)); > sig > }, 1, ctrlrate, floor(dur/ctrlrate)); > sig*env > }, 1, dtime,nofnotes); > >}.play; >) > >Mikael > >================================ >Mikael Laurson > >Hollantilaisentie 1 A 2 >00300 Helsinki 33 >Finland > > >E-mail: laurson@siba.fi >================================ > > > ------------------------------ Date: Thu, 3 Dec 1998 20:41:50 +1100 From: ggerrard <---@---.---> Subject: Re: Questions - Creamware Pulsar I am also using a Korg 1212 and am impressed. But I am also interested in the Creamware Pulsar. Will SC be supporting it when the Mac version is out? ------------------------------ Date: Thu, 3 Dec 1998 08:28:45 -0600 From: James McCartney <---@---.---> Subject: Re: Questions - Creamware Pulsar At 3:41 AM -0600 12/3/98, ggerrard wrote: >I am also using a Korg 1212 and am impressed. >But I am also interested in the Creamware Pulsar. >Will SC be supporting it when the Mac version is out? I beleive ASIO supports that, so if Steinberg ever lets me get ASIO then SC will through ASIO. Currently they tell me they are "reviewing" my case.. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ End of sc-users-digest V1 #18 *****************************