Follow

does it makes sense to invest time and energy to write music in C (as in programming language, like C99/C11/C18) as opposed to write it in ? which of those will get obsolete or have too much backward incompatibility?

( inspired by @neauoire )

@luka I would say that supercollider is a construct around C++ (like puredata/pdlib) and so would live as long as C++ ... and I've known them as being active while niche for more than 15 years ... so I would say SC is pretty "secure" ... @neauoire

@Olm_e @luka yeah, when you say C99, do you mean like you found a way to do livecoding in C?

@neauoire @Olm_e @luka as for *live coding* audio in C, this project might be of interest:

mathr.co.uk/clive/

@mathr develops AND performs with this.

@neauoire

no, wasn't thinking about livecoding. more like, how can the music-in-code be preserved. like, if one writes a complete album in SuperCollider, will it be playable (executable) in 10 years time? if one writes it in C, and even provide an executable binary... will it have more chance to be compilable and/or executable in 10,20,30 years?

@Olm_e @paul

@luka @neauoire @Olm_e From what I've heard, the SC peeps are pretty good these days about preserving backwards compatibility, especially for the older UGens. 10 years is a pretty safe bet for things still working.

I can tell you firsthand Csound that puts an insane amount of effort into conservation, to they point where they will not accept bugfixes for older opcodes, in case some composer is exploiting it somehow. There are still pieces written in the 80s that run on the latest version of Csound no problem, so I'd say that is pretty good. Several works, demos, and instruments from the MUSICN languages have been ported to Csound, and those reach all the way back to the 60s.

@luka Going the C route, hardware agnostic ANSI C code is the best way to go. Write programs that generate audio files offline, and don't bother with things like GPUs, threading or realtime, as those things are a moving target to support. Also, only rely on the standard C library and use no external dependencies.

This is what my Soundpipe project aims to be: github.com/paulbatchelor/sound It's written in C99 with none of the C99 extensions. By default, it has libsndfile as a dependency, but this can be disabled.

Again, I tried and failed to make music using only C + Soundpipe. Change->compile->render->listen took too much time, and it hindered the music making process. You are very welcome to try.

@neauoire @Olm_e

@paul

wouldn't it be possible to write a REPL shell that is not necessary for final executable, but just to monitor your work in soundpipe?

sorry if I'm asking stupid questions, since I don't know C.

@neauoire @Olm_e

@luka @neauoire @Olm_e

It is more trouble than it is worth making a repl for C work IMO. There are just so many small gotchas with that language. What you can do is write a very simple domain-specific language or VM in C that can be parsed and used to efficiently synthesize sound in soundpipe, and then build a REPL around that. For instance, it is pretty trivial to build a stack-based language in a small amount of portable C code, and then use it to generate graphs.

In fact, I did just this: github.com/paulbatchelor/sport

I went with the stack-based language because I read somewhere it was easy to build, but it actually turned out to be a great way to convey complex signal chains. The REPL came a bit later for it.

My process today is a little bit different now, but it is based on the same idea. I use something similar to Sporth, but I use Scheme code to generate/evaluate it in realtime. So Scheme generates low-level DSL code, which then in turn gets evaluated into an efficient audio graph data structure in C, which uses DSP code from Soundpipe. It's a pretty great setup because I can be very creative with the high-level language, while still having access to the low-level DSP layer in C when I need it.

@neauoire @Olm_e @paul

also, another idea based on writing your music directly in C is to optimize all processing so one could use a very cheap small board with some embeded (linux?) system that would allow running an executable binary - the album - and output audio through a headphone jack - generative/algo music medium kind of thing for physical distribution.

@luka @neauoire @Olm_e Totally on my wavelength actually. It's still a WIP for me. I've actually gotten to the point of just doing away with operating systems all together.

I have a bunch of raspberry pi 1 computers lying around my house, and managed to build a proof of concept bare-metal sound example that runs a sine wave oscillator generated via Soundpipe on the pi 1 onboard dac: github.com/paulbatchelor/pisin

With some tweaks, I bet I could get it working on newer devices.

@luka @neauoire As someone who for a while did try to write music only in C (after years working in Csound), absolutely not. I found that for every musical idea I had, I had to adjust several lines of C. It felt really slow to me. The creative feedback loop was really lacking. I ended up building a language on top of that C library.

Being able to understand/control a system down to the C level is a very very rewarding thing to have, though!

@luka @neauoire

who knows the future?
both should be ok (although c a better bet than supercollider for longetivity, imho)

i would encourage you to also consider which of these languages appeals aesthetically to you (as i expect you will be spending a bunch of time "translating" (programming) the sounds you hope to produce in the language you have chosen).

regardless, best wishes for the project.

👨‍💻

@js0000

Yes, you're right, this consideration is important too. I thank you for it. 💙

@neauoire

Sign in to participate in the conversation
SoNoMu

SoNoMu (Sound Noise Music) is a mastodon instance for musicians, sound-artists, producers of any kind of aural noise, songwriters, bedroom producers, sonic manglers and algorave livecoders. -> more...