Hi all,

I made some pushes to my "diet_csound" repo, doing some further slimming and unused directory removal, in addition to making the build instructions more on-point and minimalist. Also, added a `build.sh` building script which should work for most people, at least on Linux, provided they have a C/C++ build system in place and the core dependencies installed, per their OS.

The repo is now at commit `e1ecaaf`.   https://github.com/akjmicro/diet_csound

On another note, if anyone is interested in the project, I would love feedback and non-Linux build testers. It's working great, builds fast for me, etc. But on your alternative OS, it might set your computer on fire, who knows. I'd love to help.

Background on this: it has long been a personal pet-project of mine to have a custom build of Csound that stripped-down and removed much of what I felt was "non-essential" opcodes. Csound is an old and mighty project, but because it is like a giant snowball that has collected everything it has touched over the decades, and every whim of every dev who has worked on it, and has collected every opcode that makes every sort of noise, broadly useful or not, it is, well, BIG in every sense of the word. Because it's BIG, it has also taken longer and longer to configure, collect dependencies for (needed or not) and compile. For me, waiting for a compile for some opcode or feature set that I happen to know I won't ever use became something of a "pain-point", to use that modern dev/user conversational term.

<< It might be argued that csound's binary executable isn't _that_ big in a modern sense. And the compile isn't _that_ painful. And, well, they'd be right. So, if it helps, call this an OCD obsession of sorts; a ruthless desire for pursuing minimalist and clean coding practices. For those with me, read on... >>

Taking my fate into my own hands, and not waiting for someone else to solve _my_ problems (and why would they be motivated to, anyhow, this is ridiculous OCD after all?), this project is my own _personal_ vision of what it would be like to strip away "the noise" and have (an arguably subjective, again) a set of essential DSP opcodes of near universal utility. If it's intriguing or useful to others, who knows, I make it public for me and the 1 or 2 others who are curious...the rest can continue using the full non-reduced standard Csound. Those interested in a lean and mean version, and arguing over what should be essential or not, (lol), I invite you to the conversation. If it helps, having used Csound for decades, what I consider essential her may grow, and I might re-add things, but for now, what's gone:

• Opcodes that are not considered "best practice", even by users and devs. So, instead of telling me "best not to use `oscil` in favor of `oscili`", why not just stop providing `oscil`? There are many examples in the manual, too many to mention, The "deprecated" ones I was aware of, I simply removed. I'm not considering breaking things and backwards-compatibility, frankly. I was guided somewhat by the suggested "core opcodes" listed in the FLOSS manual here.
  
• Opcodes that are "gee-whiz toy noise-makers" (to me). I'm looking at you, `lorenz` and `planet`. If I'm wrong, argue with me! I'm not going to use them in my music, anyway. So sue me. I'm not arguing that they aren't fun to some...
• Opcodes that are unstable and can blow up and can cause hearing loss...where the manual warns you "you can play with this, but BE CAREFUL". Csound I am sure has already deafened me more than once where I was dumb not to wrap things in `limit` or something, and had to rip my headphones off at lightning speed. Anyone else been there? I'm not going to encourage those kinds of opcodes on my watch!
• Lots of opcodes that are arguably of intense utility and artistic purpose for lots of people, but tend to use a lot of CPU more than most, or are ones that I personally, lately, haven't used much. So these are on the fringes and maybe can be optionally built in future versions of diet_csound. FFT ones come to mind as a main representative of this category. Some of you may swim in this world all day every day, and have that as a focus. For now, you will find little compelling about diet_csound, then. For now. My focus has been making mostly traditional synths, and sometimes samplers-based synths. And so, designing opcodes with Faust and pulling them in to improve the sound and utility of what csound offered out of the box (i.e., frustrated with the wgpluck, pluck, repluck family being out-of-tune b/c of delay-line quantization, I turned to rolling my own "pluck" via Faust and pulling it into Csound's framework...

One other note: I have found that some of my reorganizational efforts for this fork _may_ be appealing to the main devs, and, even without removing a single opcode, the cleanup and module organization would, I think, make for a more logical "it makes sense that this thing lives in this file" layout, something I would argue isn't true of the current `master` and `devlopment` branches. I can lay out that argument to the devs elsewhere if anyone is interested. Many of the things I'm thinking of seemed to be put in place willy-nilly, and b/c the app compiled and worked, they stayed put...

All best,

Aaron.

Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson

https://soundcloud.com/filtercreed

https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg

https://aaronkristerjohnson.bandcamp.com/

http://www.untwelve.org

Code:
https://github.com/akjmicro

Slight correction -- I realized, I did keep `oscil`, even though it's often advised against for quality sound -- the reason being: arguably the best way to get low-fi/8-bit aesthetics.

Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson

https://soundcloud.com/filtercreed

https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg

https://aaronkristerjohnson.bandcamp.com/

http://www.untwelve.org

Code:
https://github.com/akjmicro

On Sat, Jan 27, 2024 at 11:47 AM Aaron Krister Johnson <akjmicro@gmail.com> wrote:

Hi all,

I made some pushes to my "diet_csound" repo, doing some further slimming and unused directory removal, in addition to making the build instructions more on-point and minimalist. Also, added a `build.sh` building script which should work for most people, at least on Linux, provided they have a C/C++ build system in place and the core dependencies installed, per their OS.

The repo is now at commit `e1ecaaf`.   https://github.com/akjmicro/diet_csound

On another note, if anyone is interested in the project, I would love feedback and non-Linux build testers. It's working great, builds fast for me, etc. But on your alternative OS, it might set your computer on fire, who knows. I'd love to help.

Background on this: it has long been a personal pet-project of mine to have a custom build of Csound that stripped-down and removed much of what I felt was "non-essential" opcodes. Csound is an old and mighty project, but because it is like a giant snowball that has collected everything it has touched over the decades, and every whim of every dev who has worked on it, and has collected every opcode that makes every sort of noise, broadly useful or not, it is, well, BIG in every sense of the word. Because it's BIG, it has also taken longer and longer to configure, collect dependencies for (needed or not) and compile. For me, waiting for a compile for some opcode or feature set that I happen to know I won't ever use became something of a "pain-point", to use that modern dev/user conversational term.

<< It might be argued that csound's binary executable isn't _that_ big in a modern sense. And the compile isn't _that_ painful. And, well, they'd be right. So, if it helps, call this an OCD obsession of sorts; a ruthless desire for pursuing minimalist and clean coding practices. For those with me, read on... >>

Taking my fate into my own hands, and not waiting for someone else to solve _my_ problems (and why would they be motivated to, anyhow, this is ridiculous OCD after all?), this project is my own _personal_ vision of what it would be like to strip away "the noise" and have (an arguably subjective, again) a set of essential DSP opcodes of near universal utility. If it's intriguing or useful to others, who knows, I make it public for me and the 1 or 2 others who are curious...the rest can continue using the full non-reduced standard Csound. Those interested in a lean and mean version, and arguing over what should be essential or not, (lol), I invite you to the conversation. If it helps, having used Csound for decades, what I consider essential her may grow, and I might re-add things, but for now, what's gone:

• Opcodes that are not considered "best practice", even by users and devs. So, instead of telling me "best not to use `oscil` in favor of `oscili`", why not just stop providing `oscil`? There are many examples in the manual, too many to mention, The "deprecated" ones I was aware of, I simply removed. I'm not considering breaking things and backwards-compatibility, frankly. I was guided somewhat by the suggested "core opcodes" listed in the FLOSS manual here.
  
• Opcodes that are "gee-whiz toy noise-makers" (to me). I'm looking at you, `lorenz` and `planet`. If I'm wrong, argue with me! I'm not going to use them in my music, anyway. So sue me. I'm not arguing that they aren't fun to some...
• Opcodes that are unstable and can blow up and can cause hearing loss...where the manual warns you "you can play with this, but BE CAREFUL". Csound I am sure has already deafened me more than once where I was dumb not to wrap things in `limit` or something, and had to rip my headphones off at lightning speed. Anyone else been there? I'm not going to encourage those kinds of opcodes on my watch!
• Lots of opcodes that are arguably of intense utility and artistic purpose for lots of people, but tend to use a lot of CPU more than most, or are ones that I personally, lately, haven't used much. So these are on the fringes and maybe can be optionally built in future versions of diet_csound. FFT ones come to mind as a main representative of this category. Some of you may swim in this world all day every day, and have that as a focus. For now, you will find little compelling about diet_csound, then. For now. My focus has been making mostly traditional synths, and sometimes samplers-based synths. And so, designing opcodes with Faust and pulling them in to improve the sound and utility of what csound offered out of the box (i.e., frustrated with the wgpluck, pluck, repluck family being out-of-tune b/c of delay-line quantization, I turned to rolling my own "pluck" via Faust and pulling it into Csound's framework...

One other note: I have found that some of my reorganizational efforts for this fork _may_ be appealing to the main devs, and, even without removing a single opcode, the cleanup and module organization would, I think, make for a more logical "it makes sense that this thing lives in this file" layout, something I would argue isn't true of the current `master` and `devlopment` branches. I can lay out that argument to the devs elsewhere if anyone is interested. Many of the things I'm thinking of seemed to be put in place willy-nilly, and b/c the app compiled and worked, they stayed put...

All best,

Aaron.

Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson

https://soundcloud.com/filtercreed

https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg

https://aaronkristerjohnson.bandcamp.com/

http://www.untwelve.org

Code:
https://github.com/akjmicro

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Hi Aaron,

I think it is great to have it! Especially for the embedded systems! What is the size of your csound library with your build?

Thanks!

Tarmo

Kontakt Aaron Krister Johnson (<akjmicro@gmail.com>) kirjutas kuupäeval L, 27. jaanuar 2024 kell 23:14:

Slight correction -- I realized, I did keep `oscil`, even though it's often advised against for quality sound -- the reason being: arguably the best way to get low-fi/8-bit aesthetics.

Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson

https://soundcloud.com/filtercreed

https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg

https://aaronkristerjohnson.bandcamp.com/

http://www.untwelve.org

Code:
https://github.com/akjmicro

On Sat, Jan 27, 2024 at 11:47 AM Aaron Krister Johnson <akjmicro@gmail.com> wrote:

Hi all,

I made some pushes to my "diet_csound" repo, doing some further slimming and unused directory removal, in addition to making the build instructions more on-point and minimalist. Also, added a `build.sh` building script which should work for most people, at least on Linux, provided they have a C/C++ build system in place and the core dependencies installed, per their OS.

The repo is now at commit `e1ecaaf`.   https://github.com/akjmicro/diet_csound

On another note, if anyone is interested in the project, I would love feedback and non-Linux build testers. It's working great, builds fast for me, etc. But on your alternative OS, it might set your computer on fire, who knows. I'd love to help.

Background on this: it has long been a personal pet-project of mine to have a custom build of Csound that stripped-down and removed much of what I felt was "non-essential" opcodes. Csound is an old and mighty project, but because it is like a giant snowball that has collected everything it has touched over the decades, and every whim of every dev who has worked on it, and has collected every opcode that makes every sort of noise, broadly useful or not, it is, well, BIG in every sense of the word. Because it's BIG, it has also taken longer and longer to configure, collect dependencies for (needed or not) and compile. For me, waiting for a compile for some opcode or feature set that I happen to know I won't ever use became something of a "pain-point", to use that modern dev/user conversational term.

<< It might be argued that csound's binary executable isn't _that_ big in a modern sense. And the compile isn't _that_ painful. And, well, they'd be right. So, if it helps, call this an OCD obsession of sorts; a ruthless desire for pursuing minimalist and clean coding practices. For those with me, read on... >>

Taking my fate into my own hands, and not waiting for someone else to solve _my_ problems (and why would they be motivated to, anyhow, this is ridiculous OCD after all?), this project is my own _personal_ vision of what it would be like to strip away "the noise" and have (an arguably subjective, again) a set of essential DSP opcodes of near universal utility. If it's intriguing or useful to others, who knows, I make it public for me and the 1 or 2 others who are curious...the rest can continue using the full non-reduced standard Csound. Those interested in a lean and mean version, and arguing over what should be essential or not, (lol), I invite you to the conversation. If it helps, having used Csound for decades, what I consider essential her may grow, and I might re-add things, but for now, what's gone:

• Opcodes that are not considered "best practice", even by users and devs. So, instead of telling me "best not to use `oscil` in favor of `oscili`", why not just stop providing `oscil`? There are many examples in the manual, too many to mention, The "deprecated" ones I was aware of, I simply removed. I'm not considering breaking things and backwards-compatibility, frankly. I was guided somewhat by the suggested "core opcodes" listed in the FLOSS manual here.
  
• Opcodes that are "gee-whiz toy noise-makers" (to me). I'm looking at you, `lorenz` and `planet`. If I'm wrong, argue with me! I'm not going to use them in my music, anyway. So sue me. I'm not arguing that they aren't fun to some...
• Opcodes that are unstable and can blow up and can cause hearing loss...where the manual warns you "you can play with this, but BE CAREFUL". Csound I am sure has already deafened me more than once where I was dumb not to wrap things in `limit` or something, and had to rip my headphones off at lightning speed. Anyone else been there? I'm not going to encourage those kinds of opcodes on my watch!
• Lots of opcodes that are arguably of intense utility and artistic purpose for lots of people, but tend to use a lot of CPU more than most, or are ones that I personally, lately, haven't used much. So these are on the fringes and maybe can be optionally built in future versions of diet_csound. FFT ones come to mind as a main representative of this category. Some of you may swim in this world all day every day, and have that as a focus. For now, you will find little compelling about diet_csound, then. For now. My focus has been making mostly traditional synths, and sometimes samplers-based synths. And so, designing opcodes with Faust and pulling them in to improve the sound and utility of what csound offered out of the box (i.e., frustrated with the wgpluck, pluck, repluck family being out-of-tune b/c of delay-line quantization, I turned to rolling my own "pluck" via Faust and pulling it into Csound's framework...

One other note: I have found that some of my reorganizational efforts for this fork _may_ be appealing to the main devs, and, even without removing a single opcode, the cleanup and module organization would, I think, make for a more logical "it makes sense that this thing lives in this file" layout, something I would argue isn't true of the current `master` and `devlopment` branches. I can lay out that argument to the devs elsewhere if anyone is interested. Many of the things I'm thinking of seemed to be put in place willy-nilly, and b/c the app compiled and worked, they stayed put...

All best,

Aaron.

Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson

https://soundcloud.com/filtercreed

https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg

https://aaronkristerjohnson.bandcamp.com/

http://www.untwelve.org

Code:
https://github.com/akjmicro

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here