Re: Pbind question
[email protected] Thu, 10 Jun 2021 09:17:46 -0400
| Newsgroups | gmane.comp.audio.supercollider.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------2916288ACDECAB4CDF178DAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Just a few thoughts from someone who has felt much the same: frustration shading over to anger. * There will be push back, but I don't believe SuperCollider is a first programming environment. The main reason? In contrast to many other languages, it does not have a canonical form, i.e., it's not standardized in the same way other languages are. This is because it has created and evolved along ad hoc lines, essentially through the research or teaching needs and interests of its primary users. * Composing music with code leads to 'coded music.' In other words, the technology used to make it colours the result. This has always been the case no matter what technology was to hand; the purest and most intuitive technology is probably the voice. So if your musical idiom and methodology is not compatible with the colour of code, it will be difficult to make the kind of music you want to make. * Underlying SuperCollider is a whole vast infrastructure of mathematics and engineering. Much of the difficulty I experience(d) with SC arose because of my ignorance of the mathematics of signal processing as well as with some of the traditions of electronic music. * The documentation, while comprehensive, is not systematically or completely or reliably indexed. As a result the, sometimes essential, nooks and crannies of technique are inaccessible. Thus one relies on the few masters or veterans (or maniacs) who have a virtually total command of the SC environment and idiom. They are few, busy, distracted and sometimes impatient. In my experience, Help would benefit from being organized in a more widely used system, e.g., Docbook or subset. (This is likely controversial but after some effort and with a fair amount of professional experience in technical writing and document management, I never found it to be a... commodious writing or editing environment.) * If you are coming to musical composition, as I am, from a traditional or conventional musical background, e.g., as a pianist or (shudder) trumpet player, the lack of 'touch' or 'connection' to the music making process is going to present an enormous cognitive disconnect. This is similar to the 'coded music' comment above. The upshot, if you need 'touch' or immediacy in your music making it will take a very long time indeed to get it through SC. In the short term, it's probably wise to follow some sort of parallel path that keeps you vitalized and encouraged with an alternative compositional method and let the SC be a supplement or niche resource -- bits and pieces, tiny steps. I could go on but all of this is to say it's not the end of the world if you take a vacation from SC. Or put it on a back burner. The important thing is to get your mind and spirit into a place where you can enjoy what you love. Which, I assume, is making music that speaks to you and is from you. ...edN On 2021-06-10 12:34 a.m., [email protected] wrote: > Hey everyone, > Thanks for all the detailed responses. Unfortunately, I understand > less than half of what you all sent me. It's probably closer to a > third, and even that seems generous. > > I appreciate that you took so much time to explaining what I wanted, > and ways to implement it, but I know I didn't understand much of it at > all. > > What follows is long and will definitely come off as resentful, so I > apologize in advance. I've had these thoughts for a long time, but > only feel comfortable expressing them now. > > As of September of this year, I would have been using SC for three > years. As of this month, I've been subscribed to this list for two > years. I've only asked for help here twice before, for assistance in > debugging code. > > Beyond that, I gave up on trying to understand the topics here a long time ago. > > To be blunt, trying to find something in this list: in this thread, or > otherwise, I can understand, let alone implement myself, feels > fruitless. It feels like you already need mastery of SC in order to > use the advice generated by this list, which defeats the purpose of > its existence. > > Sclang was my first programming language, so I learned it, and > programming more broadly, from a composer's standpoint. All the > technical jargon everyone throws around: in online tutorials, in this > list, and in this thread, almost entirely slides off of me. I've only > been able to do what little I know how to do in SC is that my college > professor created SC teaching materials that assumed no prior > programming experience from the reader. In fact, when I told him early > on how the online SC tutorials (for 3.9.3--the version I use) were > crap, he explained that that was why he made his own. > > They are the only SC help tutorials I've ever used. > > As much as I appreciate that you all gave detailed answers for how to > implement what I asked for, I don't have any expertise at all to > implement them. After reading what you all wrote, I honestly don't > know what to ask for anymore. > > If any of you knows where to find SC tutorials that don't assume that > the reader has prior programming knowledge, then that'd be great. > Maybe annotated code examples of the musical note thing I asked for > would help as well? A detailed glossary of SC terms might also be > valuable, because basically everything you guys have said is > unfamiliar to me. > > If any of you wants to know what tutorials I use, I can post them here. > > I'm sorry for the long, angry reply. This list is an amazing resource. > It just seems like I'm too inexperienced to fully appreciate, let > alone implement, what's contained in it. > > On 6/9/21, [email protected] <[email protected]> wrote: >> On Tue, Jun 8, 2021 at 9:27 PM <[email protected]> wrote: >>> I’ve always wondered why the Pattern class' library doesn’t seem to allow >>> for continuous change... >> Hm... there are two ways to conceive of control of synthesis: as >> continuities, or as discrete events. I'm going to say something a bit >> speculative, but it seems to me that these domains are very different, >> and that it's a lot to ask a single abstraction to cover both of those >> requirements equally well. >> >> Consider, for instance, analog modular (or VCV Rack). Here, >> *everything* is a continuous signal -- and it takes extraordinary >> measures to produce discrete notes (clocks and clock dividers, step >> sequencers, various forms of algorithmic magic hidden -- and not >> inspectable -- beneath panel knobs). So one could ask the converse >> question: Why do analog modular synths not allow for easy, polyphonic >> notes? >> >> If "the Pattern class library [not] allow[ing] for continuous change" >> means that patterns are useless, then by the same token, the >> difficulty of playing polyphonic notes with analog modular would >> likewise mean that analog modular synths are useless. >> >> Which is of course a preposterous conclusion. So perhaps the premise >> is mistaken. In that case, Patterns *would* be seen as useful, but >> perhaps not a perfect fit for what you're trying to do. >> >> ***Main idea:*** >> >> One thing that would help here is a way, in SC, to map arbitrary >> control synths onto a main synth's control inputs. Instead of thinking >> in terms of one big synth that does every kind of modulation I could >> possibly dream of, we could think in terms of clusters of synths: one >> main synth, plus a frequency source synth (which could be a line, an >> LFO, a breakpoint envelope, a chaotic function, or...?), plus x number >> of other control source synths. >> >> We currently don't have an easy-to-use abstraction for this -- so it >> looks like it's impossible. It's not impossible -- just needs to be >> built from smaller units. >> >>> I don’t really like (what I understand of) its conception of time - as a >>> grid that underlies and cuts everything >> I'm sorry, but I have to laugh about that one. >> >> Pexprand(0.1, 0.5, inf).asStream.nextN(20) >> >> -> [ 0.3443073364569, 0.15915276388006, 0.31323417573412, >> 0.12526591005795, 0.16658631354666, 0.35796869063474, >> 0.32007183151481, 0.19765304288833, 0.13097535468957, >> 0.46631971015074, 0.27155564302265, 0.13039742147499, >> 0.47910849783507, 0.14895486462567, 0.23602943303401, 0.3350735998923, >> 0.1139492280449, 0.30566291638996, 0.16258653827006, 0.18253953239994 >> ] >> >> I expect this collection of durations would defy attempts to identify >> a consistent metric grid. Yet, it was generated by a pattern. How >> could that be, if patterns are all about time grids? The answer is: >> There is nothing in the pattern library that enforces simple integer >> ratios between time durations. >> >>> strictures the organic-abstract potential of audio synthesis >> Right -- everybody has an aesthetic bias. If patterns aren't a good >> fit for yours, then there's no need to shoehorn your ideas into >> patterns. >> >> hjh >> >> _______________________________________________ >> sc-users mailing list >> >> info (subscription, etc.): >> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx >> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ >> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ >> > --------------2916288ACDECAB4CDF178DAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Just a few thoughts from someone who has felt much the same: frustration shading over to anger.</p> <p>* There will be push back, but I don't believe SuperCollider is a first programming environment. The main reason? In contrast to many other languages, it does not have a canonical form, i.e., it's not standardized in the same way other languages are. This is because it has created and evolved along ad hoc lines, essentially through the research or teaching needs and interests of its primary users.</p> <p>* Composing music with code leads to 'coded music.' In other words, the technology used to make it colours the result. This has always been the case no matter what technology was to hand; the purest and most intuitive technology is probably the voice. So if your musical idiom and methodology is not compatible with the colour of code, it will be difficult to make the kind of music you want to make.</p> <p>* Underlying SuperCollider is a whole vast infrastructure of mathematics and engineering. Much of the difficulty I experience(d) with SC arose because of my ignorance of the mathematics of signal processing as well as with some of the traditions of electronic music. <br> </p> <p>* The documentation, while comprehensive, is not systematically or completely or reliably indexed. As a result the, sometimes essential, nooks and crannies of technique are inaccessible. Thus one relies on the few masters or veterans (or maniacs) who have a virtually total command of the SC environment and idiom. They are few, busy, distracted and sometimes impatient. In my experience, Help would benefit from being organized in a more widely used system, e.g., Docbook or subset. (This is likely controversial but after some effort and with a fair amount of professional experience in technical writing and document management, I never found it to be a... commodious writing or editing environment.)<br> </p> <p>* If you are coming to musical composition, as I am, from a traditional or conventional musical background, e.g., as a pianist or (shudder) trumpet player, the lack of 'touch' or 'connection' to the music making process is going to present an enormous cognitive disconnect. This is similar to the 'coded music' comment above. The upshot, if you need 'touch' or immediacy in your music making it will take a very long time indeed to get it through SC. In the short term, it's probably wise to follow some sort of parallel path that keeps you vitalized and encouraged with an alternative compositional method and let the SC be a supplement or niche resource -- bits and pieces, tiny steps.</p> <p>I could go on but all of this is to say it's not the end of the world if you take a vacation from SC. Or put it on a back burner. The important thing is to get your mind and spirit into a place where you can enjoy what you love. Which, I assume, is making music that speaks to you and is from you.</p> <p>...edN</p> <p><br> </p> <div class="moz-cite-prefix">On 2021-06-10 12:34 a.m., <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br> </div> <blockquote type="cite" cite="mid:CABrkSV5YiHg_WThRJEGZ8m5bEQcz+F=BoWgR1ufdTrGMs3_ATQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org"> <pre class="moz-quote-pre" wrap="">Hey everyone, Thanks for all the detailed responses. Unfortunately, I understand less than half of what you all sent me. It's probably closer to a third, and even that seems generous. I appreciate that you took so much time to explaining what I wanted, and ways to implement it, but I know I didn't understand much of it at all. What follows is long and will definitely come off as resentful, so I apologize in advance. I've had these thoughts for a long time, but only feel comfortable expressing them now. As of September of this year, I would have been using SC for three years. As of this month, I've been subscribed to this list for two years. I've only asked for help here twice before, for assistance in debugging code. Beyond that, I gave up on trying to understand the topics here a long time ago. To be blunt, trying to find something in this list: in this thread, or otherwise, I can understand, let alone implement myself, feels fruitless. It feels like you already need mastery of SC in order to use the advice generated by this list, which defeats the purpose of its existence. Sclang was my first programming language, so I learned it, and programming more broadly, from a composer's standpoint. All the technical jargon everyone throws around: in online tutorials, in this list, and in this thread, almost entirely slides off of me. I've only been able to do what little I know how to do in SC is that my college professor created SC teaching materials that assumed no prior programming experience from the reader. In fact, when I told him early on how the online SC tutorials (for 3.9.3--the version I use) were crap, he explained that that was why he made his own. They are the only SC help tutorials I've ever used. As much as I appreciate that you all gave detailed answers for how to implement what I asked for, I don't have any expertise at all to implement them. After reading what you all wrote, I honestly don't know what to ask for anymore. If any of you knows where to find SC tutorials that don't assume that the reader has prior programming knowledge, then that'd be great. Maybe annotated code examples of the musical note thing I asked for would help as well? A detailed glossary of SC terms might also be valuable, because basically everything you guys have said is unfamiliar to me. If any of you wants to know what tutorials I use, I can post them here. I'm sorry for the long, angry reply. This list is an amazing resource. It just seems like I'm too inexperienced to fully appreciate, let alone implement, what's contained in it. On 6/9/21, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On Tue, Jun 8, 2021 at 9:27 PM <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I’ve always wondered why the Pattern class' library doesn’t seem to allow for continuous change... </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Hm... there are two ways to conceive of control of synthesis: as continuities, or as discrete events. I'm going to say something a bit speculative, but it seems to me that these domains are very different, and that it's a lot to ask a single abstraction to cover both of those requirements equally well. Consider, for instance, analog modular (or VCV Rack). Here, *everything* is a continuous signal -- and it takes extraordinary measures to produce discrete notes (clocks and clock dividers, step sequencers, various forms of algorithmic magic hidden -- and not inspectable -- beneath panel knobs). So one could ask the converse question: Why do analog modular synths not allow for easy, polyphonic notes? If "the Pattern class library [not] allow[ing] for continuous change" means that patterns are useless, then by the same token, the difficulty of playing polyphonic notes with analog modular would likewise mean that analog modular synths are useless. Which is of course a preposterous conclusion. So perhaps the premise is mistaken. In that case, Patterns *would* be seen as useful, but perhaps not a perfect fit for what you're trying to do. ***Main idea:*** One thing that would help here is a way, in SC, to map arbitrary control synths onto a main synth's control inputs. Instead of thinking in terms of one big synth that does every kind of modulation I could possibly dream of, we could think in terms of clusters of synths: one main synth, plus a frequency source synth (which could be a line, an LFO, a breakpoint envelope, a chaotic function, or...?), plus x number of other control source synths. We currently don't have an easy-to-use abstraction for this -- so it looks like it's impossible. It's not impossible -- just needs to be built from smaller units. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> I don’t really like (what I understand of) its conception of time - as a grid that underlies and cuts everything </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I'm sorry, but I have to laugh about that one. Pexprand(0.1, 0.5, inf).asStream.nextN(20) -> [ 0.3443073364569, 0.15915276388006, 0.31323417573412, 0.12526591005795, 0.16658631354666, 0.35796869063474, 0.32007183151481, 0.19765304288833, 0.13097535468957, 0.46631971015074, 0.27155564302265, 0.13039742147499, 0.47910849783507, 0.14895486462567, 0.23602943303401, 0.3350735998923, 0.1139492280449, 0.30566291638996, 0.16258653827006, 0.18253953239994 ] I expect this collection of durations would defy attempts to identify a consistent metric grid. Yet, it was generated by a pattern. How could that be, if patterns are all about time grids? The answer is: There is nothing in the pattern library that enforces simple integer ratios between time durations. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">strictures the organic-abstract potential of audio synthesis </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Right -- everybody has an aesthetic bias. If patterns aren't a good fit for yours, then there's no need to shoehorn your ideas into patterns. hjh _______________________________________________ sc-users mailing list info (subscription, etc.): <a class="moz-txt-link-freetext" href="http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx">http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx</a> archive: <a class="moz-txt-link-freetext" href="http://www.listarc.bham.ac.uk/marchives/sc-users/">http://www.listarc.bham.ac.uk/marchives/sc-users/</a> search: <a class="moz-txt-link-freetext" href="http://www.listarc.bham.ac.uk/lists/sc-users/search/">http://www.listarc.bham.ac.uk/lists/sc-users/search/</a> </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> </body> </html> --------------2916288ACDECAB4CDF178DAC-- _______________________________________________ sc-users mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ search: http://www.listarc.bham.ac.uk/lists/sc-users/search/