[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] Pbind question



A recent thread in this list is about how the sc-list is going to disappear very soon. My understanding is that, an archive will be created to keep all the past messages, but no future messages will happen anymore (but there is a forum too).  I have been subscribed to the sc-list for eight or nine years already.... Why I did it? Homework. :D

...From my experience, the sc-list was glowing with concrete examples around the years 2014-2015, and during that time, lots of people were participating. I would really recommend looking back to those posts, and take the patience of evaluating the codes. Also from that period, you can find other"broader" historical, philosophical, rhetorical discussions about SC, music and mathematics, sc-quarks in existence, live coding, physical interfaces, etc

My general opinion is that, as you say, this list is not meant for learning SuperCollider. It is more of a resource to help individuals solving or discussing some of their very particular problems with SuperCollider. But if you have lots of questions, and you post them all in here, you might not get an answer for most of them (only one or two). A good hack to deal with this is "instead of posting all the questions at once, ask one, and then wait like a month or so to ask another question." But if you just complain about SC or if you just ask very general questions, then people might answer in a very general and bored manner in return. Otherwise, if you provide a more concrete code which for some reason didn't work as expected, people might provide a great answer in return. Slack and lurk chats are better suited for knowing the community (my opinion). 

As this list is dying, it is possible that some current answers will not come with the same energy if asked today as the answers to similar questions that were posted in the past. Because people get tired of answering the same things over and over again. So a research and motivation from your part will be expected. And It is very noticeable when a question lacks these things. 

Another recommendation I would give, is, download Miscellaneous Lib, and play with it just for fun! It has tons of examples, and it is very well documented. This library is soo thrilling, and the code is never broken; it even has GUIS, and lots of them! The craziest, but simplest Synthesizers can be found here too. Maybe it would also help to read some articles by Daniel Mayer, and to know that he also teaches a synthesis course at IEM Graz, Austria. If you are very interested in learning SC, maybe you could go to a place for learning it, with the adequate tutors, and environment (with people who also want to learn SC in a richer level). 

Maybe you could also try to take private SC lessons from other people, if your current SC lessons do not suffice (for whatever reason). Some people that come to my mind are: Sergio Luque, Charle Hutchins, Bruno Ruviaro, Daniel Mayer, Julian Rohrhuber, Fabrice Mogini, Konstantinos Vasilakos, Nick Collins, etc Some of the names I'm giving might only give lessons through a university course, though :( 

I do beleive SuperCollider is not for everyone. First of all, programming languages are difficult, and you have to be willing to learn it with the patience and craft that it requires. But maybe you could just try to do a few things with it, instead of learning everything about it. I myself am not a SuperCollider expert, and probably will never be one. I only use it as an ocassional tool, and for some specific purpose in mind. What I personally enjoy the most about it is Patterns, and Ugens. But ask me about signal-processing, Fourier Transforms, Convolution and all that, I don't know a thing. 

My last advice would be: try to make a team of people to solve sc-problems, as this also provides a way to learn lots of computing. Many heads think better than one, and sometimes the solutions just come up in this way.

It was lots of fun to be in the list, and I made some abroad friends along the way. So Congrats for having achieved this great community! :/




On Wed, Jun 9, 2021 at 11:35 PM <paulineugalde@xxxxxxxxx> 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, jamshark70@xxxxxxxxx <jamshark70@xxxxxxxxx> wrote:
> On Tue, Jun 8, 2021 at 9:27 PM <maxlouis.raugel@xxxxxxxxx> 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: https://listarc.bham.ac.uk/marchives/sc-users/
> search: https://listarc.bham.ac.uk/lists/sc-users/search/
>


--
"I LOOK FORWARD TO CREATING A NEW FUTURE WITH YOU."

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


--
Ofelia Negrete
ofeliayorquesta.com