Re: Pbind question
[email protected] Thu, 10 Jun 2021 19:06:38 +0200
| Newsgroups | gmane.comp.audio.supercollider.user |
|---|---|
| Message-ID | <CABYyzgBpsdOext6prGdB5JasUD4Yu1Y41hW3D_uR10SGCO4Ayw@mail.gmail.com> |
--000000000000eea03905c46c6af0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, James, thank you for your response. ... I don't think patterns are useless ! My apologies if i gave off that impression. I do use Patterns sometimes and am quite aware/in awe of their potential, hence my curiosity. I just get a bit stuck composing with continuities, for which i might have an aesthetic bias like you say (i do not write indian music at all but please check out the video on Gamakas if you want a different, not so personal context) and i was quite happy to find a simple fix with Varlag + Pseg + Pmono. As for the 'grid' - there is such a thing as unstructured grids. I didn't mean to say it's consistent or repetitive, just that the Pattern Class seems to be based on steps / discrete events, which i now understand is inherent to the complexity of writing such an abstraction. Strong choices have to be made in the conception of something as diverse and powerful. I'm perfectly happy with it as long as i know this is the way it is ! Pauline, here are two tutorials that I found very accessible, helpful, enjoyable: Bruno Ruviaro - A gentle introduction to supercollider https://ccrma.stanford.edu/~ruviaro/texts/A_Gentle_Introduction_To_SuperCol= lider.pdf Eli Fieldsteel's (classic) tutorial series: https://www.youtube.com/watch?v=3DyRzsOOiJ_p4&list=3DPLPYzvS8A_rTaNDweXe6PX= 4CXSGq4iEWYC + all the helpfiles and examples! I also come from a purely composer's background and have only been learning for 6-7 months (though headfirst). After that and some practice I did find a lot of pleasure following emails, gleaning infos here and there. even reading something you don't understand (at all) may come back to you later when you need it and lead to exciting new possibilities. I would also suggest the forum where things are moving, the responses range from very technical to purely usage, whatever you're after. like edN said what matters most is your sustained desire to do what you love. i just want to share another beginniner's perspective for all the people who devoted some time here - I actually found the existence of this mailing list very encouraging ! best, Max Le jeu. 10 juin 2021 =C3=A0 15:19, <[email protected]> a =C3=A9crit : > 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 methodolog= y > is not compatible with the colour of code, it will be difficult to make t= he > 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 a= s > 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, noo= ks > and crannies of technique are inaccessible. Thus one relies on the few > masters or veterans (or maniacs) who have a virtually total command of th= e > 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 professiona= l > 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 o= r > conventional musical background, e.g., as a pianist or (shudder) trumpet > player, the lack of 'touch' or 'connection' to the music making process i= s > 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 throu= gh > 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 wha= t > 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 tim= e 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]> <jamshark70@gmail.= com> wrote: > > On Tue, Jun 8, 2021 at 9:27 PM <[email protected]> <maxlouis.raug= [email protected]> wrote: > > I=E2=80=99ve always wondered why the Pattern class' library doesn=E2=80= =99t 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=E2=80=99t really like (what I understand of) its conception of tim= e - 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-studi= os/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/ > > --000000000000eea03905c46c6af0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><div dir=3D"ltr"><div dir=3D"auto">Hello everyone,</div><div><br></div= ><div>James, thank you for your response.</div><div><br></div><div>... I do= n't think patterns are useless ! My apologies if i gave off that impres= sion. I do use Patterns sometimes and am quite aware/in awe of their potent= ial, hence my curiosity. I just get a bit stuck composing with continuities= , for which i might have an aesthetic bias like you say (i do not write ind= ian music at all but please check out the video on Gamakas if you want a di= fferent, not so personal context) and i was quite happy to find a simple fi= x with Varlag=C2=A0+ Pseg + Pmono. <br></div><div>As for the 'grid'= - there is such a thing as unstructured grids. I didn't mean to say it= 's consistent or repetitive, just that the Pattern Class seems to be ba= sed on steps / discrete events, which i now understand is inherent to the c= omplexity of writing such an abstraction. Strong choices have to be made in= the conception of something as diverse and powerful. I'm perfectly hap= py with it as long as i know this is the way it is !<br></div><div><br></di= v><div>Pauline, here are two tutorials that I found very accessible, helpf= ul, enjoyable:</div><div>Bruno Ruviaro - A gentle introduction to supercoll= ider<br></div><div><a href=3D"https://ccrma.stanford.edu/~ruviaro/texts/A_G= entle_Introduction_To_SuperCollider.pdf" target=3D"_blank">https://ccrma.st= anford.edu/~ruviaro/texts/A_Gentle_Introduction_To_SuperCollider.pdf</a></d= iv><div>Eli Fieldsteel's (classic) tutorial series:<br></div><div><a hr= ef=3D"https://www.youtube.com/watch?v=3DyRzsOOiJ_p4&list=3DPLPYzvS8A_rT= aNDweXe6PX4CXSGq4iEWYC" target=3D"_blank">https://www.youtube.com/watch?v= =3DyRzsOOiJ_p4&list=3DPLPYzvS8A_rTaNDweXe6PX4CXSGq4iEWYC</a></div><div = dir=3D"auto">+ all the helpfiles and examples!</div><div><br></div><div dir= =3D"auto">I also come from a purely composer's background and have only= been learning for 6-7 months (though headfirst). After that and some pract= ice I did find a lot of pleasure following emails, gleaning infos here and = there. even reading something you don't understand (at all) may come ba= ck to you later when you need it and lead to exciting new possibilities. I = would also suggest the forum where things are moving, the responses range f= rom very technical to purely usage, whatever you're after. like edN sai= d what matters most is your sustained desire to do what you love. i just wa= nt to share another beginniner's perspective for all the people who dev= oted some time here - I actually found the existence of this mailing list v= ery encouraging !</div><div dir=3D"auto"><br></div><div dir=3D"auto">best,<= /div></div></div><div><div dir=3D"ltr"><div>Max<br></div><div></div><div><b= r></div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 10 juin 2021 =C3=A0=C2= =A015:19, <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>> a =C3=A9crit=C2=A0:<br></div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= rgb(204,204,204);padding-left:1ex"> =20 =20 =20 <div> <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 i= s 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 'conn= ection' to the music making process is going to present an enormous cognitive disconnect. This is similar to the 'coded music' co= mment above. The upshot, if you need 'touch' or immediacy in your m= usic 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>On 2021-06-10 12:34 a.m., <a href=3D"mailto:[email protected]" target=3D"_blank">paulineu= [email protected]</a> wrote:<br> </div> <blockquote type=3D"cite"> <pre>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 href=3D"mailto:[email protected]" target=3D"_blank">jamsha= [email protected]</a> <a href=3D"mailto:[email protected]" target=3D"_blank= "><[email protected]></a> wrote: </pre> <blockquote type=3D"cite"> <pre>On Tue, Jun 8, 2021 at 9:27 PM <a href=3D"mailto:maxlouis.raug= [email protected]" target=3D"_blank"><[email protected]></a> wrote= : </pre> <blockquote type=3D"cite"> <pre>I=E2=80=99ve always wondered why the Pattern class' libr= ary doesn=E2=80=99t seem to allow for continuous change... </pre> </blockquote> <pre>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&q= uot; 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=3D"cite"> <pre> I don=E2=80=99t really like (what I understand of) its conc= eption of time - as a grid that underlies and cuts everything </pre> </blockquote> <pre>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=3D"cite"> <pre>strictures the organic-abstract potential of audio synthesis </pre> </blockquote> <pre>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 href=3D"http://www.birmingham.ac.uk/facilities/ea-studios/research/super= collider/mailinglist.aspx" target=3D"_blank">http://www.birmingham.ac.uk/fa= cilities/ea-studios/research/supercollider/mailinglist.aspx</a> archive: <a href=3D"http://www.listarc.bham.ac.uk/marchives/sc-users/" targ= et=3D"_blank">http://www.listarc.bham.ac.uk/marchives/sc-users/</a> search: <a href=3D"http://www.listarc.bham.ac.uk/lists/sc-users/search/" ta= rget=3D"_blank">http://www.listarc.bham.ac.uk/lists/sc-users/search/</a> </pre> </blockquote> <pre></pre> </blockquote> </div> </blockquote></div> </div> --000000000000eea03905c46c6af0-- _______________________________________________ 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/