From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #4 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, July 27 1998 Volume 01 : Number 004 ---------------------------------------------------------------------- Date: Thu, 23 Jul 1998 11:18:31 +0200 From: Ioannis Zannos <---@---.---> Subject: SC Memory partition (was: Re: Spawn example bugs) At 1:31 PM -0700 22.7.1998, James McCartney wrote: >At Wed Jul 22 12:30:45 1998, Ioannis Zannos wrote: > >I can't reproduce these. Have you tried increasing your RAM partition? >How much CPU usage are you getting? > You were right about SC getting out of memory. Recommended size is 7096 KB. I increased it to 15000 KB, and still got a reading of *only!* ca 1466 KB free with nothing but the standard stuff loaded. Of course its good SC can still work with a "small" memory partition, but people should be warned... Best, Iannis - --------------------------- Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Thu, 23 Jul 1998 16:37:50 +0200 From: Ioannis Zannos <---@---.---> Subject: Sorry, 1 unnecessary question. Apologies for the dumb question! ... Just found the answer in the help files: >At 1:31 PM -0700 22.7.1998, James McCartney wrote: >>At Wed Jul 22 12:30:45 1998, Ioannis Zannos wrote: > ><..... snip ... > >> > >What about something like: > numbox.value = mousex.value; >or > sp.nexttime = 0.2; > >Why not use the "regular" setter methods like > numbox.value_(mousex.value); > >Is there a difference? > The help file says obj.var = val and obj.var_(val) are equivalent. I.Z. ------------------------------ Date: Thu, 23 Jul 1998 19:36:25 +0200 From: Ioannis Zannos <---@---.---> Subject: Integrating duration based and condition based timing (scheduling, triggering) At 9:46 AM -0700 22.7.1998, James McCartney wrote: > >Scheduling can be done in several ways. You can use the Spawn >event function. You can use a Synth task (not yet documented, >but the "z analog variant" example uses one). You can execute >a block in the Sequencer object upon receiving a trigger from >something like a ControlIn which can be linked to a GUI item or >MIDI key. There will also be ways of starting an event in a Spawn >externally, but that is not done yet. The situation still seems a little unsatisfactory and complex to me. Spawn is already a fine thing and so is Sync, but I think there is still room for improvements here. While still studying it, here is an idea for a new class related to timing and triggering of events that may help simplify coding in this domain: The occurence of an event e in an interactive system may be dependent on two different things: a) Time offset from a previous event: Event e starts (happens) when a time interval d has elapsed from a previous event e0. b) A condition that is a function of the internal state of the system and / or external input: Event e starts when condition c becomes true, where c is a block (closure) returning a boolean. c will have to be evaluated continuously until it becomes true. It may be evaluated at audio rate (as some triggers/gates are), at control rate, or at a freely defined rate, if necessary. Therefore lets consider a class named "When" or alternatively "TimeP" (for time point) that can do both types of event triggering above, depending on the type of its arguments. The syntax for usage within a Synth or Spawn would be: When.ar( t, e, repeats = 1, rate ="kr" ); Arguments: t is the time interval or condition determining when e is to be evaluated (started). It is either one of: - - a simple number - indicating the time interval in seconds to wait before evaluating (starting) e. - - a block - indicating a condition to be repeatedly evaluated until it becomes true. e is the event to be started (evaluated) at time point t. It should be a function returning either a unit generator graph of the type required for Spawn and synth, or nil. repeats is for executing the When time-point repeatedly. If repeats = 1, then e is executed only once, after which When ends. If repeats > 1, then e is executed repeats time, after which When ends. If repeats = 0, then e is executed for ever, When never ends. An additional idea: If 0 < repeats < 1, then e is evaluated only repeats.coin of the time it should actually happen. (like the kind of random condition n.coin.if(playsomething, nil) known from Spawn examples). rate indicates the rate at wich the condition t is to be checked (applicable only when t is a condition, alternatively it could be some kind of time base when t is a duration number). rate = "ar" poll at audio rate (for signals) rate = "kr" poll at control rate (for gui items, mouse etc.) rate = SomeTypeOfMidiSpec: Evaluate t only when the type of MIDI message specified is input. This need not be described further here - it can be designed by analogy to SC1 and SC2 practices. rate = a number. The rate for polling t, in seconds. For expensive computations like evaluating a neural network or checking a rule system one may choose rates as slow as 0.1-1 seconds. When would return either a UGen graph appropriate for Spawn/Synth or nil, for skipping one execution cycle in Spawn. A scheme for passing the value of t, the execution count, and the When instance itself to e at evaluation time, and for setting t to new values for t from within e could be devised. But this won't be elaborated here. One could probably design When with the means available to SC2.22d now. Then one can put an array of Whens inside Mix and thus start many sounds, polling processes etc. at once (in Synth). If the above also motivates some low-level, efficient implementations of certain types of the pollings or scheduling above, it might be useful. I hope its also useful as an idea in the ongoing work on triggering from GUI or other external sources. Regards Iannis ================================================= PS. James - I am not sure whether you want such longish messages to go straight to the list. Please indicate if you wish messages to the mailing list to be limited to a small size in the future ... Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Thu, 23 Jul 1998 10:41:53 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: SC Memory partition (was: Re: Spawn example bugs) At Thu Jul 23 11:18:31 1998, Ioannis Zannos wrote: >At 1:31 PM -0700 22.7.1998, James McCartney wrote: >>At Wed Jul 22 12:30:45 1998, Ioannis Zannos wrote: >> >>I can't reproduce these. Have you tried increasing your RAM partition? >>How much CPU usage are you getting? >> > >You were right about SC getting out of memory. Recommended >size is 7096 KB. I increased it to 15000 KB, and still >got a reading of *only!* ca 1466 KB free with nothing >but the standard stuff loaded. Of course its good >SC can still work with a "small" memory partition, but >people should be warned... This is an artifact of whatever you are using to determine the free memory. SC2 allocates nearly all the memory you give it so that it can do its own memory management such as allocating large buffers at interrupt level. Therefore even though it looks like there is not much free memory, it is actually allocated from MacOS but sitting on a free list in SC2. ------------------------------ Date: Thu, 23 Jul 1998 10:46:04 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: Scheduling with spawn [Also polling the mouse ... et al.] At Thu Jul 23 10:56:59 1998, Ioannis Zannos wrote: >it seems more appropriate to use ControlIn in conjunction with trigger >right? Only if you want to retrigger an ongoing process rather than spawn new ones. >I still wonder what load is involved in the extra >UGen created by Spawn, and what Pause has to do with this >when running many Spawns in parallel. Pause is used to pause an ongoing process rather than spawn new ones. I will try to give a couple more examples later. ------------------------------ Date: Thu, 23 Jul 1998 21:09:54 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: Integrating duration based and condition based timing (scheduling, triggering) At Thu Jul 23 19:36:25 1998, Ioannis Zannos wrote: >The situation still seems a little unsatisfactory and complex >to me. Spawn is already a fine thing and so is Sync, but >I think there is still room for improvements here. I think what is needed is a TSpawn that spawns on triggers. Then on top of that basic block other things could be built just as XFadeTexture, OverlapTexture, OrcScore, Cycle, SelectEvent, etc are all written on top of Spawn in SC code. None of those need have been written by me. You are free to write your own classes like those. It is very expensive to evaluate a condition written as SC code at control rate and prohibitively so at audio rate. The efficient thing to do is write a ugen graph that will cause a trigger upon a condition. Then TSpawn could spawn an event upon each trigger. With Sequencer, ImpulseSequencer, ToggleFF, SetResetFF, PulseCount, PulseDivide, <, >, et al, it is possible to write just about anything you might need. Exceptional cases are invited. Your When class is trying to do too many things in the same class, IMO. I would make a couple of different classes out of it. >PS. James - I am not sure whether you want such longish >messages to go straight to the list. Please indicate if you >wish messages to the mailing list to be limited to >a small size in the future ... fine w/ me.. ------------------------------ Date: Fri, 24 Jul 1998 11:43:49 +0200 From: Staffan Liljegren <---@---.---> Subject: SC2 ControlIns in taps ? This is a multi-part message in MIME format. - --------------CAA0DDF2488E1392905C65B0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit (I know this has been talked about before but I lost those messages...) I tried to set up a GUI for one of my instruments, where one slider to control tap delay, ie w = ... SliderView.new( w, Rect.new( 106, 76, 371, 99 ), "jet size", 0.5, 0.1, 0.5, 0.05, 'exponential'); .... buf = Signal.new(Synth.sampleRate*0.4); del = TapL.ar(buf, ControlIn.kr(w.at(0))); Which doesn't work .What is the correct thing to do here ? - -Staffan Liljegren - --------------CAA0DDF2488E1392905C65B0 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Staffan Liljegren Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Staffan Liljegren n: Liljegren;Staffan org: Ericsson email;internet: staffan@medialab.ericsson.se title: Research Manager, Ericsson Media Lab tel;work: +46 8 719 5984 tel;fax: +46 8 7195311 x-mozilla-cpt: ;1 x-mozilla-html: FALSE version: 2.1 end: vcard - --------------CAA0DDF2488E1392905C65B0-- ------------------------------ Date: Fri, 24 Jul 1998 18:54:10 +0200 From: laurson@siba.fi (Mikael Laurson) Subject: sound-files I have some questions concerning sound-files in SC2. I tested the write method of Synth using the following code: Synth.write(SinOsc.ar (440,0,0.1), 0.2,"HD:test", 'AIFF') I am able to open the sound-file and play it in SC2. The problem starts when I try to open the sound-file with another application (Alchemy, SoundApp, etc.) They don't recognise nor accept it. How can I create AIFF files (or SD files) that are recognised by other applications? (I looked with ResEdit the Info for the sound-file created by SC2 and I noticed that the type field was "????" and not "AIFF", also the file did not have a resource fork.) Will SC2 support playing of large (multichannel) sound-files that will not fit into the RAM? Still another question: Does (or will) SC2 include the "Awcoscil" module of SC1? Mikael ================================ Mikael Laurson Hollantilaisentie 1 A 2 00300 Helsinki 33 Finland E-mail: laurson@siba.fi ================================ ------------------------------ Date: Fri, 24 Jul 1998 18:22:08 +0200 From: Ioannis Zannos <---@---.---> Subject: Re: Integrating duration based and condition based timing (scheduling, triggering) >At Thu Jul 23 19:36:25 1998, Ioannis Zannos wrote: > > >>The situation still seems a little unsatisfactory and complex >>to me. Spawn is already a fine thing and so is Sync, but >>I think there is still room for improvements here. > >I think what is needed is a TSpawn that spawns on triggers. >Then on top of that basic block other things could be built just >as XFadeTexture, OverlapTexture, OrcScore, Cycle, SelectEvent, etc >are all written on top of Spawn in SC code. None of those need have been >written by me. You are free to write your own classes like those. > >It is very expensive to evaluate a condition written as SC code at control >rate and prohibitively so at audio rate. The efficient thing to do >is write a ugen graph that will cause a trigger upon a condition. Then TSpawn >could spawn an event upon each trigger. With Sequencer, ImpulseSequencer, >ToggleFF, SetResetFF, PulseCount, PulseDivide, <, >, et al, it is >possible to write just about anything you might need. Exceptional cases >are invited. > >Your When class is trying to do too many things in the same class, IMO. >I would make a couple of different classes out of it. > > >>PS. James - I am not sure whether you want such longish >>messages to go straight to the list. Please indicate if you >>wish messages to the mailing list to be limited to >>a small size in the future ... > >fine w/ me.. I will post you a detailed answer to audiosynth now, which you can forward to the list if you wish. You may be right about the functionality of when being too broad. But its the principle that I am concerned about. We can sort out details later, and experience will certainly show more modifications. Hope this will lead to something... Best, Iannis Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Fri, 24 Jul 1998 18:46:10 +0200 From: Ioannis Zannos <---@---.---> Subject: Re: sound-files At 6:54 PM +0200 24.7.1998, Mikael Laurson wrote: >I have some questions concerning sound-files in SC2. > >I am able to open the sound-file and play it in SC2. >The problem starts when I try to open the sound-file with >another application (Alchemy, SoundApp, etc.) They don't recognise >nor accept it. >How can I create AIFF files (or SD files) that are recognised by >other applications? >(I looked with ResEdit the Info for the sound-file created by SC2 >and I noticed that the type field was "????" and not "AIFF", also >the file did not have a resource fork.) Perhaps use of one of many freeware mac file-type changin utilities will help. I have been using things like: Drop*Attribute 3.0.0 (Fat) from: SouthSide Software (SouthSide@kagi.com) ©1994-1996 by Bob Bradley, All Rights Reserved. This application is $10 shareware. Also have a look at http://www.msoft.it/sniffer/softwareinglese.html (my favorite utility link site for the mac) or: http://hyperarchive.lcs.mit.edu/HyperArchive/HyperArchive.html or: http://www.pht.com/info-mac/ With the said utilities, it is usually very easy to give any file any attribute from a given application by opening a file from the target application. Iannis ====================================================== Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Fri, 24 Jul 1998 18:52:10 +0200 From: Ioannis Zannos <---@---.---> Subject: Re: Integrating duration based and condition based timing (scheduling, triggering) At 9:09 PM -0700 23.7.1998, James McCartney wrote: >At Thu Jul 23 19:36:25 1998, Ioannis Zannos wrote: > >I think what is needed is a TSpawn that spawns on triggers. >Then on top of that basic block other things could be built just >as XFadeTexture, OverlapTexture, OrcScore, Cycle, SelectEvent, etc >are all written on top of Spawn in SC code. None of those need have been >written by me. You are free to write your own classes like those. OK. I will have a go at it... >It is very expensive to evaluate a condition written as SC code at control >rate and prohibitively so at audio rate. The efficient thing to do >is write a ugen graph that will cause a trigger upon a condition. Then TSpawn >could spawn an event upon each trigger. With Sequencer, ImpulseSequencer, >ToggleFF, SetResetFF, PulseCount, PulseDivide, <, >, et al, it is >possible to write just about anything you might need. Exceptional cases >are invited. This is what I do not understand. I have started studying the above. I do not understand how Pause stops / restarts processes, Furthermore, you say: >The efficient thing to do >is write a ugen graph that will cause a trigger upon a condition. But won't I have to evaluate the condition within the trigger, or for a trigger anyway? Do you mean the trigger ugens provided with SC2 like Trigger, Trigger2 or the trigger concept? Moreover, SC2 trigger ugens are .ar type, so I dont even know how to do the condition checking at kr !!!. Perhaps just one simple example from you would help to get things straight and to get started. Say an example about triggering an event whenever the value of a slider is smaller than 0.5 (?)... >Your When class is trying to do too many things in the same class, IMO. >I would make a couple of different classes out of it. As I said, experience, usage will show. I will have to start with some basics anyway, and then extend as needed... - ------------------ Here a suggestion about Spawn.ar though on which I would like your opinion or the opinion of other users: The order of arguments in Spawn.ar may be better: Spawn.ar(newEventFunc, nextTime, numChannels...) rather than: Spawn.ar(newEventFunc, numChannels, nextTime, ...) It depends whether time structure or channel / spatial structure is the aspect more often used in designing sound. I tend to care first about time structure, then about mixing/panning - but it may be only a personal preference... ? One may even shift numChannels further back: Spawn.ar(newEventFunc, nextTime, maxRepeats, numChannels, ...) I find that at this stage I am hardly using numChannels, and I do not expect to be using it excessively in the future either. Cheers, Iannis - -------------------------------------- Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Fri, 24 Jul 1998 18:54:04 +0200 From: Ioannis Zannos <---@---.---> Subject: Moving scope windows around I need to move window of a signal view to another position. This is because I want to open a signal scope and an fft scope at the same time, next to each other on the monitor screen. GUI windows can generally be moved around as for example: var w; w = GUIWindow.new("test", Rect.newBy(100, 100, 300, 200)); w.bounds_(w.bounds.moveTo(400, 200)); But I tried: scope = Scope.window("FFT", fftsize, fft.magnitudeApx); scope.view.bounds_(scope.view.bounds.moveTo(500,100)); and it does not work. How does one move a scope window to a desired position? Note that resising the FFT window and also zooming or displacement of the display axis is a feature that would come in very handy for extensive use with fft-scope... Iannis ====================================================== Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Fri, 24 Jul 1998 18:57:16 +0200 From: Ioannis Zannos <---@---.---> Subject: When statement... Hello, Since I mentioned it, here is the idea about When reviewed, for what its worth. I will do part of it for sure, any ideas welcome: 1. One could introduce When as a Control Structure operator (like If, While, For ...). This in my opinion would mean an extension of the control structure concept duly reflecting the temporal aspects of musical programming ... - -- Syntax: When (expression, action, repeat = 1, rate = "kr"); - -- Description: evaluate expression at kr / ar / self defined rate, depending on rate argument, until it becomes true. When expression becomes true, evaluate event. Repeat evaluation of the whole structure times. If is 0 evaluate for ever. [ option? If 0 < repeat < 1 then evaluate action only if repeat.coin *also* turns out true ... , and keep repeating When ... ] - -- Possible further feature: "normal" time-offset scheduling: Strictly time-offset based scheduling of events can be very easily integrated in this structure by introducing a message for SimpleNumbers that is understood as an expression to be used as time offset by When: When (aSimpleNumber.time, action, repeat = 1, rate = "kr"); means evaluate action after aSimpleNumber seconds. Also one could even extend this to complex numbers in two thinkable ways: The imaginary part means a random time jitter to be added to the real part (possibly previously scaled to avoid negative time offset). This together with the option of letting fractional repeat numbers mean if (repeat.coin, action), may ease the coding of random deviations... I am aware that this reintroduces the [offset, func].sched; kind of construct, but I think it is worthwhile considering the above idea in the context of Control Structures, and to my knowledge it should be possible to implement if ones sticks to the present scheme of spawning events within a sync. The above should be compatible to Spawn.ar by always returning a UGenGraph or nil as action... - -- Usage, discussion (GUI, MIDI, Keyboard ...): To connect to a gui item, say a number box nbox1, one would go: When (ControlIn.kr(nbox1) < 10.0, newEventFunc, ...) meaning execute newEventFunc when the value of nbox1 is smaller than 10.0. To further streamline the coding of this it may be desirable to have a ctlin method for gui items, reducing the above to: When (nbox1.ctlin < 10.0, newEventFunc, ...) (Note: I have not managed to get the value of buttons. I guess functionality is not yet implemented ... Would it be useful to make it compatible to the above idea - perhaps this is a new uniform and economical way for plugging in controls?) - -- Tcase: Multiple checks (kind of temporal "case" statement). Consideration: Even a checkbox has more than one values (0.0 or 1.0), so it is handy to introce a multiple condition checking When function - a kind of temporal version of LISPs "cond" or the case statement. Tcase ([[condition, action, break = true], [condition, action, ...], ... ], rate) This may be a good way to connect actions to many gui items, and to configure triggering by midi, computer keyboard or other devices. 2. Alternative implementation within the Spawn class: Implementing conditional functionality and time offset to start as new method or as extention of the existing ar method of Spawn: Spawn.ar(newEvent, timeoffset, ...) // note different arg order.... Spawn would check the type of the timeoffset arg and decide whether to time by duration offset or by condition checking. To indicate that spawning of the first event is to happen *after* timeoffset rather than *immediately*, one may use a different method name. Spawn.at(newEvent, timeoffset ....) Means: wait until timeoffset, then execute newEvent, and keep executing like Spawn.ar after that. Alternatively, one can indicate the disciction between .ar / .at modes as a keyword argument rather than with a different message. Iannis - --------------------------------------------- Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Fri, 24 Jul 1998 14:06:30 -0400 (EDT) From: David Crandall <---@---.---> Subject: Midi Mapping Faders in v2.0d22 When I Midi Map faders in the GUI box, the patch doesn't remember the mappings. Am I missing something, or is there a way to do this in code, or is the feature still to come in a later version? BTW, I'm using an MM-16 to send Midi Volume across the 16 channels. thanks, dc ------------------------------ Date: Fri, 24 Jul 1998 14:24:08 +0000 From: mary <---@---.---> Subject: Re: sound-files I have some questions concerning sound-files in SC2. I tested the write method of Synth using the following code: Synth.write(SinOsc.ar (440,0,0.1), 0.2,"HD:test", 'AIFF') I also have questions about the same that perhaps James can answer. I can't even get the code synth.write to work. Is there a more detailed help file? How are other people saving the audio output? Thanks, Mary ------------------------------ Date: Fri, 24 Jul 1998 17:59:17 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: Midi Mapping Faders in v2.0d22 At Fri Jul 24 14:06:30 1998, David Crandall wrote: >When I Midi Map faders in the GUI box, the patch doesn't remember the >mappings. Am I missing something, or is there a way to do this in code, >or is the feature still to come in a later version? BTW, I'm using an >MM-16 to send Midi Volume across the 16 channels. It doesn't rememeber mappings. You can setup the mappings in code. In View.sc there are some methods for ControlView called mapToController, mapToTouch, etc. So you can edit the generated code to say: SliderView.new(...).mapToController(1,7); What I should do is make the code generator generate this automatically. ------------------------------ Date: Fri, 24 Jul 1998 18:04:17 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: sound-files At Fri Jul 24 14:24:08 1998, mary wrote: >I have some questions concerning sound-files in SC2. > >I tested the write method of Synth using the following code: > >Synth.write(SinOsc.ar (440,0,0.1), 0.2,"HD:test", 'AIFF') > >I also have questions about the same that perhaps James can answer. I can't even >get the code synth.write to work. The above statement depends on your hard drive being called "HD". Is that the case? How about trying this instead: Synth.write(SinOsc.ar (440,0,0.1), 0.2, "test_2", 'AIFF'); ------------------------------ Date: Fri, 24 Jul 1998 23:09:59 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: When statement... There are a number of problems with this as presented that I do not have time to discuss. I would say to wait until the program is better documented and you read the docs and understand the constructs that are already provided before you try to propose new inconsistent things. Once a triggerable Spawn is implemented I think you will be able to build what you need and it will be consistent with the current architecture. very brief notes: ControlIn is already able to evaluate an arbitrary SC function at k rate. As I said before you REALLY do not want to evaluate a condition at audio rate. Write it as a ugen graph that triggers. Also repeat = nil (not zero) is what means repeat forever currently in Spawn. I don't like the overloading of 'coin' onto repeat. What if you want a repeat count AND coin. These are two separate things. ------------------------------ Date: Fri, 24 Jul 1998 23:09:56 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: Integrating duration based and condition based timing (scheduling, triggering) At Fri Jul 24 18:52:10 1998, Ioannis Zannos wrote: >This is what I do not understand. I have started >studying the above. I do not understand how Pause >stops / restarts processes, Furthermore, you say: Look at the Pause example file. Whenever the amplitude input to Pause is <= 0 then the function is paused. >>The efficient thing to do >>is write a ugen graph that will cause a trigger upon a condition. >But won't I have to evaluate the condition within the trigger, >or for a trigger anyway? Do you mean the trigger ugens provided >with SC2 like Trigger, Trigger2 or the trigger concept? What I mean is that you can write just about any condition as a ugen graph. A trigger is any transition from <= 0 to > 0. To trigger events we'd need a TSpawn object which I will make. For instance your example below: >Say an example about triggering an event whenever >the value of a slider is smaller than 0.5 (?)... Do you mean trigger once or trigger repeatedly when it falls below 0.5 ? myslider = window.at(0); // get your slider from window's views // trigger once trigger = myslider.kr < 0.5; // trigger repeatedly (use trigger = Impulse.ar(rate, myslider.kr < 0.5); >Moreover, SC2 trigger ugens are .ar type, so I dont even >know how to do the condition checking at kr !!!. No if you look at the classes most if not all the trigger classes let you make kr versions. > >Perhaps just one simple example from you would help to >get things straight and to get started. see above. triggering events will require a TSpawn object as I mentioned. >Here a suggestion about Spawn.ar though on which I would >like your opinion or the opinion of other users: > >The order of arguments in Spawn.ar may be better: > Spawn.ar(newEventFunc, nextTime, numChannels...) >rather than: > Spawn.ar(newEventFunc, numChannels, nextTime, ...) > >It depends whether time structure or channel / spatial >structure is the aspect more often used in designing >sound. I tend to care first about time structure, >then about mixing/panning - but it may be only >a personal preference... ? I use both equally. I like to spatialize early on as part of the instrument itself. >One may even shift numChannels further back: >Spawn.ar(newEventFunc, nextTime, maxRepeats, numChannels, ...) I disagree. At higher levels nextTime is usually set to nil anyway because Spawn takes the next time from the intrinsic logical duration of its sub events. And at those higher levels there are usually multiple channels because you are then time ordering entire sections of a piece. ------------------------------ Date: Mon, 27 Jul 1998 09:53:26 +0200 From: Ioannis Zannos <---@---.---> Subject: Re: When statement... At 11:09 PM -0700 24.7.1998, James McCartney wrote: >There are a number of problems with this as presented that I do not >have time to discuss. I would say to wait until the program is better >documented and you read the docs and understand the constructs that are already >provided before you try to propose new inconsistent things. >Once a triggerable Spawn is implemented I think you will be able to build >what you need and it will be consistent with the current architecture. Tspawn will be sufficient. Stand corrected about the When proposal being untimely. >very brief notes: > >ControlIn is already able to evaluate an arbitrary SC function at k rate. Do you mean something like: var condition; condition = { arg a b; a * 15 < b }; .... ControlIn.kr(condition) ... or : ... ControlIn.kr( { ....... } ) ......... >As I said before you REALLY do not want to evaluate a condition at audio rate. >Write it as a ugen graph that triggers. Aggreed - my text was unclear on this point. I do have a problem though after reading up on Triggers and Gates: I understand it that Trig, Trig1, Gate etc. output a continuous signal and so do Sequencer, ImpulseSequencer. Therefore how do I convert the becoming true of a condition to an event, i.e. how do I use a signal to trigger an event? Since ugen graphs are in principle things that output singals - not things that trigger events, your statement "write it as a ugen graph that triggers" above calls for more explanation. I have tried putting a spawn inside the condition part of a Sequencer statement, but the spawn will not be installed in the graph. Your Tspawn comes in at this point. Perhaps you will give examples of how to use Trig, Sequencer etc. in conjunction with Tspawn. >Also repeat = nil (not zero) is what means repeat forever currently in Spawn. Stand corrected. >I don't like the overloading of 'coin' onto repeat. What if you want a >repeat count AND coin. These are two separate things. Point taken. This is more neat and consistent. Best, Iannis - ----------------------------------------------------------- Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Mon, 27 Jul 1998 10:26:18 +0200 From: Ioannis Zannos <---@---.---> Subject: Re: Integrating duration based and condition based timing (scheduling, triggering) At 11:09 PM -0700 24.7.1998, James McCartney wrote: >At Fri Jul 24 18:52:10 1998, Ioannis Zannos wrote: > ... > >>But won't I have to evaluate the condition within the trigger, >>or for a trigger anyway? Do you mean the trigger ugens provided >>with SC2 like Trigger, Trigger2 or the trigger concept? > >What I mean is that you can write just about any condition as a ugen >graph. A trigger is any transition from <= 0 to > 0. >To trigger events we'd need a TSpawn object which I will make. TSpawn will be sufficient to build just about everything needed in conditional triggering of events. >For instance your example below: > >>Say an example about triggering an event whenever >>the value of a slider is smaller than 0.5 (?)... > >Do you mean trigger once or trigger repeatedly when it falls below 0.5 ? > >myslider = window.at(0); // get your slider from window's views > >// trigger once >trigger = myslider.kr < 0.5; I dont understand this, because I dont know how to use it to spawn an event. I expect it will be covered by TSpawn, so I will wait for that. >// trigger repeatedly (use >trigger = Impulse.ar(rate, myslider.kr < 0.5); I meant the previous case. >>Moreover, SC2 trigger ugens are .ar type, so I dont even >>know how to do the condition checking at kr !!!. > >No if you look at the classes most if not all the trigger classes let you >make kr versions. Yes, I found that out, but the help files only mention .ar so I was misled. However, given the vast number of classes it is understandable that documentation must be limited to the essentials. >>It depends whether time structure or channel / spatial >>structure is the aspect more often used in designing >>sound. I tend to care first about time structure, >>then about mixing/panning - but it may be only >>a personal preference... ? > >I use both equally. I like to spatialize early on as part of the >instrument itself. > >>One may even shift numChannels further back: >>Spawn.ar(newEventFunc, nextTime, maxRepeats, numChannels, ...) > >I disagree. At higher levels nextTime is usually set to nil anyway >because Spawn takes the next time from the intrinsic logical duration >of its sub events. And at those higher levels there are usually multiple >channels because you are then time ordering entire sections of a piece. Very interesting. I will have to explore this dimension more, and I think its good that SC is helping musicians to explore spatialisation and integrate it in their sound design. I.Z. Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Mon, 27 Jul 1998 11:08:01 +0200 From: Ioannis Zannos <---@---.---> Subject: binding generic Controllers to controlviews, external triggering James, some more suggestions / things I miss which I think are basic for interactive use of SC: A number of messages exist for binding control views to MIDI messages. What about binding control views to internal control output? Like the existing: ctlview.mapToController(...); One could make ctlview.mapToInternalController(...); which would take as input any ControlIn.kr() type thing. Also related: Voicer is triggered by MIDI note on events only. Could one make a voicer triggered by other types of events? Of course one might build something similar to voicer based on the expected TSpawn, but, I would suggest making an class that enables one to simulate MIDI events to SC itself. Would that be an easy way around and a first step to generalising internal/external control to SC? The synth task variable: Will it be able to address the synth instance from inside the task of the synth to start Tspawn events? How about multiple periodic tasks in different rates in one synth? These can come in very handy. In general, while the UGen concept in SC2 and the handling of envelopes, continuous controls, oscillators, filters and multichannel processing are extremely elegant, and clear, the triggering of events and the handling of non-audio (periodic/aperiodic) tasks as well as communication are not yet so clear to the user. I think if you provided in providing a similarly consistent concept for these latter aspects, SC would gain even further. Presently ControlIn and its associated classes address continuous signals. What is needed is an equally competent and consistent system for periodic and asynchronous events. (Hope this makes sense as I am still a bit unclear how these aspects work in the present version of SC2...) I assume that a computer keyboard controller / trigger is also in your to-do list. Perhaps event (i.e. non-continuous) triggers should be treated as subclasses of a single class. By the way, a question I keep hearing from interested parties: any prospects we may get MIDI output at some point, or does the timing problem remain under current OS conditions? Best regards, Iannis ================================================== Ioannis Zannos Staatliches Institut fuer Musikforschung Tiergartenstr. 1, D-10785 Berlin, Germany Tel: +49 30 25481140 Fax: +49 30 25481172 ------------------------------ Date: Mon, 27 Jul 1998 13:14:52 +0200 (MET DST) From: Hans Tutschku <---@---.---> Subject: computer keyboard Is there already a way to look for the computer keyboard - as in SC1 ? if asciiCode == 49 then ... end.if Hans ------------------------------ Date: Mon, 27 Jul 98 18:58:41 +0100 From: Cohen Veliscek <---@---.---> Subject: Re: computer keyboard remove ------------------------------ Date: Mon, 27 Jul 1998 10:08:42 -0700 (PDT) From: James McCartney <---@---.---> Subject: Re: When statement... At Mon Jul 27 09:53:26 1998, Ioannis Zannos wrote: >and so do Sequencer, ImpulseSequencer. Therefore how do I convert >the becoming true of a condition to an event, i.e. how do I >use a signal to trigger an event? TSpawn. Which I just wrote yesterday :-) >graph. Your Tspawn comes in at this point. Perhaps you will >give examples of how to use Trig, Sequencer etc. in conjunction >with Tspawn. yup. ------------------------------ End of sc-users-digest V1 #4 ****************************