From: owner-sc-users-digest@lists.io.com (sc-users-digest)
To: sc-users-digest@lists.io.com
Subject: sc-users-digest V1 #308
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 Friday, June 22 2001 Volume 01 : Number 308
----------------------------------------------------------------------
Date: Thu, 21 Jun 2001 09:06:09 +0000
From: Jem Finer <---@---.--->
Subject: patching/connecting windows . . .
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
- --MS_Mac_OE_3075959274_1036337_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Hello,
It occured to me that there may be a very simple way of patching one
instrument into another - my "system" is to put instruments in the Library
via Main.sc - so they're all there when SC compiles.
Then I can use the lib menu and the Mixer gui to get lots of things running
in parallel. Of course what would be wonderful would be to be able to patch
one of these processes into another. I used to "do it" by sending the output
of each lib item to a delay buffer and having each item be able to choose
whether to read from the buffer. This was on the basis of an idea of Martin
Robinsons which I may have got a bit wrong - it worked but seemed to
sometimes lock up the machine - so in fact it NEARLY worked rather than
worked).
I'm hoping the SModule class in SC3 (or something else) will make inter
instrument patching via GUI a simple and every day task but in the meantime
. . .
Maybe the crucial lib does it but I couldn't see where/how - Crucial ?
I've added a button in the makeEditWindow method of MixerVoice
ButtonView.new(editWindow, Rect.newBy( 400, top, 100, 20 ),'patch',
0,0,1, 1).action_({another
instrument});
so now all edit windows have this button - I hoped that I could then call up
another instrument via the button action
eg
Library.at(['RLPF']).value(out)
which would start up a filter and pass the out put of the "mother" patch as
the input to the filter .
It nearly works ! the problem/stumbling block is passing the output - that
doesn't work.
I imagine .value is wrong - is this a possibility as a simple patching
method ?
Jem
- --MS_Mac_OE_3075959274_1036337_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable
patching/connecting windows . . .
Hello,
It occured to me that there may be a very simple way of patching one instru=
ment into another - my "system" is to put instruments in the Libra=
ry via Main.sc - so they're all there when SC compiles.
Then I can use the lib menu and the Mixer gui to get lots of things running=
in parallel. Of course what would be wonderful would be to be able to patch=
one of these processes into another. I used to "do it" by sending=
the output of each lib item to a delay buffer and having each item be able =
to choose whether to read from the buffer. This was on the basis of an idea =
of Martin Robinsons which I may have got a bit wrong - it worked but seemed =
to sometimes lock up the machine - so in fact it NEARLY worked rather than w=
orked).
I'm hoping the SModule class in SC3 (or something else) will make inter ins=
trument patching via GUI a simple and every day task but in the meantime &nb=
sp;. . .
Maybe the crucial lib does it but I couldn't see where/how - Crucial ?
I've added a button in the makeEditWindow method of MixerVoice
ButtonView.new(editWindow, Rect.newBy( 400, top, 100, 20 ),'patch',
&n=
bsp; =
&nbs=
p; 0,0,1, 1).action_({another instrument}=
);
so now all edit windows have this button - I hoped that I could then call u=
p another instrument via the button action
eg
Library.at(['RLPF']).value(out)
which would start up a filter and pass the out put of the "mother"=
; patch as the input to the filter .
It nearly works ! the problem/stumbling block is passing the output - that =
doesn't work.
I imagine .value is wrong - is this a possibility as a simple patchin=
g method ?
Jem =
;
- --MS_Mac_OE_3075959274_1036337_MIME_Part--
------------------------------
Date: Thu, 21 Jun 2001 12:06:33 +0200
From: Julian Rohrhuber <---@---.--->
Subject: Re: connecting windows
to add yet another point to this discussion, looking towards SC3:
Maybe it would be feasible to introduce a class analog to Pen, say
GUI, or similar, to create different gui representations of Objects.
So the proposed class would decide if a ControlValue is accessed by a
Slider or whatever interface.
This would avoid the inflexibility of a specific "GUIification".
So in addition to .draw an Object would understand .gui (as proposed by felix),
and would take a GUI constructor object as argument (similar to Ron's Control).
I think Pen is a very interesting model, as it can be nested, so GUI
could be nested, too.
x = View.new;
ControlValue.gui(GUI( control:\slider, view: x)); //would create a
slider for each entry
or even:
#{
{
a = SinOsc.ar(100, 0, 0.1);
a.gui(GUI( control:\slider )); //would create a
slider for each input of a
a
}.play;
}.send;
this is just a sketch of a idea.
One aspect I'd like to point at is that it is not necessarily practical to
have one graphic element represent each Object. This makes it hard to
navigate data
with a GUI. Often it is nicer to browse data.
------------------------------
Date: Thu, 21 Jun 2001 07:40:57 -0500
From: James McCartney <---@---.--->
Subject: Re: patching/connecting windows . . .
I'm working on something that will make patching very flexible.
I'll say more when it is done.
- --- james mccartney james@audiosynth.com
SuperCollider - a real time synthesis programming language for the PowerMac.
------------------------------
Date: Thu, 21 Jun 2001 13:56:25 +0100
From: Andy Wilson <---@---.--->
Subject: sc book
are there any plans out there to properly document sc?
in my dreams Isee a huge o'reilly book that takes me from rudimentary to
advanced sc programming while also teaching me the concepts of computer
music a la curtis roads. there is a cd attached to the book with hundreds of
example files, plugins, etc.........
am I the only person who thinks that the lack of such documentation is the
major reason sc is not used more widely?
- --
{ andy wilson << managing director << LShift << www.lshift.net }
{ www.andyw.com && www.faust-pages.com && www.directorxml.com }
------------------------------
Date: Thu, 21 Jun 2001 08:20:37 -0500
From: James McCartney <---@---.--->
Subject: Re: sc book
on 6/21/01 7:56 AM, Andy Wilson at andy@lshift.net wrote:
> are there any plans out there to properly document sc?
>
> in my dreams Isee a huge o'reilly book that takes me from rudimentary to
> advanced sc programming while also teaching me the concepts of computer
> music a la curtis roads. there is a cd attached to the book with hundreds of
> example files, plugins, etc.........
>
> am I the only person who thinks that the lack of such documentation is the
> major reason sc is not used more widely?
Yes, but right now it is still a moving target.
I think the next version will have more longevity as far as stability of
features.
- --- james mccartney james@audiosynth.com
SuperCollider - a real time synthesis programming language for the PowerMac.
------------------------------
Date: Thu, 21 Jun 2001 09:55:45 -0500
From: "David Cottle" <---@---.--->
Subject: Re: straight me up
Hi,
> David Cottle's book has been very helpful so far it cleared a lot of
I'm doing heavy revisions to the Digital Synthesis w SC. (The first draft
was written after only a few months with SC.) Please download it in about
two weeks. I give a better explanation of how to use mul and add in modules.
- --
><><><><><><><><><><><>
David Cottle, computer music, contra, cottle@cerlsoundgroup.org
"My next piece, which I have not yet learned to like." ‹ Herbert Brün
------------------------------
Date: Thu, 21 Jun 2001 14:49:51 -0400
From: "crucial" <---@---.--->
Subject: caught the wrap bug ?
// this kind of makes sense to me
4.wrap(0,4)
4
4.wrap(0.0,4.0)
4
4.0.wrap(0.0,4.0)
0
4.0.wrap(0,4)
0
// this doesn't
- -3.wrap(0,4)
2
- -3.wrap(0.0,4.0)
- -3
- -3.0.wrap(0.0,4.0)
1
- -3.0.wrap(0,4)
1
ie. negative integers wrap incorrectly
the solution for me was to convert the int to a float
before wrapping.
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Thu, 21 Jun 2001 15:08:55 -0400
From: "crucial" <---@---.--->
Subject: Re: connecting windows
> also spracht chris clepper :
>as for the following diagrams: we're on the same page i think.
>although i want to do the patching on the fly via the SC3 method of
>compiling while the synth engine is running. that's what i've always
>wanted from a synthesis environment.
ron kuivila's SC/Node class (look on the sc swiki) was i believe the original inspiration
for the SC3 module.
it works in sc2.
i am considering an adaption of it and james' approach.
actually wouldn't take that long.
then you could execute multiple
{
}.play
in sc2 just like in sc3.
i mainly want it so that i can get rid of transport and make Player class as simple as
possible.
but i'll do it so that you wouldn't have to use the new Synth
I'm just not sure whether to try and make it a Synth modification
or (like ron) a separate class.
doing it to Synth would mean all .bench .scope .play etc. would work
pseudo=multi=threaded.
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Thu, 21 Jun 2001 15:27:52 -0400 (EDT)
From: "Ronald J. Kuivila" <---@---.--->
Subject: using the sched features of Group's...
Hi James,
I would like to be able to use Group's in the NRTVM for scheduling
actions, etc. Is there any easy way to perform the contents of
schedQueue based on arbitrary time increments? (I am looking for a
message like "play(dt)" which would perform all the actions between
the current time of the Group and that time plus dt.)
RJK
------------------------------
Date: Thu, 21 Jun 2001 16:00:37 -0400
From: "crucial" <---@---.--->
Subject: Re: patching/connecting windows . . .
>Hello,
>
>It occured to me that there may be a very simple way of patching one
>instrument into another - my "system" is to put instruments in the Library
>via Main.sc - so they're all there when SC compiles.
fyi: my system works thusly:
anytime you create an Instr ( aka Instrument) it gets stored in a global Library.
this was JmC's idea in sc3d5.
they are accesible via
Instr.at([\orc,\suborc,\instrname])
i actually load on demand because i have like 30 pages of Instr.
>Then I can use the lib menu and the Mixer gui to get lots of things running
>in parallel. Of course what would be wonderful would be to be able to patch
>one of these processes into another. I used to "do it" by sending the
>output of each lib item to a delay buffer and having each item be able to
>choose whether to read from the buffer. This was on the basis of an idea of
>Martin Robinsons which I may have got a bit wrong - it worked but seemed to
>sometimes lock up the machine - so in fact it NEARLY worked rather than worked).
>
>I'm hoping the SModule class in SC3 (or something else) will make inter
>instrument patching via GUI a simple and every day task but in the meantime . . .
>
>Maybe the crucial lib does it but I couldn't see where/how - Crucial ?
Patches are very flexible, can take anything that responds to .value as an input.
patches can dynamically have their args overriden:
patch.ar([ differentAudioInput ])
you can save a patch to disk with a placeholder for one of the args
saved as:
Patch([\reverbs,\distorto],[ Ar(0.0), // a plug on silence, a placeholder
0.3, // some params for the reverb
1.2 //
])
so you can write efx patches and save them without saving the intended audio
input with it.
then on the fly you can play the patch and override arguments.
thatDistortoPatch.ar([ { AudioIn.ar([1,2]) } ]) // feed it a function
for realtime switching:
Patch([\reverbs,\distorto],
[
PatchBox( listOfPlayersOrPatches ),
PatchBox( listOfKrPlayersForThisArg )
]).topGui
patch box can be switched via the gui or you can send the object messages
to switch it any way you like. variable cross fade / env.
strings when passed in as args will be treated as paths and loaded from disk.
the listOfPlayers could be an array of strings.
again i will mention that players can be any patch, a sound file player,
event stream player, kr rate patches, kr streams of patterns.
i'm going to do a direct ugenFunc one so you can skip having to make Instr and do a patch
on it.
>eg
>
>Library.at(['RLPF']).value(out)
equivalent:
Instr.ar([\filters,\rlpf],[ out ])
or
Instr.at([\filters,\rlpf]).ar(out)
>
>which would start up a filter and pass the out put of the "mother" patch as
>the input to the filter .
>
>It nearly works ! the problem/stumbling block is passing the output - that doesn't work.
>
>I imagine .value is wrong - is this a possibility as a simple patching method ?
>
>
>Jem
>
>
>
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Thu, 21 Jun 2001 16:00:43 -0400
From: "crucial" <---@---.--->
Subject: Re: connecting windows
>i love doing new things. my problem lies with my train of thought (which i discovered in my comp
>sci classes...) which seems to differ quite a bit from the 'typical' programmer.
>
>my logic isn't the most practical at times. and in many cases, it simply doesn't make any sense
>to other people.
>
>then again, i don't want to be a 'typical' programmer.
i have learned many lessons for life in general by better understanding good coding
principles.
>i was using the term 'object' in a physical manner. although you can't touch or hold a GUI, it's
>a much more tangible 'object' to the human eye. (and brain)
yes and half the world still thinks object orientated programming means dragging little
buttons
onto a window with interface builder.
>> so are you maybe thinking of parsing a synth's ugens , going down the graph, showing the
>> true
>> interconnections ?
>> i think that might be useful to look at, but a mess to edit with.
>
>this is almost exactly what i'm trying to do.
under my library any object responds to .gui with either the default gui or its own
specified gui class.
you might play around with using .inspect on a synth and browsing through the whole
ugen and output arrays.
you could build a gui class that instead of using drill down would go through the whole
graph and display everything.
>
>i'm trying (as usual) to rewrite SC in SC. SC already does this, but the graph is hidden from
>the user. i want to bring it forward, and represent the process visually.
that would very cool and educational.
the linking thing is really just the synth that the ugen exists in.
before play the ugens are in the ugens variable
once it gets going, they are in the ouputs variable as well
>> say you have:
>>
>> 4.do({
>> in = CombL.ar(in,0.2,rrand(0.05,0.2))
>> })
>>
>> that looks nice in code, very understandable. but in a graphic representation its
>> confusing.
>> that's the primary benefit of SC vs. Max
>
>but that's the whole challenge.
what's wrong with code ?
a view of the result of the code might be useful, but the code is the clearest expression
of the intent.
>
>i have another obsession (among the many others...) which involves the visualization of
>information. how does one go about representing complex pieces of information in a meaningful
>and understandable manner?
my dad knows this guy who is trying to represent complex data sets (medical, weather
systems etc.) in
sonic form. i chipped in my two cents noting that spacialization cue detection on humans
is really acute,
more so than amplitude (or possibly partials or frequency). he should use that.
i can play name that tune with 0.3 second splices of techno or hip hop. its all about the
producer's mix/image/
sound space.
>however, i dislike centralization. there's always a "Main" class or some controlling object in
>most computer systems.
but they mostly just set up independant watchers, load data, do inits, set up object
relationshihps
and then go into yoda object buddha wait mode. and wait for you damn humans to click on
shit.
>> I'm still trying to simplify and clarify Player so that everybody doesn't think its some
>> kind
>> of brand name or personal thing of mine.
>>
>> I think there is a general class of things that are 'normal fully fledged objects' (as
>> opposed
>> to say a function), that can be supplied to any kind of input in any kind of system.
>> when .valued, they play, they deliver, they do their thing.
>
>let's say i have some code in window a. this is the code for an oscillator of some sort.
>
>now i have some more code in window b. this is the code for a filter of some sort.
>
>at some point in time, that code has to interact. it has to come together. it has to become
>concrete.
no, the 'code'(sic) ie. object doesn't need to do anything or pass any information from
one to the other
at all.
the linking object, the uber-patch, that needs to specify which objects/functions/patches
etc. to
use and how to use them.
>my problem is not understanding how to get information (data) from one window to the other. it's
>almost like message passing in parallel computing.
except not remotely as complicated.
>> I would say they needn't be aware of each other's existence during the pre-link or even
>> after
>> linking. keep all of them in another structure.
>>
>> GUGenLinker( [ gugenone,gugentwo,gugenthree ])
>
>see, there's this structure. this centralization.
no centralization. that's just one linker/uber-patch.
you can have many.
they can themselves be used as little things to be linked by other bigger things.
>
>i want small parts.
>
>i want small parts to come together.
>
>however, i don't want a small parts collector.
>
>i want a very organic system.
>> I currently use PlayerPool, which can store a whole bunch of things,
>> and gives a nice hyper-link style button to gui any one of them individually.
>> It doesn't specify any way to play those players in a linked/connected fashion.
>> it just holds them in an array.
>> something else comes along and selects things out of the pool to link together.
>> that other thing does the linking.
>>
>> the object that does the linking is aware of all the objects which it is linking.
>> the pool knows of all possible linkable (in memory) objects.
>> the objects themselves know only themselves.
>
>hmmm... that sounds pretty cool.
>
>actually, this is somewhat similar to my GA system. the pool is the Environment (as in the
>"World" in which the objects exist) and the objects are self evolving entities.
PlayerPool is really simple. its just an array of things. its like a pallette to use to
paint or whatever.
you can have many of them. its just a holding place, a bag.
its not centralizing at all.
>the problem is that Synth is the central player. all of these GUGens have to be inserted into a
>single Synth.play at some point in time.
>
>yes?
>
>this is resolved in SC3, but there's still a top level Spawn delegating tasks.
no in SC3 it handles this top thing auto-magically so you don't have to worry about it.
stop worrying about it.
i made a post a bit ago about how i think i might make an sc2 synth that does that same
trick.
its much easier to do in sc2.
any time you do { }.play it figures out itself if it needs to create a top level and get
it playing.
otherwise your thing is just added to the group that is playing.
you only need to worry about your synth, your patch your link thing.
>cheers,
>
>christian
>
>
>
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Thu, 21 Jun 2001 16:25:23 -0400
From: "crucial" <---@---.--->
Subject: Re: connecting windows
>>> so are you maybe thinking of parsing a synth's ugens , going down the graph, showing the
>>> true
>>> interconnections ?
>>> i think that might be useful to look at, but a mess to edit with.
>>
>>this is almost exactly what i'm trying to do.
>
>under my library any object responds to .gui with either the default gui or its own
>specified gui class.
by which i was implying that you could write a UGenGui class that gives a custom useful
display to the UGen
or Synth could have SynthGui which would show the ugen array
then any time you .gui-ed any synth you would see what's in there.
i can code this in aprox 15 minutes, but i'm writing bass lines.
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Thu, 21 Jun 2001 14:14:25 -0400
From: christian adam hresko <---@---.--->
Subject: X API
http://www.theregister.co.uk/content/39/19871.html
c.a.h.
------------------------------
Date: Thu, 21 Jun 2001 14:00:03 -0400
From: christian adam hresko <---@---.--->
Subject: Re: patching/connecting windows . . .
James McCartney wrote:
> I'm working on something that will make patching very flexible.
> I'll say more when it is done.
>
so this connecting windows scheme i've been babbling about may actually come to
life?
cheers,
christian
------------------------------
Date: Thu, 21 Jun 2001 18:00:59 +0000
From: Jem Finer <---@---.--->
Subject: Re: patching/connecting windows . . .
on 21/6/01 12:40, James McCartney at asynth@io.com wrote:
>
> I'm working on something that will make patching very flexible.
> I'll say more when it is done.
>
> --- james mccartney james@audiosynth.com
> SuperCollider - a real time synthesis programming language for the PowerMac.
>
>
>
>
brilliant - I'll wait for that !
Jem
------------------------------
Date: Thu, 21 Jun 2001 14:05:24 -0400
From: krakowiak@sympatico.ca
Subject: Re: straight me up
please let me know when the new one's out. thanks David.
David Cottle wrote:
> Hi,
>
> > David Cottle's book has been very helpful so far it cleared a lot of
>
> I'm doing heavy revisions to the Digital Synthesis w SC. (The first draft
> was written after only a few months with SC.) Please download it in about
> two weeks. I give a better explanation of how to use mul and add in modules.
>
> --
> ><><><><><><><><><><><>
> David Cottle, computer music, contra, cottle@cerlsoundgroup.org
>
> "My next piece, which I have not yet learned to like." ? Herbert Brün
------------------------------
Date: Thu, 21 Jun 2001 14:15:52 -0400
From: jason mcmahon <---@---.--->
Subject: b.more.xperimental mailing list
- --=====================_7583025==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
I've started a mailing list for Baltimore-area experimental/digital
artists, not limited to just music, but also video experimentation and
digital performance artists. If you're interested, please give it a try....
http://groups.yahoo.com/group/bmorexperimental
//bsom
- --=====================_7583025==_.ALT
Content-Type: text/html; charset="us-ascii"
I've started a mailing list for Baltimore-area experimental/digital
artists, not limited to just music, but also video experimentation and
digital performance artists. If you're interested, please give it a
try....
http://groups.yahoo.com/group/bmorexperimental
//bsom
- --=====================_7583025==_.ALT--
------------------------------
Date: Thu, 21 Jun 2001 16:22:21 -0400
From: "crucial" <---@---.--->
Subject: Re: patching/connecting windows . . .
>>I'm hoping the SModule class in SC3 (or something else) will make inter
>>instrument patching via GUI a simple and every day task but in the meantime . . .
>>
>>Maybe the crucial lib does it but I couldn't see where/how - Crucial ?
>for realtime switching:
>
> Patch([\reverbs,\distorto],
> [
> PatchBox( listOfPlayersOrPatches ),
> PatchBox( listOfKrPlayersForThisArg )
> ]).topGui
>
needless to say this is one simple, limited way to do this.
i think there should/could be other ways, and i'm hoping you come up with some.
a PatchBox that browses and loads from disk
using PlayerPool to store large numbers of possibles
and select your input from there.
i used to have PatchChain
which played the output of one into the input of the next.
but with this new Patch class, there as many inputs as there
are arguments in the Instrument's function.
as Spec improves, it becomes possible to go through a collection/database
and limit your find to acceptable/legal inputs.
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Thu, 21 Jun 2001 13:49:26 -0700
From: James Reynolds <---@---.--->
Subject: Re: sc book
I am also looking forward to some kind of thorough reference for
SuperCollider. The included examples are certainly helpful for getting
started, and the integrated help documentation is great too, but they
leave me hungry for more. It's frustrating when you're trying to figure
out how to take it to the next level and have to learn by deciphering
mostly undocumented examples (after, of course, figuring out WHICH
examples you should be looking at). And there's nothing like the
frustration of selecting some cool-looking command, hitting command-H,
and getting dumped to the main Help index!
Of course, I don't think the documentation necessarily has to try to
cater to all musicians who have absolutely no programming experience. I
do have intermediate experience with several programming languages
(object-oriented and otherwise), and have already written some cool,
simple things with SuperCollider, but the lack of comprehensive,
well-organized documentation is the main thing holding me back from
doing everything I want to do with it.
All of this is not meant in any way to bash James' SC help files. They
are terrific: the examples are simple, useful, and easy to understand,
it's just a shame they don't exist for all SC functions. The next
step is the addition of more documentation showing how to tie it all
together: a set of thorough step-by-step tutorials, beginning through
advanced, would be great.
James
On Thursday, June 21, 2001, at 05:56 AM, Andy Wilson wrote:
> are there any plans out there to properly document sc?
>
> in my dreams Isee a huge o'reilly book that takes me from rudimentary to
> advanced sc programming while also teaching me the concepts of computer
> music a la curtis roads. there is a cd attached to the book with
> hundreds of
> example files, plugins, etc.........
>
> am I the only person who thinks that the lack of such documentation is
> the
> major reason sc is not used more widely?
>
> --
> { andy wilson << managing director << LShift << www.lshift.net }
> { www.andyw.com && www.faust-pages.com && www.directorxml.com }
>
>
------------------------------
Date: Thu, 21 Jun 2001 16:22:21 -0400
From: "crucial" <---@---.--->
Subject: Re: patching/connecting windows . . .
>>I'm hoping the SModule class in SC3 (or something else) will make inter
>>instrument patching via GUI a simple and every day task but in the meantime . . .
>>
>>Maybe the crucial lib does it but I couldn't see where/how - Crucial ?
>for realtime switching:
>
> Patch([\reverbs,\distorto],
> [
> PatchBox( listOfPlayersOrPatches ),
> PatchBox( listOfKrPlayersForThisArg )
> ]).topGui
>
needless to say this is one simple, limited way to do this.
i think there should/could be other ways, and i'm hoping you come up with some.
a PatchBox that browses and loads from disk
using PlayerPool to store large numbers of possibles
and select your input from there.
i used to have PatchChain
which played the output of one into the input of the next.
but with this new Patch class, there as many inputs as there
are arguments in the Instrument's function.
as Spec improves, it becomes possible to go through a collection/database
and limit your find to acceptable/legal inputs.
_____((
http://crucial-systems.com
_________________))_______
------------------------------
Date: Fri, 22 Jun 2001 00:31:46 +0200
From: Julian Rohrhuber <---@---.--->
Subject: Re: sc book
>
>All of this is not meant in any way to bash James' SC help files.
>They are terrific: the examples are simple, useful, and easy to
>understand, it's just a shame they don't exist for all SC functions.
>The next step is the addition of more documentation showing how to
>tie it all together: a set of thorough step-by-step tutorials,
>beginning through advanced, would be great.
I was thinking of a couple of lego style step by step constructions
of examples. Maybe we could start something like this on the swiki.
------------------------------
Date: Thu, 21 Jun 2001 16:24:03 -0500
From: chris clepper <---@---.--->
Subject: Re: connecting windows
> > also spracht chris clepper :
>>as for the following diagrams: we're on the same page i think.
>>although i want to do the patching on the fly via the SC3 method of
>>compiling while the synth engine is running. that's what i've always
>>wanted from a synthesis environment.
>
>ron kuivila's SC/Node class (look on the sc swiki) was i believe the
>original inspiration
>for the SC3 module.
>it works in sc2.
>
>i am considering an adaption of it and james' approach.
>
>actually wouldn't take that long.
please do. i have been playing around a bit with your lib and think
it has tons of possibilities...
>then you could execute multiple
>
>{
>
>}.play
>
>in sc2 just like in sc3.
that would be killer.
>i mainly want it so that i can get rid of transport and make Player
>class as simple as
>possible.
>but i'll do it so that you wouldn't have to use the new Synth
>
>I'm just not sure whether to try and make it a Synth modification
>or (like ron) a separate class.
>
>doing it to Synth would mean all .bench .scope .play etc. would work
>pseudo=multi=threaded.
>
that's up to you.
there is one feature of SC3 that i don't think is possible in SC2:
changing soundfiles while the synth is running. i often use tons of
files and in SC2 i have to make a seperate patch for each. lots of
gui windows!
thanks in advance (and for sharing the lib)
chris
------------------------------
Date: Thu, 21 Jun 2001 16:30:22 -0500
From: "David Cottle" <---@---.--->
Subject: Re: sc book
Hi,
> I am also looking forward to some kind of thorough reference for
[...]
> frustration of selecting some cool-looking command, hitting command-H,
> and getting dumped to the main Help index!
Just a tip. You can write your own help files. Use the .help extension and
put them in the Help folder. My problem is once I do something I sometimes
can't remember how, so I copy and paste little examples from the list or my
own work into the help files and either name them (e.g.) quadpan.help or
myhelp.help of just help!.help.
------------------------------
Date: Thu, 21 Jun 2001 19:18:48 -0400
From: Lee Azzarello <---@---.--->
Subject: Array.fill(value, function) misunderstanding
There is a line in the code James posted here a few days ago that's really
getting my goat. It was from the first composition in the message titled
"burn those idle cycles", which I must say contains 3 great pieces (even
though the 2nd one crashed my PB G3 500).
The line is this:
Array.fill(#[1,2,3,4].choose, {
rrand(24,96).midicps })
I thought I'd look it up in the help file for Array but the .fill message
doesn't seem to be there. So after some poking around I figured out what it
is doing and it seems like an invaluable method.
So my question is why isn't this method documented in the help files? The
only documentation I could find was through inspecting the .fill message,
which produced this:
ArrayedCollection::fill : this.fill(value)
Density::fill : this.fill(size, densityPercent)
List::fill : this.fill(item)
Meta_Collection::fill : this.fill(size, function)
Signal::fill : this.fill(val)
and the only line that seemed to relate was
Meta_Collection::fill : this.fill(size, function)
But What's a Meta_Collection? So I looked at the help file for Collection,
still nothing about .fill.
Granted that one line
Meta_Collection::fill : this.fill(size, function)
does tell exactly what it's doing but the word Array never even appears in
it! And the line that *does* have the word Array in it has nothing to do
with what I was looking for!
I may be expecting too much, but I'm having trouble memorizing these
"hidden" features of the language. I find myself going through long search
processes every time I use SC to find more information on certain messages.
- --------------------
- -l[e^2]
*old { ^this.shouldNotImplement(thisMethod) }
http://eds.org/~lee
------------------------------
Date: Thu, 21 Jun 2001 19:18:47 -0400
From: Lee Azzarello <---@---.--->
Subject: Lag not in Ugen Ref Sheet
Lag appears to be missing from the 2.2.10 Ugen Ref Sheet.
- --------------------
- -l[e^2]
*old { ^this.shouldNotImplement(thisMethod) }
http://eds.org/~lee
------------------------------
Date: Fri, 22 Jun 2001 10:30:57 +1000
From: newton armstrong <---@---.--->
Subject: Re: patching/connecting windows . . .
Another take on patchability in SC2...
I found my Instrument Library was getting too big and difficult to manage,
and there was a lot of duplication of code, so I decided to make a UGenFunc
class, with a bunch of filters and other things implemented as class
methods, and to subclass basic Instrument definitions. It works like this:
// UGenFunc class: patch instruments (subclasses) through
// any filters or other effects
UGenFunc {
*ar {
^{ arg env1, env2, blend, pan=0.0, amp=1.0; var src;
src = Pan2.ar(this.init.valueEnvir, pan, amp);
EnvGen2.ar(env1, env2, blend, src);
}
}
*arResonz {
^{ arg env1, env2, blend, pan=0.0, amp=1.0, cfreq=200.0, rq=0.1;
var src;
src = Resonz.ar(Pan2.ar(this.init.valueEnvir, pan, amp), cfreq, rq);
EnvGen2.ar(env1, env2, blend, src);
}
}
// ...many more methods, all of which are available to subclasses...
// UGenFunc subclasses: instrument source definitions
PMOscLFTri : UGenFunc {
*init {
^{ arg carfreq=20.0, modfreq=200.0, lfTriFreq=20.0, mulM=1.0,
phasemod=0.0;
PMOsc.ar(carfreq, modfreq, LFTri.ar(lfTriFreq, mulM), phasemod);
}
}
}
// ...many more instrument definitions, all of which can be patched through
// filters and other effect as defined in the methods of the superclass...
You can then use the classes in regular Patterns:
(
var w;
w = GUIWindow("", Rect.newBy(100, 90, 10, 60));
ButtonView( w, Rect.newBy(20, 20, 60, 20), "switch");
w.at(0).action_({ w.at(0).toggle });
Pbind(
\dur, 0.1,
\ugenFunc, Pswitch1([PMOscLFTri.ar, PMOscLFTri.arResonz], Pfunc({
w.at(0).value.asInt })),
\amp, 1.0,
\env1, Pfunc({ Env.perc(0.006, #[0.03, 0.006].choose, 1, #[1, -2.3]) }),
\env2, Pfunc({ Env.perc(0.06, #[0.3, 0.06].choose, 1, #[1, -2.3]) }),
\blend, Pfunc({ MouseX.new.value }),
\lfTriFreq, Pfunc({ MouseY(10, 2000, 'exponential').value }),
\mulM, Pfunc({ rrand(4.0, 8.0) }),
\carfreq, Pfunc({ exprand(4000, 5000) }),
\modfreq, 200.0,
\phasemod, Pfunc({ rrand(0.0, 2pi) }),
\cfreq, Pfunc({ exprand(200.0, 1000.0) }),
\rq, 0.73,
\pan, Pfunc({ 1.0.rand2 });
).play;
GUIWindow.closeAll;
)
------------------------------
Date: Fri, 22 Jun 2001 02:25:17 -0400
From: "crucial" <---@---.--->
Subject: re: sc3 style multiple {}.play in sc2
>>ron kuivila's SC/Node class (look on the sc swiki) was i believe the
>>original inspiration
>>for the SC3 design.
>>it works in sc2.
>>
>>i am considering an adaption of it and james' approach.
>>
>>actually wouldn't take that long.
>
>
>please do. i have been playing around a bit with your lib and think
>it has tons of possibilities...
i hope it is useful and sparks more sharing of objects. sc community is practicly
legendary for not sharing jack shit.
on the other most Max/msp artists i know all got their setups from someone. very few
of them built their own set up. twerk and ms. blechtom do, and of course josh.
>>then you could execute multiple
>>
>>{
>>
>>}.play
>>
>>in sc2 just like in sc3.
>
>that would be killer.
>
>>i mainly want it so that i can get rid of transport and make Player
>>class as simple as
>>possible.
>>but i'll do it so that you wouldn't have to use the new Synth
>>
this is starting to look cool. no need for topGui anymore, and you can
freely launch all kinds of things.
and even if you don't want to use the altered Synth class, the play buttons
still just say .play
>>I'm just not sure whether to try and make it a Synth modification
>>or (like ron) a separate class.
>that's up to you.
currently if you try and Synth.play while already running, it kvetches at you.
"synth already playing"
so its not really a biggy to extend that to the multiple spawn principle without
breaking any code or examples whatsoever.
>
>there is one feature of SC3 that i don't think is possible in SC2:
>changing soundfiles while the synth is running. i often use tons of
>files and in SC2 i have to make a seperate patch for each. lots of
>gui windows!
look again at SFP and the modified SoundFile
you could load a different SFP from disk and it would contain a SoundFile
that saved all the header info with it. as long as the file is the same size,
bit depth, samplerate etc. it will play fine without reading the header.
i am just archiving the header info.
i have yet to start messing with Samples and dynamic loading. i'm doing all
synthesis right now.
also you can with SFP just use it to play the sound files, not use the SFPClip, loop etc.
load up an array of them into a PlayerPool and you can switch between sound files
all you like.
>
>thanks in advance (and for sharing the lib)
>
>chris
>
>
_____((
http://crucial-systems.com
_________________))_______
------------------------------
End of sc-users-digest V1 #308
******************************