IANAL. Shr3D is my personal project. I'm just a anonymous guy on the internet. I can/will never claim any ownership on it. That's why I choose to place the Shr3D core code in the public domain. I never cared about copyright. I think copyright always sucked. It sucks even more in the age of LLMs. In true hacker spirit I think there should not be any limits on what you can do with a computer. You should be able to run any software on any device you want. There are things I simply never understood about copyright:
| Source File | Platform | License | Comment | #define |
|---|---|---|---|---|
| deps/Superpowered | Android | Proprietary | Needed for real time audio on Android. Copied code from Superpowered SDK. Includes a 3rd party static library. Big issue, open source replacement would be nice. | SHR3D_AUDIO_SUPERPOWERED |
| src/asio.cpp | Proprietary | No idea | copied code from the ASIO SDK. The code does basic Windows API calls. IMO it should be ok, but Audacity claims the ASIO SDK is not compatible with open source software. | SHR3D_AUDIO_ASIO |
| src/hexfin.c | All | MIT | copied code from cycfi/q | SHR3D_SFX_CORE_HEXFIN |
| src/milk.cpp | Windows | GPL v2.1 | copied code from projectM | SHR3D_ENVIRONMENT_MILK |
| src/rijndael.cpp | All | Unknown | I think I copied code from here, but the download link is broken. | SHR3D_PSARC |
| src/samplerate*.c | All | Dual License, GPL or 2-clause BSD | Required by some Rakarrack effects. | SHR3D_SFX_CORE_RAKARRACK_LIBSAMPLERATE |
| deps/vst3sdk, src/sfxPluginVst3.cpp | Linux, Windows | Dual License, Proprietary or GPL 3 | The proprietary license is crazy. It forbids dirstributing the source files of the SDK. So the build has to download the SDK. Which means you can not build Shr3D without internet access. The build would also break as soon as Steinberg removes the file from their webserver. IMO this is unacceptable. If I go with the GPL 3 licence there is not such an issue and I can even distribute modified source files? | SHR3D_SFX_PLUGIN_VST3 |
Audio is the most crucial part of Shr3D. It is essential to get a very low round trip latency (≤ 10ms). Here is a overview:
Note: SDL is used whenever I have not yet spend the time to implement the platform specific code.
Update: check out .shred, the Supreme Heavy Riffage and Effect Description file format specification.
A long term goal is to create a new file format as a replacement for .psarc files. As the PlayStation ARChive name suggest it is a archive for other files.
Obviously the main reason why Shr3D supports .psarc file is because there is a huge community creating them and there exists decent tooling for creating your own files.
Shr3D does cache metadata and album covers of .psarc files which helped with the biggest issue: Performance. But I think a new file format would be even better.
Here is what is so bad about the .psarc file format:
We need a simple archive format. The containing files should be human readable.
I think it would be good to really think hard about what to keep from .psarc and what should be added. I would like to nail this format this once and for all and not be another example of xkcd 927.
Right now I'm leaning towards .zip since it is so widly used. The best thing about it is that no external tools are needed for editing the content on Windows. The .zip extension would be renamed to .shred. Shr3D could play/import them by simply double clicking.
Human readable files would be nice in case you are not satisfied with your guitar tone on a file from someone else. You could have patch files that only overwrite parts inside the original .shred file. In case you want to share your improvements you could have the option to make your local overwrites permanent.
The .shred files would usually be one song per file with as many arrangements as you want. But you could also have a .shred file that is a collection of other .shred files. The naming schema would be similar to .psarc, 'artist-name_song-title_v1.shred'.
One preview audio file + at least one audio song file: The .ogg format would be the straightforward choise. Modern lossless formats do exist, but there is nothing that could be gained when converting the existing .psarc files (.ogg audio = lossy compression) into a new audio format. Multiple audio song files could be allowed to make it possible to have .ogg files with instruments like lead guitar or bass removed. Note: I dislike that many existing .psarc file have an additional period of silence at the start of the audio file. I would prefer to have use configurable silence in Shr3D that delays the audio of all songs equally start of all songs.
One Album cover file: There is no universal compressed image format that works on all GPUs. Thats why album cover must use the .png file format (you can't really go wrong with it). A resolution of 256x256 RGB should be a good compromise between file size and quality. .ogg files do have a metadata artwork section, but we shoud not use it.
One Lyrics file: Lyrics are simple. We have the time when it will be shown, the duration and the text itself. A file with lines like "123.456,0.068=Hello+" for each word will do. A '+' will indicate a line break. A '-' will skip the space after the word.
One song info file: I also choose a extra file over the .ogg metadata section. Simple "key=value" lines like "albumYear=2004" will do.
Arrengement files: These are complicated files containing the note data, phrases. The new files would be human readable of course. I want them to be diffable in case you want to do a fix on an existing file. The obvious goto format for this kind of data would be JSON. I've looked into it, but I decided to stick with .ini here too. Reasons:
I struggled with choosing between Discord and Matrix for a while. Matrix is nice, but the userbase is tiny. That's why I will go with Discord for now. I will switch over to a self hosted Matrix homeserver in case I regret this decision or in case my account gets banned. Let's see how it will work out.
The renderer in highway.cpp is quite simple.
I would call it an immediate mode renderer.
By that I mean all geometry is send to the GPU each frame.
The nice thing about it is that changing any settings like the view distance, note shape or string color does not cause any buffers to be reinitialized and it will not cause any performance hickups.
The tradeoff is that it is not very fast in generall since we do a draw call for each geomertry.
Thankfully our frames do not contain a lot of it and we can mostly get away with calling glDrawArrays about 300 times per frame at 1000 fps. It's crazy what you can get away with on modern hardware these days.
When using Shr3D on the Web there is quite some overhead involved and you are roughly only getting about 5% of the fps that you would get on the desktop.
This is a problem and highway2.cpp should improve it eventually by sorting the geometry in a frame based on the Z coordinate, using VBOs and instanced rendering.
Shr3D v0.4.2 got a record button!
I added it because I don't have a ASIO audio interface with loopback support.
Without it you can't caputure the sound you hear on your headphones.
The new recorder solves this problem if you only want to capture audio.
You would still need loopback for live streaming Shr3D.
Here is how the new recorder works:
After toggling the button, the audio signal you hear on your headphones is also written into a buffer.
When the song ends, this buffer gets written to disk.
It will be put into this nice directory structure:
recorder/artist/year-album/song/YYYY-MM-DD_HH_MM.wav.
This is excellent for tracking your progress over time.
The wav files are using 32 bit floats.
This is super nice because there is no code needed for doing any float to integer conversion or dealing with clipping the signal at 2^24.
And most importantly you can't ruin your recording anymore.
Most big corporate logos today are simple and boring.
My favorite open source project logo is the old LLVM dragon logo. I think it is just perfect. I think it is super recognizable because there are not many logos like it around. I want Shr3D to have a similar badass logo, but I'm lacking the drawing skills for it.
I generated the current logo when AI image generation got to the point of getting usable. I'm not sure how I should feel about AI art. It is awesome because I'm able to create about without much effort. On the other hand the web is already full of it.
Anyway, I think the current logo could be improved. I would like to have a uniform set of logos, banners, fonts, etc.
Watch my gear video.
From my gear video, you might have already seen my instruments. I snapped some pictures when I installed the Roland GK-KIT-BG3 on my bass:
