surge-synthesizer / sst-basic-blocks Goto Github PK

View Code? Open in Web Editor NEW

7.0 7.0 3.0 386 KB

Basic building blocks for the audio thread

License: GNU General Public License v3.0

CMake 0.30% C++ 99.13% Perl 0.42% C 0.14% Shell 0.01%

sst-basic-blocks's Introduction

https://surge-synthesizer.github.io/

Built with Astro & Tailwind CSS

Install node.js
- (Optional) Install pnpm
npm install/pnpm install to install dependencies
npm run dev/pnpm dev to run the development server

Adding and editing pages

To make changes, all you need to is fork the project. Once you have done that you can create a branch on your fork make changes and then open a PR. This git document for the OSS Surge-Synthesizer project outlines a suggested way of doing work and then creating PRs.

Once you have created a branch in your fork you can then just click the edit button (upper right corner) to edit a post in the src/content/pages folder. Because the posts are markdown documents you can just edit stuff in place in the GitHub editor.

To add a page, open the src/content/pages folder in your fork and click the create new file button.

A post has a frontmatter section and a body section. The frontmatter section is metadata about the post, such as which image to use and what categories it belongs to. A new post would have frontmatter that looks something like:

---
slug: surge-xt
title: Surge XT
summary: Surge XT is an open source hybrid synthesizer, and the synth which started the Surge Synth Team project!
order: 1
thumbnail: /screenshots/surge-xt.png
categories: [Synth]
url: https://surge-synthesizer.github.io
issue_tracker: https://github.com/surge-synthesizer/surge/issues
---

The title is the display name for the post, the summary is the text in the card on the main page, the thumbnail is an image for the project, and the categories are a comma-separated list of any appropriate categories (look at the other projects for categories that already exist). The order determines which position a post appears in on the main page.

The body section of a post is where you can write a description of the project in markdown. It is everything after the frontmatter section.

Editor setup

Official guides

VS Code Setup

Set Prettier as your default formatter

{
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "[astro]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[yaml]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "prettier.documentSelectors": ["**/*.astro"]
}

Format on paste, save & type

{
    "editor.formatOnPaste": true,
    "editor.formatOnSave": true,
    "editor.formatOnType": true
}

Associate CSS files with tailwind

{
    "files.associations": {
        "*.css": "tailwindcss"
    }
}

sst-basic-blocks's People

Contributors

Stargazers

Watchers

Forkers

baconpaul xenakios mx

sst-basic-blocks's Issues

Hook up discord notifications

You know like in other products and stuff

More comprehensive tests

Beyond the smoke test - just bite the bullet next time I’m in here

ParamMetaData::valueFromString should take in a FeatureState too and use it?

Currently it is not possible for example to extend a parameter's range and convert a string to a value if the string has a valid value that is in the extended range. I am not sure if this is designed to work like this on purpose, but I guess it's more like a missing implementation at the moment in the ParamMetaData valueFromString method?

SimpleLFO copy construction doesn't work

sst::basic_blocks::modulators::SimpleLFO can't be copied (and possibly moved) correctly as a value because of the way the code has been written. Because that probably usually is not needed anyway, might be easiest to just delete the copy and move constructors/assignments for the class.

Curious issue with the Lanczos resampler

It looks like zero initing the input array in the constructor with
memset(input, 0, 2 * BUFFER_SZ * sizeof(float));
does not work correctly, at least on Windows/Clang 16.0.5. Junk is left in the input buffer, causing corrupted output during the first processing round.

Changing to the following seems to fix :

memset(input[0], 0, BUFFER_SZ * sizeof(float)); memset(input[1], 0, BUFFER_SZ * sizeof(float));

Param MetaData Polarity and Jog

mostly just remembering what we said

Xenakios — Yesterday at 5:22 PM
ah ok, is there some other way to express the bi-polarness in the ParamMetaData?
EvilDragon — Yesterday at 5:22 PM
you set the range -1...1
Xenakios — Yesterday at 5:22 PM
right, so it's has to be deduced elsewhere in the code? (like when drawing sliders)
EvilDragon — Yesterday at 5:23 PM
https://github.com/surge-synthesizer/surge/blob/main/doc/Dynamic%20Names%2C%20Deactivation%20and%20Bipolarity.md
baconpaul — Yesterday at 6:25 PM
I have to date used min == -max to infer bipolar yeah
We could change that. Add a polarity enum of inferred unipos unineg bipolar
Defaults to inferred
Add a as method
Add a query which uses rules for inferred
Happy to add that.
Would help with one bit of conduit too
Xenakios — Yesterday at 6:47 PM
cool!
what about quantization for the param values?
baconpaul — Yesterday at 7:52 PM
i've followed the idea that int and bool are quantized and float is not
would you like a quantized float too? is that the idea?
for the polarity here's my proposal not-on-phone
we add an enum
enum Polarity { 
   INFERRED,
   UNIPOS,
   UNINEG,
   BIPOLAR,
   NO_POLARITY
} polarity{INFERRED};


then we add an obvious withPolarity(Polarity p)

then we add 

Polarity getPolarity() const {
   if (polarity != INFERRED)
      return polarity;
   if (min == 0 && max > 0)
      return UNIPOS;
   if (max == 0 && min < 0)
      return UNINEG;
   if (min == -max)
      return BIPOLAR;
   return NO_POLARITY;
}
which I think covers all the cases
then I would make sst-jucegui knobs draw UNIPOS and NO_POLARITY from 0, UNINEG from top and BIPOLAR from middle
your thoughts on this design welcome before I code it up
EvilDragon — Yesterday at 7:57 PM
I'm not sure we really need the unipos and unineg distinction
it would draw visually the same way.
baconpaul — Yesterday at 7:58 PM
Not necessarily
You might choose to have unineg draw the ring from the top not th ebottom on a slider for instance
EvilDragon — Yesterday at 7:58 PM
I don't see the huge need tbh
ah for a slider. hm sure I guess
baconpaul — Yesterday at 7:58 PM
yeah
its easier to collapse them than to sprinkle ifs everywhere is my rough idea
EvilDragon — Yesterday at 7:58 PM
very rare cases I think
baconpaul — Yesterday at 7:59 PM
we can add an 'isUnipolar' which is 'getPolarity() == unipos || unineg' easily
EvilDragon — Yesterday at 7:59 PM
right 
baconpaul — Yesterday at 7:59 PM
and more importantly an 'isBipolar'
Xenakios — Yesterday at 8:01 PM
regarding the quantization, for GUI, so that the GUI code doesn't need to guess what is the natural step for example when using the arrow keyboard shortcuts
EvilDragon — Yesterday at 8:01 PM
or mousewheel
Xenakios — Yesterday at 8:01 PM
yeah
EvilDragon — Yesterday at 8:05 PM
the problem is that a float parameter can be nonlinear
you cannot specify a quantization step then necessarily
Xenakios — Yesterday at 8:12 PM
std::vector<float> customquantizedvalues 😬 😂
baconpaul — Yesterday at 8:16 PM
Oh yeah so a jog rounding
I have that in the sst jucegui api
And couldn’t match it to Param metadata
Ok I will add both this week
But basically a set of jog up and down and round to jog options clearly needed
I needed them for the ally implementation. What does the arrow key do
And I just hacked it last week
Got it. Will add to list