#95

I’m still sticking with my original argument that for this kind of person:

C would be intimidating to start with, and in that sense would be hard and inaccessible, and that they could probably encourage themselves to get into programming more easily by sending a bang out of a button in Max than by starting with C. Also I like this point:

You get positive feedback much more easily and quickly.

I think @alanza has really summed this up best:

3 Likes
#96

Programming didn’t really stick for me until I started using it to make music and sound. That gave programming a purpose.

It also helped that I was determined to make music entirely on Linux, for whatever reason. There wasn’t much commercial music software available at the time, so (thankfully) Linux forced me to write my own tools. Also, Linux has such a dev friendly environment. The Unix approach to development is so simple and straight forward.

Oh! And this is critical… Csound. I was learning Csound because it was a sophisticated synthesis engine that could run on Linux. One of the best things about Csound is that it is text based synthesizer. It was trivial to write programs to generate Csound code. A little went a long way too! These programs weren’t just toys either. While simple, they were actually very practical. At the time, I was learning a little bit of Python and Perl.

Finally, learning Vim was a huge help. It’s a great text editor. But more importantly, it unified the physical experience of coding into a single interface. Instead of learning a new IDE for every language I wanted to learn, I just did it all in Vim.

7 Likes
#97

I first got a taste of programming in college using R for Bio-stats. I was pretty late to the game in 2008. But my curiosity in programming stems from that semester using R. My knowledge base was essentially nothing, but I went through periods of personal breakthroughs and growth, and periods little to no gains. I still use R today, but more regularly use VBA and SQL for work, both of which I learned on my own and went through a similar growth process.

#98

To expand entirely too much on my well-meaning shitpost:

You can make a beep with a computer with simple programs in lots and lots of ways! Some of them are certainly more interesting than others. This “hello world” variant should work in basically any language you can use to write a console program on the desktop. Printing the BEL character (escape code '\a') to the terminal exactly like this is probably one of the first ways I ever deliberately made a program make sound, I think a friend and I even had some goofy C or C++ program that would beep repeatedly this way with some pseudo-musical timing by just using spin-wait delays.

If one’s goal is to build specific effects or tools for audio processing, there are lots of awesome environments where this is going to be a lot less work than other ways you can go about it. Many of these will let you learn programming while also getting to do real-time audio stuff, visual programming, etc. out of the box, and that is very satisfying and can be very productive. But I think that if one’s goal is to learn to program, C can be a great place to start. It has relatively few syntax elements, it allows very direct manipulation of memory and files, it challenges and teaches valuable techniques through its constraints. It is also scurrying around somewhere underneath the feet of basically any other programming environment you come across. Writing software you will some day be well-served, especially if you want to involve real-time signal processing, by having a working knowledge of C. There is a learning curve as far as understanding the language building blocks but that’s true in every language or environment.

My immediate reaction to the sentiment that audio programming in C is too complicated for beginners to learn to make something musical before getting frustrated was “what’s the simplest C program I can write that makes a sound?” and I think that this would be a super fun way to structure a C tutorial – every program somehow makes sound, either by playing it directly, by creating a file, or other means. You can also use a lot of great libraries for abstracting away a lot of the complicated bits that you don’t want to deal with, nowadays there are even pretty good package managers for writing C/C++ programs. Here is an example I set up which uses Conan to install the cross-platform PortAudio library, then build the paex_sine.c example file to play a 5 second (loud! turn your volume down) sine wave. This should work on any platform as long as you have a C compiler and Python installed. That is easier said than done on some platforms but still I think fairly comparable to setup procedures for most programming languages. This also hides a fair number of details that it is also important for beginners to understand that don’t directly relate to the programming part – invoking the compiler, including and linking, etc. – but I think these can also be learned incrementally side-by-side with the actual programming part.

There is something really special about programming C or assembler that is hard to separate from how I think about software. Especially on a platform like a microcontroller with no operating system where nothing is write protected and writing to some addresses can do something tangible, there is a feeling of glimpsing what the machine actually is, encountering at once its elegance and power and fragility and capability for self-destruction, making lights blink and steppers step and BEEPS! I would most likely not have learned “how to program” in any practical sense, or at least would have had a much different path there, had it not been for my early experiences programming C. I value that a lot and having some of those engrossing experiences is something I wish for all programmers, beginners or otherwise.

That said, I frequently prefer to actually try and do music things inside environments where the hard work of building the tool, or at least the workshop, has been underway for a while – there is a framework in place where I can focus on “application logic”. Thankfully there are tons of platforms now where this is possible, and many of them can be easily extended in C, enjoying immediate interaction with the data without having to lay the groundwork first. On the other hand, living in a software environment you built yourself in some way is wonderful, the feeling of knowing roughly where to find things, or of understanding at a glance the complicated chain of events that would result in the bug you’re looking at, and feeling like you know where the secret tunnels go.

My first encounter with the concept of a computer program as something that could be written was stumbling across AppleScript on what I’m almost certain was called a Macintosh SE II, but Google seems unconvinced that such a model existed. Perhaps it was an SE/30? I had no clue what I was looking at, or what a “syntax error” was, which was all I could get it to say for a long time. I was looking for video games. I guess I came back to it enough times that I eventually figured out there was a record button, which would convert whatever else you were doing on the computer into text! From that I figured out some basics about available commands, and I managed to program it to, like, open a folder and slide the window around the outer edge of the screen. This would have all been copy-pasting and editing stuff the macro recorder spat out, I don’t think I had any concept of flow control until several years (and programming languages?) later. My parents seemed confused, but supportive.

After that I feel like K-12 was only occasionally punctuated by intervals in which I was not farting around trying to teach myself to program something. Misadventures included: endless if-else trees of Visual Basic dialog boxes composing a short and deeply uninteresting choose-your-own-adventure text game, being given and reading the first chapter of a half dozen or so different books on C++ before getting bored, a stream of harebrained toy programs, failing to understand some web tutorials on SDL and OpenGL in service of some nebulous fantasies about making video games, really bad Geocities-cliche type websites making prominent use of <embed src="ff3_kefka.mid"> and bearing no regard for the idea of a “closing tag”.

In retrospect I think I was a pretty awful and unfocused learner and absorbed way less from these experiences than I could have, not for a lack of trying on other people’s part. When I was introduced to microcontroller programming in high school something clicked, I started to understand why C was designed this way, which I don’t think had really been conveyed in the course of my earlier attempts to learn C++. After that I started to get more serious about it, went to college, yada yada.

5 Likes
#99

tbh I feel like the thing that intimidates me more about DSP at the C level is the additional understanding of sound rather than code. It’s not a huge mental leap to write code per sample and the syntax isn’t rlly that bad, but I’m too used to the mathematical stuff that even shitty max/msp objects have baked in (i.e. filtering, interpolation, unit conversions).

feel like there’s a lot more resources for learning code compared to audio/digital sound - though maybe this is a good place to ask abt that.

#100

The STK has a lot of these low level building blocks, plus some exotic things like banded waveguides.
https://ccrma.stanford.edu/software/stk/

3 Likes
(Modern) C Programming Tips and Tricks
#101

i agree - the point i was trying to make is that “DSP at the C level” is just “DSP.”

the question was “how did you learn to program.” for me and a lot of people, that was with C, and it continues to be useful. i still think that in an objective sense that is the “best” way to learn programming, which is not the same as learning computer science or audio DSP - C is ubiquitous, simple, performant, close to the machine; it forces you to learn about abstraction and architecture; there are an endless number of high-quality resources, libraries, and examples; and unlike Max/MSP it is free.

but really the “best” way to learn something is to do it, and in this context the language is probably not as important as just having a project and executing it from start to finish.

since my livelihood involves coding, i also continue to do exercises on codesignal.com whenever i can and in as many different languages as i can, to stay flexible. i highly recommend doing this; it is very helpful for me to be able to read and modify code in ruby, haskell, dart, kotlin, swift or whatever. similarly, rosettacode.org is a cool resource.

now you can use gen~ or WebAudio to very easily process a block of audio samples. which will not teach you much about programming. whatever, many/most people don’t actually want/need to be general programmers.

learning DSP and math is definitely harder. it’s been discussed quite a bit on various threads and there are a lot of book recommendations. my personal favorite is probably the steiglitz primer which is admirably short, clear and to-the-point.

13 Likes
#102

Thanks for these tips.

I’m in an odd place right now with regard to programming. Started coding at the age of 9, and did it professionally from '98 to '06, but have since drifted further and further away from coding as a primary pastime.

So, now I’m looking at starting over. In some ways it feels like starting from scratch. It’s pretty exciting, but also in many ways just as overwhelming as the first time through.

Has anybody else come back to coding after a long hiatus? I was a pretty solid coder back in the day, but I’m so rusty now that I’m lacking all confidence.

1 Like
#103

BTW, i’m also a fan of the pragmatic programmer.

for me, the biggest challenges in the craft of programming are not gaining fluency in syntax or algorithms. those are the fun parts, which can be easily pursued as a hobby or game. the hard parts are things like managing project scope, defining requirements, establishing unit tests, refactoring, and all the “other stuff” that you can’t learn from a language reference.

8 Likes
#104

While we are talking about great sites to “practice” programming doing https://adventofcode.com every year is incredibly fun for me, and serves as a nice refresher for more algorithmic knowledge.

1 Like
#105

I hear ya. DSP code at the C level is mostly a bunch of arithmetic operations and trig operations. You can’t look at C code and grok it the same way you can with other data structures and algorithms IMO. You need to really know the mathematical notation.

2 Likes
#106

If you’ll permit me to continue bantering with you about this long past the point of productive conversation, let me I guess sketch my relationship to coding for sound / other things. I agree that in some sense this will be The Wrong Answer.

Programming has never entered in any large capacity into what I do professionally. I really like it, and I see improving my skills as what I hope will be a lifelong practice. But, I really am a diletante here; for me it makes sense to wade into writing it all myself slowly.

And really, I guess there’s a slippage here. I’ve been saying all of these things as if they were complaints about the C language, but really what is going on is that I don’t know how the sausage is made: It took me a good week or more of snatches of time reading in order to accumulate an understanding of what is going on in the SVF implementation you very kindly suggested to me, and a month to grok the oscillator code I wrote. Of course one doesn’t need to understand everything about something in order to dive in, but one reason I don’t use more pure C is in order to allow myself to dive into writing things myself when I would like to, and not when I wouldn’t.

In other words—I don’t know much DSP, much less interface writing, so abstracting it away is helpful for finishing things. I know somewhat how to learn it, where to look, etc., and actually I feel well-prepared to learn all these things when I have time. But until then, the convenience of something aimed higher (in terms of abstraction) is helpful.

6 Likes
#107

As usual you find a way to put into clear and precise language a thing I was struggling to gesticulate about (in my head, though public gesticulation is not unknown for me).

1 Like
#108

this is v v much in line w/ my experience in creating my own tools. I actually really hate both max/msp and ableton, but I’ve stuck to both really firmly just bc there’s a bunch of things they can already do. like, uh, recording. and volume.

my dream and goal is to write a tool that I’ve built from the ground up, but for right now I gotta figure out how to go and make some gosh darn music, so I don’t go off and make a tool designed entirely around stuff that I don’t need (which I’ve done, alot,).

so I feel like you really need something extensible to make this system work. wish some of those things were better (& open source >:| ), but we got what we got.

4 Likes
#109

i agree. there’s some slippage (which is fine.) i jumped in the thread on a whim, b/c i saw @csboling’s fun salty beep post and the response, and thought it would be a fun counterpoint exercise to try and implement a major scale of sinewaves in C, concisely and clearly, and see how long it would take with no dependencies (answer, maybe 10-15 minutes. this would be a great interview problem.)

following is a rambly Too Long bunch of thoughts that will probably close out my involvement here for the time being.

as often happens, i think the discussion has uncovered some important points here, one of which is that “programming” or the verb “to program” can encompass a variety of tasks.

to me, “programming” always been a sort of fundamental tool for implementing parts of all kinds of systems. in my own experience those have include audio hardware / firmware / software devices, but also quite a few scientific research projects and some other kinds of HW/SW products.

the more projects i’ve done, the more my concept of “programming” has broadened. it is a craft that encompasses many considerations beyond the algorithmic. projects have a tendency to grow in scope. the more stuff your platform can do, the more true this is.

e.g.:
ok let’s make an interactive sound sculpture…
what if we add a bluetooth chipset to that… and a camera… and a webserver…
and and… and suddenly my architecture has grown from having to process a stream of samples, to a dizzying tapestry of processes, threads, data streams, platforms, protocols, and libraries. that’s where things fall apart without serious attention to craft. (so maybe what i need to know is “how do you learn software architecture” or something.)

maybe a more relevant point: how to learn really depends on what kind of goals you want to be able to achieve. the assumption is that we’re talking about audio synthesis and processing. clearly, there are many tools that do low-level audio manipulation well. the only reason i can see to go to the sample level is to experiment with algorithms. ironically, as @PaulBatchelor has pointed out, probably the best way to experiment with audio algorithms programmatically is with a high-level and possibly domain-specific language. there are some standouts:

  • Faust in particular is kind of a killer app if you are comfortable with the functional paradigm and expressing algos as signal flow. (TBH, i haven’t personally gotten as comfortable with it as i’d like for eperimenting at low levels; usually i have to have a super clear idea of what i want to do first. for building strings of blocks and cross-compiling them, it’s great.)

  • Octave/Matlab is the de facto standard for a lot of academic and engineering work, and comes with many tools for visualization, numerical analysis and optimization, &c. (SciPy is also becoming very popular; i still find python sort of a drag to work with personally). it’s a one-liner to export an Octave matrix to a soundfile. (audiowrite('foo.wav', data, samplerate)). pretty much everything i do algorithmically starts in Octave before becoming C code; i’ll write DSP test cases in Octave and re-use them on the C output.

  • C/C++ get honorable mention from me here because they are the bedrock languages, learning them is good for you, and they can extend all those other environments. there are many, many ways to deploy C in audio programs without dealing with the boilerplate: write a JACK program, VST plug, Audio Unit, JUCE app, csound opcode, PD external, use libsndfile, use soundpipe, alt firmware for your favorite Eurorack computer, &c &c.

(i’ll emphasize again that the hard part here is understanding what operations produce what results, and not actually performing the operations.)

if you don’t want to work at the low level of the DSP (you want to string together building blocks and probably control them with musical logic), then there are the usual suspects, largely to taste:

  • textual (csound, supercollider, chuck, sporth, &c)
  • patching (pd, max, reaktor, bidule, &c)

you absolutelydo not have to know much DSP math to effectively use these things; that is of course their basic reason for existence. the further up you go in terms of abstraction, the less this activity resembles general-purpose programming. (which is fine! i’m all for stepping away from, like, Instruction Set paradigms.)

the core concepts of “programming” for the purpose of processing audio can be absorbed in a day. digital audio is just a stream of numbers. loop over them and perform a handful of arithmetic operations and “that’s it.”

nobody does everything “from scratch.” very few people would ever get anything done. PD uses Tcl/Tk to implement the UI, Max uses JUCE. (Tcl/Tk is a scripting language with a GUI toolkit built in C; JUCE is a C++ framework wrapping native rendering with a lot of helpful abstractions. C and ASM are abstractions. it’s turtles all the way down. i haven’t even seen applications of substantial scope written in ASM since the 80s, and frankly… those people were maniacs. (ok, shlisp is done in ASM, and peter B is also kindof a maniac, but that’s a set of opcodes and much simpler.))

for all my evangelizing about learning C, it’s not because i think doing stuff at the low level is particularly smart or cool. usually it’s not the most efficient way to do some particular thing (because there is a domain language / framework / library / program / device that already does that thing.) i recommend it for pragmatic reasons, because knowing C/C++ (and now, JavaScript) allows you to see into such a large amount of what’s going on in the digital world.

if the context wasn’t specifically about audio, i would say just learn (modern) javascript. syntax is clean, there are tons of resources and tools, computers are fast and it’s not just for websites anymore (e.g. Orca).

in the context of audio, learn C. you need the performance and it will help you customize everything from Max to modular.

“real programmers set the universal constants at the start such that the universe evolves to contain the disk with the data they want.”

20 Likes
#110

just wanted to pop back in say that i’ve appreciated all the responses to my initial question, and i’ve had a lot of fun reading the discourse in this thread that hasn’t been directly related to my question. i really enjoy this community and admire y’alls knowledge and grace. :bouquet:

2 Likes
#111

i need to amend my statement. i’ve tried to learn max i believe three times. third times, you know… :sparkles:

@andrew has been inspiring me w/m4l devices and i’ve been wanting to port old patches in for years. i started learning french in duolingo and have been enjoying that process deeply, and so it reminded me: i can learn a new language.
@Rodrigo is beyond amazing with his ideas, execution and generosity of patch content and time.
last night i had trouble sleeping because i was so excited about a stupid simple idea i had for the port i am working on.

i couldn’t get very far without teachers but this time it is feeling much better. so what i mean to say is that i am learning max right now. @dan_derks recommended a lot of things and continues to help, the kadenze max course has been helpful and a good place to start. my first port to m4l was a @RABID @rajatheresidentalien @CrackaAttacka patch that has been so close to my heart and practical application since well into the old forum years. miss u raja!!!

this place is amazing and it is time to post in the the coffee thread

and @sandy has been such a kind soul egging me on in my king port patch modification dreams of the chocolate grinder FOREVER. it will happen.

9 Likes
#112

@dude forgot i had this account, and that it had notifications on :see_no_evil:
…until you tagged me :laughing:
(sorry i’m not much on forums anymore, sometimes i visit cycling74’s forums, but not frequently, hope no one takes it personally, just got my focus elsewhere these days).
Truly grateful to hear that I helped you in some way, though. It gets easier and easier in an exponential way, but the universe needs you to meet it half-way first,
so keep going forward! :raised_hands: Never look back. :eyes: FOREVER! :muscle::stuck_out_tongue_winking_eye:
And you’ll always find more joy just around the next corner in this crazy world of artsy fartsyness and tech :joy:
Grateful for your continued awesomeness :pray::innocent: Be well, All the best :beers:

5 Likes
#113

dang, kadenze looks awesome. i’ve been wanting to learn max too. i will have to give the kadenze course a shot.

if you have any other pointers or suggestions of helpful resources, give me a shout!

#114

i am the last person to give learning advice on this topic as it has taken me years and years to even get motivated to learn the barest beginnings of max.

what i am doing these days is a mix of max tutorials (there is a d/l for the delicious tutorials from max packages section (which i have not tried (in that format) yet)), dissecting/exploring patches i love, kadenze (very slowly). i control click on objects and explore examples constantly. i try to engage learned friendly folks for thoughts. i’m reading max threads and lightly dipping toe into max forums (mostly finding amazing max4live patches). hoping to collaborate on ideas with others.

but my main thing is trying not to lose fun so i encourage having fun while mixing in some learning so i let abstractions happen naturally otherwise it is so dry. that was what stopped me in learning tracks the first 2 times.

7 Likes