From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #307 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, June 21 2001 Volume 01 : Number 307 ---------------------------------------------------------------------- Date: Wed, 20 Jun 2001 17:03:59 +1000 From: newton armstrong <---@---.---> Subject: Re: OSC: Max->SC newton armstrong wrote: > From: "Ronald J. Kuivila" <---@---.---> > >> I don't know what you mean - I have used the code successfully in >> installations in the spring of 2000.  But I have not used it since.  Have >> you actually tried it?  (I am off in West Yellowstone right now and not in >> a position to check it out.) > > > Yeah, I've tried it. It produces the now familiar message: > € ERROR: expected ',' char at beginning of tag string. > > Perhaps the ',' requirement has been added to the OSC/SC protocol since your > project last year? If you look at the hex output of the OpenSoundControl > object in Max, it isn't there at the beginning of the tag, and I can't see a > provision for it anywhere in your pyrite code. > > I'll have a play with it a bit later today, and post the code if I get it > working. > > It works if you change this line: tags = theList.collect({arg item; ^typeTable.assocAt(type(item)) }); to: tags = 44 $ theList.collect({arg item; ^typeTable.assocAt(type(item)) }); 44 is the ascii code for the comma character, which needs to be prepended to the tag string. Thanks, btw. It's a very useful thing to have. ------------------------------ Date: Wed, 20 Jun 2001 12:37:22 -0500 From: chris clepper <---@---.---> Subject: Re: connecting windows so to get back to the root of the connecting windows idea: the desire is to connect seperate functions with their own gui windows together on the fly. this means they can share .ar and .kr (or any) info simply by 'patching' together a chain. and here are some ideas on how to do it: - - use the SWARK method to define a set of objects and then compile them as a single patch and execute that code. - - find a way to implement something like defaudiobus in SC1 or send~/receive~ in MAX/MSP to patch audio while running. - - experiment with the new crucial library, which seems to have loads of new options... - - wait for the final version of SC3. if i remember correctly this will be a feature, james? this is definitely something i have been trying to figure out how to do, but i'm very new to SC2/3 so i need lots of help. any further input would be great. chris ------------------------------ Date: Wed, 20 Jun 2001 14:22:47 -0400 From: christian adam hresko <---@---.---> Subject: Re: connecting windows chris clepper wrote: > so to get back to the root of the connecting windows idea: the desire > is to connect seperate functions with their own gui windows together > on the fly. this means they can share .ar and .kr (or any) info > simply by 'patching' together a chain. > > and here are some ideas on how to do it: > > - use the SWARK method to define a set of objects and then compile > them as a single patch and execute that code. > > the SWARK library isn't available to the public, is it? this is exactly (well, part of it...) what i'm trying to do. i'm going to plow through the Crucial Library tonight, and the rest of this week for that matter since it's pretty big. here's a better ASCII diagram of what i'm trying to do: anOsc = { FSinOsc.ar(//user input, user input, user input); }.inAGUI; | | | aFilter = { HPF.ar(//user input, user input, user input); }.inAGUI; | | | output = { //call Synth.play with anOsc and aFilter linked together }.inAGUI; anOsc, aFilter, and output ALL reside in separate windows. (i.e. not of the same patch...) the graphical representation might look something like: - --------------------------------- | GUGenName: oscillator1 | | OscType: FSinOsc | | param1: | | param2: | | param3: | | | | linkedTo: | | linkedWith: filter | - --------------------------------- - --------------------------------- | GUGenName: filter1 | | FilterType: HPF | | param1: | | param2: | | param3: | | | | linkedTo: oscillator | | linkedWith: output | - --------------------------------- - --------------------------------- | GUGenName: output | | NumberOfChannels: 2 | | | - --------------------------------- - --------------------------------- | | | Link GUGens | | | - --------------------------------- the "Link GUGens" would be a Button action of some type. it's a not a user definable GUGen. the output GUGen is not user definable either. only NumberOfChannels can be altered inside the GUI window. i can see the .gui method in the Crucial Library taking care of the inAGUI method i have above. cheers, christian ------------------------------ Date: Wed, 20 Jun 2001 15:45:22 -0400 From: tk <---@---.---> Subject: straight me up Hi! David Cottle's book has been very helpful so far it cleared a lot of problems. One question i have: can any of you give a simple explanation of "mul" and "add" ?? thanks ------------------------------ Date: Wed, 20 Jun 2001 15:54:11 -0400 From: christian adam hresko <---@---.---> Subject: Re: straight me up tk wrote: > Hi! > > David Cottle's book has been very helpful so far it cleared a lot of > problems. One question i have: can any of you give a simple explanation > of "mul" and "add" ?? > > thanks mul = multiply let's say you have a sine wave, with an amplitude (height) of 1.0 so the upper bound of the sine wave is 1.0 and the lower bound is -1.0 if you multiply by, let's say 2, the upper bound becomes 2.0 and the lower bound becomes -2.0 the amplitude is now 2.0 add can be thought of as an offset. let's use the same sine wave again with an amplitude of 1.0 if you add, let's say 1, the entire sine wave is shifted upwards by a factor of one now the lower bound is 0 and the upper bound is 2.0 the sine wave no longer crosses through the x axis. does this make sense? cheers, christian ------------------------------ Date: Wed, 20 Jun 2001 16:27:39 -0500 From: "t. krakowiak" <---@---.---> Subject: Re: straight me up yeah that makes sense, how about in the nested function say: { SinOsc.ar ( SinOsc.ar ( freq: 5, mul: 5, add: 440) } ) what would final freq be? > if you add, let's say 1, the entire sine wave is shifted upwards by a > factor of one isn't it a phase? ------------------------------ Date: Wed, 20 Jun 2001 15:46:43 -0500 From: James McCartney <---@---.---> Subject: Re: straight me up on 6/20/01 4:27 PM, t. krakowiak at krakowiak@sympatico.ca wrote: > yeah that makes sense, how about in the nested function say: > > { SinOsc.ar ( > > SinOsc.ar ( freq: 5, mul: 5, add: 440) > > } ) > > what would final freq be? The freq will vary from between 435 and 445 hertz at a rate of 5 hertz. > isn't it a phase? It's called the learning phase. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Wed, 20 Jun 2001 16:42:08 -0400 From: christian adam hresko <---@---.---> Subject: Re: straight me up "t. krakowiak" wrote: > yeah that makes sense, how about in the nested function say: > > { SinOsc.ar ( > > SinOsc.ar ( freq: 5, mul: 5, add: 440) > > } ) > > what would final freq be? > > > if you add, let's say 1, the entire sine wave is shifted upwards by a > > factor of one > > isn't it a phase? > this depends on what you're trying to do. the SinOsc UGen has a phase argument. is this what you're trying to do? Synth.play({ var freq; freq = SinOsc.kr(5.0, 5.0, 440); SinOsc.ar(freq); }); cheers, christian ------------------------------ Date: Wed, 20 Jun 2001 16:54:35 -0500 From: "t. krakowiak" <---@---.---> Subject: Re: straight me up yes, question is: isn't a "phase" part that moves sinewave away from x axis? - ----- Original Message ----- From: "christian adam hresko" <---@---.---> To: Sent: Wednesday, June 20, 2001 3:42 PM Subject: Re: straight me up > > > "t. krakowiak" wrote: > > > yeah that makes sense, how about in the nested function say: > > > > { SinOsc.ar ( > > > > SinOsc.ar ( freq: 5, mul: 5, add: 440) > > > > } ) > > > > what would final freq be? > > > > > if you add, let's say 1, the entire sine wave is shifted upwards by a > > > factor of one > > > > isn't it a phase? > > > > this depends on what you're trying to do. > > the SinOsc UGen has a phase argument. > > > is this what you're trying to do? > > > Synth.play({ > var freq; > freq = SinOsc.kr(5.0, 5.0, 440); > SinOsc.ar(freq); > }); > > > cheers, > > christian > > ------------------------------ Date: Wed, 20 Jun 2001 16:09:53 -0500 From: James McCartney <---@---.---> Subject: Re: straight me up on 6/20/01 4:54 PM, t. krakowiak at krakowiak@sympatico.ca wrote: > > yes, question is: isn't a "phase" part that moves sinewave away from x axis? in the equation y = sin(w) * mul + add; w is the phase. mul and add scale and offset the output. > > { SinOsc.ar ( > > > > SinOsc.ar ( freq: 5, mul: 5, add: 440) > > > > } ) the above is equivalent to: freq = sin( 5 * 2pi * t ) * 5 + 440; y = sin( freq * 2pi * t ); t is the time in seconds. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Wed, 20 Jun 2001 17:56:37 -0500 From: "t. krakowiak" <---@---.---> Subject: Re: straight me up got it - ----- Original Message ----- From: "James McCartney" <---@---.---> To: Sent: Wednesday, June 20, 2001 3:46 PM Subject: Re: straight me up > on 6/20/01 4:27 PM, t. krakowiak at krakowiak@sympatico.ca wrote: > > > yeah that makes sense, how about in the nested function say: > > > > { SinOsc.ar ( > > > > SinOsc.ar ( freq: 5, mul: 5, add: 440) > > > > } ) > > > > what would final freq be? > > The freq will vary from between 435 and 445 hertz at a rate of 5 hertz. > > > > isn't it a phase? > > It's called the learning phase. > > --- james mccartney james@audiosynth.com > SuperCollider - a real time synthesis programming language for the PowerMac. > > > > ------------------------------ Date: Wed, 20 Jun 2001 17:59:33 -0500 From: "t. krakowiak" <---@---.---> Subject: Re: straight me up > > It's called the learning phase. > cause i'm a "mul"e ------------------------------ Date: Wed, 20 Jun 2001 18:56:01 EDT From: DSPGuy@aol.com Subject: Processing Does anyone know what numerical precision SC uses in its processing, specifically, the digital filters such as SOS (second order filter section)? Is it floating point and if so, 64 or 32 bits? And does it matter if the data being processing originates, say, as 16 bit integers? I can do a detailed analysis to find out, but it would sure save time to skip that part. Jerry ------------------------------ Date: Wed, 20 Jun 2001 18:04:55 -0500 From: James McCartney <---@---.---> Subject: Re: Processing on 6/20/01 5:56 PM, DSPGuy@aol.com at DSPGuy@aol.com wrote: > > Does anyone know what numerical precision SC uses in its processing, > specifically, the digital filters such as SOS (second order filter > section)? > > Is it floating point and if so, 64 or 32 bits? And does it matter if the > data being processing originates, say, as 16 bit integers? > > I can do a detailed analysis to find out, but it would sure save time to > skip that part. > > Jerry > 32 bit floats mostly. Some things, like envelope segments that integrate over long durations, use doubles. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Wed, 20 Jun 2001 21:59:43 -0400 From: "crucial" <---@---.---> Subject: Re: connecting windows >> >i'm building something from scratch, so i'm not overly interested in >> >'custom' libraries just yet. >> >> btw. my 'custom' library is not a unified system. it is a collection of useful >> objects and approaches. there are some inter-locking systems. >> it makes no particular demands on doing everything within a system. >> where it does, is its weakness, and that's what is getting improved. > >i'm not sure if it's the way i compose my emails or what, but i'm obviously doing something >wrong. sorry, didn't mean to come off defensive/offensive. i just see the problem you are tackling, and am taking this chance to get further conversation going about the ideas i've laid out. and to show how your problem could be easily addressed with Instrument and Patch. but to be honest, i know you christian. and i know you checked out the library, and even though it works and you can start making music with it right away and start devising new linking systems right away, you thought "nah.... i want to build my own thing. " which i do all the time. that's why i've ended up being a heavy SC user, because i can set up stuff the way i want to do it, even if i could have gotten the same patch going in minutes in reaktor. we all have to choose where in the bit-head -> non-technical-musician continuum we wish to be. the bit-heads are not the most heavy jedi, they are just the ones who deal with the smallest particles. we are all special. i am not remotely a bit-head. somewhere up the pike from there. i'm just hoping i can funnel more of the hard working crazies like yourself into doing new things. >i'm trying to represent UGens in a graphical manner. these Graphcial UGens (GUGens...) can >be connected in the same manner as UGens in SC code. > I made some pages of simple oscillators, simple filters etc. Instr([\filters,\RLPF],{ arg audio=0.0,ffreq=500,rq=0.5,mul=1.0,add=0.0; RLPF.ar(audio,ffreq,rq,mul,add) }); i did this for binops, special compound filters, all oscs etc. you can patch them together at the ugen by ugen level. but generally you have a lot of 'graphical circuitry' for a fairly thin sound. better to write an Instr with a bit more beef: multiple oscillators, splayed stereo fields, Integrator, filters etc. the single UGen Instrument is useful though when i just want to add a Filter to something. i could write a class that would rip all UGen subclasses into virtual instruments. then you could just say. Patch([\UGens,\SinOsc]).topGui and you would have sliders for each of the arguments. but on the other hand it took me 20 minutes to just create a couple of pages of Instruments, and I'm done for ever. >the GUI 'object' (a GUGen) is a visual representation of the underlying code. therefore, the >code can exist without the GUGen, but the GUGen will do nothing without the code. code is the squiggly stuff on the page. when you compile and excecute the code, it becomes objects. the GUGen is a visual representation of those objects. 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. 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 so I'm just feeding back to your idea here: I feel that somethings are better done on a GUI (sequences,patching sound objects together) and some are better done by writing code (instrument functions, effect functions). when you break it down to small components like UGens, it becomes less useful as a GUI. IMHO. > >you're making too many assumptions about whether or not my original post was aimed towards >the Crucial Library. no, i'm just noticing that you are trying to solve a problem that I have recently posted a solution for. so i'm getting all in your face to discuss the issues and aspects of the problem. so that both of us will learn something from it. in order to improve my design, i would need to know why it strikes you right away that ... >i'm not sure if i want to use Player, and i'm not sure if i want to use .gui to create a >'Patch.' gui is only to create a gui that allows the user to interface with the patch itself using a graphical display /mouse. it will change soon to .addToGui to be like sc3. Ron is using .show 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. >> i just want to know how to 'snag' code from window (or >> >GUI) to window >i'm trying to access params that exist in one window or GUI from another window or GUI. well you wrote the GUI class right ? wouldn't you know better than anybody else how to access those params ? how about: christiansMagicGugen.params = christiansOtherMagicGugen.params; is your problem that the one object does not have a variable containing the other object ? >the trick is, the GUIs are not part of the same patch until everything is linked, and >executed. prior to the GUGen link process, the GUGens are independent of each other. >however, they are 'aware' of each others existence during the pre-link stage. okay i know you are done with school, but i'm going to be a nag. i'm sorry. but if you take the same approach as all those brainy computer scientists so cleverly devised, you will save yourself re-inventing the wheel. and as a bonus, we will find it easier to answer your questions because they will make sense. a GUI is a Graphical User Interface. you are talking about an Object that is capable of creating a GUI, but it ISN"T ITSELF a GUI. so your really talking about the GUGen (TM) objects. 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 ]) 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. >i'm a simple simple boy and i'm easily confused by all these technicalities. > >i've never worked with data structures, abstract data types, sorting techniques, etc, etc. yes you have ;) you went to school for this stuff, 'member ? and you've been hard at work on SC for what, a year ? >the other day i was thinking of hashing my instruction set for my virtual machine using >quadratic probing, but i realized i'm a moron and don't understand this bizarre world of >programming.... well more to the point, you should do something useful with your energy. like go to the beach. >hmmm... i've actually got a genetic algorithm environment (much improved since the previous >release which didn't really work...) that i'm working on. > >when it's finished (for the time being) i'll send it to you if you'd like. mos def ! >okay. so this in no way answers my question about connecting windows. well okay. windows are GUIWindows. they have an array called views that holds all the views that are on the window. those views are all of the simple concrete sort : RangeView, ButtonView etc. you probably don't really care about what those things are doing. you probably want to get the params from one GUGen to be sent to another GUGen. why not say gugenOne.params = gugenTwo.params; so it really doesn't matter what window if any those GUGens have installed a GUI upon. the window is completely irrelevant. you must learn to separate the View from the Model. the GUI is not the object. the map is not the territory. you should study classical MVC. > > > > >cheers, > >christian > > > _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Wed, 20 Jun 2001 22:03:29 -0400 From: "crucial" <---@---.---> Subject: Re: connecting windows >i'm going to plow through the Crucial Library tonight, and the rest of >this week for that matter since it's pretty big. not as big as it looks. lots of small classes. the power of factoring etc. etc. > > >here's a better ASCII diagram of what i'm trying to do: > >anOsc = { > FSinOsc.ar(//user input, user input, user input); >}.inAGUI; >| >i can see the .gui method in the Crucial Library taking care of the >inAGUI method i have above. do you mean that message to take a function and create a bigger container around it ? or to actually pop the gui window up ? i'm changing .gui to .addToGui which i think is the most expressive. and it also gives you the option of doing that gui on an existing window, or if no layout is supplied, creates a new layout on a new window. _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Thu, 21 Jun 2001 02:24:28 -0500 From: chris clepper <---@---.---> Subject: Re: connecting windows >the SWARK library isn't available to the public, is it? i'm not sure about that. i have it... >this is exactly (well, part of it...) what i'm trying to do. > >i'm going to plow through the Crucial Library tonight, and the rest of >this week for that matter since it's pretty big. agreed. it seems like it might have the depth to do what we're looking for... 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. i think SC3 might answer these questions. james, care to comment??? > >here's a better ASCII diagram of what i'm trying to do: > >anOsc = { > FSinOsc.ar(//user input, user input, user input); >}.inAGUI; >| >| >| >aFilter = { > HPF.ar(//user input, user input, user input); >}.inAGUI; >| >| >| >output = { > //call Synth.play with anOsc and aFilter linked together >}.inAGUI; > > >anOsc, aFilter, and output ALL reside in separate windows. (i.e. not of >the same patch...) > >the graphical representation might look something like: > >--------------------------------- >| GUGenName: oscillator1 | >| OscType: FSinOsc | >| param1: | >| param2: | >| param3: | >| | >| linkedTo: | >| linkedWith: filter | >--------------------------------- > >--------------------------------- >| GUGenName: filter1 | >| FilterType: HPF | >| param1: | >| param2: | >| param3: | >| | >| linkedTo: oscillator | >| linkedWith: output | >--------------------------------- > >--------------------------------- >| GUGenName: output | >| NumberOfChannels: 2 | >| | >--------------------------------- > > >--------------------------------- >| | >| Link GUGens | >| | >--------------------------------- > > > > >the "Link GUGens" would be a Button action of some type. it's a not a >user definable GUGen. the output GUGen is not user definable either. >only NumberOfChannels can be altered inside the GUI window. > >i can see the .gui method in the Crucial Library taking care of the >inAGUI method i have above. > i never know what i want to do from one moment to the next best cgc ------------------------------ Date: Thu, 21 Jun 2001 03:28:51 -0400 From: christian adam hresko <---@---.---> Subject: Re: connecting windows crucial wrote: > > >i'm not sure if it's the way i compose my emails or what, but i'm obviously doing something > >wrong. > > sorry, didn't mean to come off defensive/offensive. i just see the problem you are > tackling, and am taking > this chance to get further conversation going about the ideas i've laid out. and to show > how > your problem could be easily addressed with Instrument and Patch. probably more my 'fault' as i tend to get a little goofy when i compose emails during the wee hours of the night/morning. i know your intentions were and are good, and i appreciate your feedback. > > > but to be honest, i know you christian. hmmm... how so? > and i know you checked out the library, and even > though > it works and you can start making music with it right away and start devising new linking > systems > right away, you thought "nah.... i want to build my own thing. " well, kinda maybe possibly. it's in my very nature to do what's already been done. i like to take things apart and put them back together. even if i don't understand exactly what's going on. i like to start from the ground up. but i do realize the benefits of code reuse, and realizing when i should (and can) use preexisting code. it's my own personal struggle... > > > which i do all the time. that's why i've ended up being a heavy SC user, because i can > set up > stuff the way i want to do it, even if i could have gotten the same patch going in minutes > in > reaktor. > > we all have to choose where in the bit-head -> non-technical-musician continuum we wish to > be. > the bit-heads are not the most heavy jedi, they are just the ones who deal with the > smallest particles. > we are all special. i am not remotely a bit-head. somewhere up the pike from there. > > i'm just hoping i can funnel more of the hard working crazies like yourself into doing new > things. 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'm trying to represent UGens in a graphical manner. these Graphcial UGens (GUGens...) can > >be connected in the same manner as UGens in SC code. > > > > I made some pages of simple oscillators, simple filters etc. > > Instr([\filters,\RLPF],{ arg audio=0.0,ffreq=500,rq=0.5,mul=1.0,add=0.0; > > RLPF.ar(audio,ffreq,rq,mul,add) > > }); > > i did this for binops, special compound filters, all oscs etc. > > you can patch them together at the ugen by ugen level. > > but generally you have a lot of 'graphical circuitry' for a fairly thin sound. that's the huge drawback of what i'm trying to do. but to tell you the truth, i'm only trying to do this to see if i can do it. it's not practical. there's programs like Max and Reaktor which do this much better. for whatever reason, i get more satisfaction when i do something in SC that has absolutely nothing to do with 'music.' i'll probably end up writing some C++ plugins that are basically pointless. but pointless working plugins, to me, are somewhat gratifying. > > > better to write an Instr with a bit more beef: > multiple oscillators, > splayed stereo fields, > Integrator, filters etc. > > the single UGen Instrument is useful though when i just want to add a Filter to something. > > i could write a class that would rip all UGen subclasses into virtual instruments. > then you could just say. > > Patch([\UGens,\SinOsc]).topGui > > and you would have sliders for each of the arguments. > > but on the other hand it took me 20 minutes to just create a couple of pages of > Instruments, and I'm done for ever. yep. this is the reason SC is a powerful tool. there's a decent learning curve, but as we've seen on this list, it doesn't take a programmer to create fairly complex instruments, classes, and 'systems.' > > > >the GUI 'object' (a GUGen) is a visual representation of the underlying code. therefore, the > >code can exist without the GUGen, but the GUGen will do nothing without the code. > > code is the squiggly stuff on the page. when you compile and excecute the code, it > becomes > objects. the GUGen is a visual representation of those objects. i'll have to be more explicit with my emails. 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) and i should've defined a GUGen before i started using the term so loosely. GUGen: A graphical representation of a Unit Generator. A GUGen is the "front end" for the underlying code which will eventually be compiled, linked, and executed as SC objects. > > > 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. 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. > > > 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. 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? natural language processing and representation in the visual domain. > > > so I'm just feeding back to your idea here: > > I feel that somethings are better done on a GUI (sequences,patching sound objects > together) > and some are better done by writing code (instrument functions, effect functions). i'm just going through a GUI stage. although i'm quite fascinated by GUI design and design aspects. to tell you the truth, i'd do away with all GUIs. i'm colorblind for god's sake. i'm the most non visual person i know. so maybe this is why i'm attracted to the idea of creating a better graphical layout and a better graphical system to represent intangible 'objects.' > > > when you break it down to small components like UGens, it becomes less useful as a GUI. > IMHO. yes, it most definitely does. i'm a huge advocate of small, compact classes which compose a larger system. however, i dislike centralization. there's always a "Main" class or some controlling object in most computer systems. even computer hardware. you have a "Central" Processing Unit. why does it have to be "Central?" we are very centralized creatures. i don't like that. > > > > > >you're making too many assumptions about whether or not my original post was aimed towards > >the Crucial Library. > > no, i'm just noticing that you are trying to solve a problem that I have recently posted a > solution for. > so i'm getting all in your face to discuss the issues and aspects of the problem. so that > both of us > will learn something from it. well, we're definitely communicating. so your idea worked. hopefully you'll be able to deal with my stubbornness. > > > in order to improve my design, i would need to know why it strikes you right away that ... > > >i'm not sure if i want to use Player, and i'm not sure if i want to use .gui to create a > >'Patch.' > > gui is only to create a gui that allows the user to interface with the patch itself using > a graphical display /mouse. > it will change soon to .addToGui to be like sc3. Ron is using .show well, i just mean i'm not sure because i haven't looked at everything in detail yet. but you're doing a good job of convincing me that a good deal of what i need is already there. so this motivates me more to explore your library. > > > 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. you mean passing objects as arguments? since everything in SC is an object, i mean an instance of a class. is this what you're talking about? > > > when .valued, they play, they deliver, they do their thing. yeah. objects. i guess that answers my question. i think. > > > >> i just want to know how to 'snag' code from window (or > >> >GUI) to window > > >i'm trying to access params that exist in one window or GUI from another window or GUI. > > well you wrote the GUI class right ? wouldn't you know better than anybody else how to > access > those params ? i haven't worked on the GUI class yet. i'm trying to recognize and resolve whatever problems i can think of. this is one of the larger hurdles i have to overcome. i might even UML the whole thing. again, my wording was bad. 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. > > > how about: > > christiansMagicGugen.params = christiansOtherMagicGugen.params; > > is your problem that the one object does not have a variable containing the other object ? 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. the problem is that SC is a centralized system. i'm not saying it's a bad system. it's far from bad. but there's still the idea of centralization. that was a big problem with my genetic algorithm project... > > > >the trick is, the GUIs are not part of the same patch until everything is linked, and > >executed. prior to the GUGen link process, the GUGens are independent of each other. > >however, they are 'aware' of each others existence during the pre-link stage. > > okay i know you are done with school, but i'm going to be a nag. i'm sorry. but if you > take the same approach as all those brainy computer scientists so cleverly devised, > you will save yourself re-inventing the wheel. and as a bonus, we will find it easier to > answer your questions because they will make sense. oh, my questions never make sense. they make sense to me, but not to many other people. > > > a GUI is a Graphical User Interface. you are talking about an Object that is capable > of creating a GUI, but it ISN"T ITSELF a GUI. yep. exactly. > > > so your really talking about the GUGen (TM) objects. yes. copyright 2001 Christian Adam Hresko hehe... > > > 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. 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. > > > >i'm a simple simple boy and i'm easily confused by all these technicalities. > > > >i've never worked with data structures, abstract data types, sorting techniques, etc, etc. > > yes you have ;) you went to school for this stuff, 'member ? > and you've been hard at work on SC for what, a year ? i wish i had a full year to work on SC. i had to spend most of my time doing calculus, linear algebra, electronics, analog and digital recording, sound synth, comp sci, physics, etc, etc... not to mention all the societies and whatnot that i was involved with. and i've been working on an article since october. so i've spent more time doing academic wank. my data structures class wasn't exactly a walk in the park either... > > > >the other day i was thinking of hashing my instruction set for my virtual machine using > >quadratic probing, but i realized i'm a moron and don't understand this bizarre world of > >programming.... > > well more to the point, you should do something useful with your energy. > like go to the beach. or watch TV. total request live. what else is there to live for? > > > >hmmm... i've actually got a genetic algorithm environment (much improved since the previous > >release which didn't really work...) that i'm working on. > > > >when it's finished (for the time being) i'll send it to you if you'd like. > > mos def ! mosfet! > > > >okay. so this in no way answers my question about connecting windows. > > well okay. windows are GUIWindows. they have an array called views that holds > all the views that are on the window. those views are all of the simple concrete > sort : RangeView, ButtonView etc. > > you probably don't really care about what those things are doing. i care about everything. i don't like not knowing what's going on with the tools i'm working with. even if it's irrelevant to what i'm doing, i like to have at least a decent idea of how things are working. > > > you probably want to get the params from one GUGen to be sent to another GUGen. yes, yes, yes. this is what i've been trying to drag out of someone. this is where i'm stuck. > > > why not say > gugenOne.params = gugenTwo.params; > > so it really doesn't matter what window if any those GUGens have installed a GUI upon. 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. > > > the window is completely irrelevant. > > you must learn to separate the View from the Model. > the GUI is not the object. > the map is not the territory. > > you should study classical MVC. i know it doesn't seem like it, but we did this in my Java class. but that was only one semester. i finally have time to read up on all the stuff that grabbed me the most. discussion to be continued... cheers, christian ------------------------------ End of sc-users-digest V1 #307 ******************************