The Synthesis ToolKit in C++ (STK) is a set of open source audio signal processing and algorithmic synthesis classes written in the C++ programming language.

Related tags

Miscellaneous stk
Overview

The Synthesis ToolKit in C++ (STK)

By Perry R. Cook and Gary P. Scavone, 1995--2021.

This distribution of the Synthesis ToolKit in C++ (STK) contains the following:

  • include: STK class header files
  • src: STK class source files
  • rawwaves: STK audio files (1-channel, 16-bit, big-endian)
  • doc: STK documentation
  • projects: example STK projects and programs

Please read the Legal and Ethical notes near the bottom of this document and the License.

For compiling and installing STK, see the INSTALL.md file in this directory.

Contents

OVERVIEW

The Synthesis ToolKit in C++ (STK) is a set of open source audio signal processing and algorithmic synthesis classes written in the C++ programming language. STK was designed to facilitate rapid development of music synthesis and audio processing software, with an emphasis on cross-platform functionality, realtime control, ease of use, and educational example code. The Synthesis ToolKit is extremely portable (most classes are platform-independent C++ code), and it's completely user-extensible (all source included, no unusual libraries, and no hidden drivers). We like to think that this increases the chances that our programs will still work in another 5-10 years. STK currently runs with "realtime" support (audio and MIDI) on Linux, Macintosh OS X, and Windows computer platforms. Generic, non-realtime support has been tested under NeXTStep, Sun, and other platforms and should work with any standard C++ compiler.

The only classes of the Synthesis ToolKit that are platform-dependent concern sockets, threads, mutexes, and real-time audio and MIDI input and output. The interface for MIDI input and the simple Tcl/Tk graphical user interfaces (GUIs) provided is the same, so it's easy to experiment in real time using either the GUIs or MIDI. The Synthesis ToolKit can generate simultaneous SND (AU), WAV, AIFF, and MAT-file output soundfile formats (as well as realtime sound output), so you can view your results using one of a large variety of sound/signal analysis tools already available (e.g. Snd, Cool Edit, Matlab).

The Synthesis Toolkit is not one particular program. Rather, it is a set of C++ classes that you can use to create your own programs. A few example applications are provided to demonstrate some of the ways to use the classes. If you have specific needs, you will probably have to either modify the example programs or write a new program altogether. Further, the example programs don't have a fancy GUI wrapper. If you feel the need to have a "drag and drop" graphical patching GUI, you probably don't want to use the ToolKit. Spending hundreds of hours making platform-dependent graphics code would go against one of the fundamental design goals of the ToolKit - platform independence.

For those instances where a simple GUI with sliders and buttons is helpful, we use Tcl/Tk (https://www.tcl.tk/) which is freely distributed for all the supported ToolKit platforms. A number of Tcl/Tk GUI scripts are distributed with the ToolKit release. For control, the Synthesis Toolkit uses raw MIDI (on supported platforms), and SKINI (Synthesis ToolKit Instrument Network Interface, a MIDI-like text message synthesis control format).

SYSTEM REQUIREMENTS

See the individual README's (e.g. README-linux) in the /doc directory for platform specific information and system requirements. In general, you will use the configure script to create Makefiles on unix platforms (and MinGW) or the VS2017 workspace files to compile the example programs. To use the Tcl/Tk GUIs, you will need Tcl/Tk version 8.0 or higher.

WHAT'S NEW (AND NOT SO NEW)

Despite being available in one form or another since 1996, we still consider STK to be alpha software. We attempt to maintain backward compatability but changes are sometimes made in an effort to improve the overall design or performance of the software. Please read the "Release Notes" in the /doc directory to see what has changed since the last release.

A new StkFrames class has been created to facilitate the handling and passing of multichannel, vectorized audio data. All STK classes have been updated to include tick() functions that accept StkFrames arguments.

The control message handling scheme has been simplified greatly through the use of the Messager class. It is now possible to have access to simultaneous piped, socketed, and/or MIDI input control messages. In most cases, this should eliminate the use of the Md2Skini program.

Realtime audio input capabilities were added to STK with release 3.0, though the behavior of such is very hardware dependent. Under Linux and Macintosh OS-X, audio input and output are possible with very low latency. Using the Windows DirectSound API, minimum dependable output sound latency seems to be around 20 milliseconds or so, while input sound latency is generally higher. Performance with the ASIO audio API on Windows provides much better performance.

As mentioned above, it is possible to record the audio ouput of an STK program to .snd, .wav, .raw, .aif, and .mat (Matlab MAT-file) output file types. Though somewhat obsolete, the program Md2Skini can be used to write SKINI scorefiles from realtime MIDI input. Finally, STK should compile with non-realtime functionality on any platform with a generic C++ compiler.

For those who wish to make a library from the core STK classes, the configure script generates a Makefile in the src directory that will accomplish that.

DISCLAIMER

You probably already guessed this, but just to be sure, we don't guarantee anything works. :-) It's free ... what do you expect? If you find a bug, please let us know and we'll try to correct it. You can also make suggestions, but again, no guarantees. Send email to the mail list.

LEGAL AND ETHICAL

This software was designed and created to be made publicly available for free, primarily for academic purposes, so if you use it, pass it on with this documentation, and for free.

If you make a million dollars with it, it would be nice if you would share. If you make compositions with it, put us in the program notes.

Some of the concepts are covered by various patents, some known to us and likely others which are unknown. Many of the ones known to us are administered by the Stanford Office of Technology and Licensing.

The good news is that large hunks of the techniques used here are public domain. To avoid subtle legal issues, we'll not state what's freely useable here, but we'll try to note within the various classes where certain things are likely to be protected by patents.

FURTHER READING

For complete documentation on this ToolKit, the classes, etc., see the doc directory of the distribution or surf to http://ccrma.stanford.edu/software/stk/. Also check the platform specific README's for specific system requirements.

PERRY'S NOTES FROM THE ORIGINAL DISTRIBUTION

This whole world was created with no particular hardware in mind. These examples are intended to be tutorial in nature, as a platform for the continuation of my research, and as a possible starting point for a software synthesis system. The basic motivation was to create the necessary unit generators to do the synthesis, processing, and control that I want to do and teach about. Little thought for optimization was given and therefore improvements, especially speed enhancements, should be possible with these classes. It was written with some basic concepts in mind about how to let compilers optimize.

Your question at this point might be, "But Perry, with CMix, CMusic, CSound, CShells, CMonkeys, etc. already cluttering the landscape, why a new set of stupid C functions for music synthesis and processing?" The answers lie below.

  1. I needed to port many of the things I've done into something which is generic enough to port further to different machines.

  2. I really plan to document this stuff, so that you don't have to be me to figure out what's going on. (I'll probably be sorry I said this in a couple of years, when even I can't figure out what I was thinking.)

  3. The classic difficulties most people have in trying to implement physical models are:

    A) They have trouble understanding the papers, and/or in turning the theory into practice.

    B) The Physical Model instruments are a pain to get to oscillate, and coming up with stable and meaningful parameter values is required to get the models to work at all.

This set of C++ unit generators and instruments might help to diminish the scores of emails I get asking what to do with those block diagrams I put in my papers.

  1. I wanted to try some new stuff with modal synthesis, and implement some classic FM patches as well.

  2. I wanted to reimplement, and newly implement more of the intelligent and physical performer models I've talked about in some of my papers. But I wanted to do it in a portable way, and in such a way that I can hook up modules quickly. I also wanted to make these instruments connectable to such player objects, so folks like Brad Garton who really think a lot about the players can connect them to my instruments, a lot about which I think.

  3. More rationalizations to follow . . .

Issues
  • play example fails on the Mac

    play example fails on the Mac

    After a default configure and make, the play examples fails as follows on the Mac:

    > ./play /w/s/wav/mandolin1.wav 44100
    2017-04-15 14:49:13.384 play[80868:1752912] Error loading /Library/Audio/Plug-Ins/HAL/JackRouter.plugin/Contents/MacOS/JackRouter:  dlopen(/Library/Audio/Plug-Ins/HAL/JackRouter.plugin/Contents/MacOS/JackRouter, 262): Library not loaded: /System/Library/Frameworks/Jackmp.framework/Versions/A/Jackmp
      Referenced from: /Library/Audio/Plug-Ins/HAL/JackRouter.plugin/Contents/MacOS/JackRouter
      Reason: image not found
    2017-04-15 14:49:13.385 play[80868:1752912] Cannot find function pointer New_JackRouterPlugIn for factory 7CB18864-927D-48B5-904C-CCFBCFBC7ADD in CFBundle/CFPlugIn 0x7fbf83c0e720 </Library/Audio/Plug-Ins/HAL/JackRouter.plugin> (bundle, not loaded)
    

    I am using JACK as installed by MacPorts. I do not find a Jackmp framework at Apple. In any case, a new dependency seems to be needed in configure.

    opened by josmithiii 26
  • Dynamic library not installed properly

    Dynamic library not installed properly

    Makefile is slightly dyslexic, with the following results:

    $ cd src
    $ ./configure -prefix=/Users/r/Projects/Mu/usr
    ...
    $ make install
    ...
    cp -r ../include/*.h /Users/r/Projects/Mu/usr/include/stk
    install -d /Users/r/Projects/Mu/usr/lib
    install -m 644 libstk.dylib.4.4.4 /Users/r/Projects/Mu/usr/lib
    install: libstk.dylib.4.4.4: No such file or directory
    make[2]: *** [install] Error 71
    make[1]: *** [install] Error 2
    make: *** [/Users/r/Projects/Mu/usr/lib/libstk.a] Error 2
    

    It appears that Makefile disagrees with itself. Around line 90, it's creating 'libstk.4.4.4.dylib':

    # Makefile line 90
    $(SHAREDLIB) : $(OBJECTS)
        $(RM) -f $(@) $(SHAREDLIB).$(MAJOR) $(SHAREDLIB)
        $(CC) $(LDFLAGS) -fPIC -dynamiclib -o libstk.$(RELEASE).dylib $(OBJECT_PATH)/*.o $(LIBS)
        $(LN) -s libstk.$(RELEASE).dylib $(SHAREDLIB)
        # $(LN) -s libstk.$(RELEASE).dylib $(SHAREDLIB).$(MAJOR)
    

    ... but around line 100, it's trying to install 'libstk.dylib.4.4.4':

    install: $(SHAREDLIB) install-headers
        install -d $(DESTDIR)$(PREFIX)$(LIBDIR)
        install -m 644 $(SHAREDLIB).$(RELEASE) $(DESTDIR)$(PREFIX)$(LIBDIR)
        ln -sf $(SHAREDLIB).$(RELEASE) $(DESTDIR)$(PREFIX)$(LIBDIR)/$(SHAREDLIB)
        ln -sf $(SHAREDLIB).$(RELEASE) $(DESTDIR)$(PREFIX)$(LIBDIR)/$(SHAREDLIB).$(MAJOR)
    

    According to https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW19, it appears that the correct name would be libstk.4.dylib, where 4 is the major version number.

    I'd change it, but I have no idea how many other apps depend on the name of the shared library.

    opened by rdpoor 26
  • Windows refresh + ASIO

    Windows refresh + ASIO

    Hi. As part of my other audio experiments I wanted to incorporate some wave/sound generating capability. I decided stk was the best option based on several criteria. As the current VS build configs are stale, I updated them to support VS2017. I also spent some time debugging the ASIO support but didn't quite get through that completely.

    So, I would like to formalize these steps and give back my learnings. My thought is to branch and create a new project folder with an updated win stk build + ASIO + OSC server (because this is what I really want for my experiments). I can do this with VS but also strongly consider using Qt/mingw/QMake/QtCreator which I consider a superior environment for C++ applications (even vanilla ones that don't use Qt libs).

    If this is acceptable and successfully implemented, then consideration can be given to updating the other projects.

    opened by cepthomas 19
  • Jack support should not require ALSA

    Jack support should not require ALSA

    AC_CHECK_LIB(asound, snd_pcm_open, , AC_MSG_ERROR(Jack support also requires the asound library!))], )

    Jack is independent of ALSA in both sound and MIDI.

    opened by yurivict 7
  • Build wavetables (rawwaves) into source code

    Build wavetables (rawwaves) into source code

    I am the author and maintainer of Csound opcodes that wrap the STK instrument classes (https://github.com/csound/csound/blob/develop/Opcodes/stk/stkOpcodes.cpp). It would greatly facilitate encapsulating the STK in Csound and in other projects if there were an option to bring all of the rawwaves wavetables into RAM and into the actual source code such that there would be no need to read this data from storage and no need to locate this storage at run time.

    enhancement 
    opened by gogins 7
  • [Suggestion] More Windows MinGW instructions for compiling a .lib

    [Suggestion] More Windows MinGW instructions for compiling a .lib

    Thank you for the examples/*.vcxproj files. I was able to get a custom project built. However, for convenience, I'd like to build a .lib for Windows.

    I've installed MinGW. I have C:\MinGW\bin\autoconf. If I launch a MinGW 64 prompt, cd to the stk directory, and type autoconf I get bash: autoconf: command not found. If I type C:/MinGW/bin/autoconf I get C:/MinGW/bin/autoconf-2.68: line 501: /mingw/bin/autom4te-2.68: No such file or directory.

    I also have C:\MinGW\share\autoconf\autoconf but am not sure what good it is.

    I would really appreciate a few more troubleshooting steps for the Windows installation. Thank you!

    opened by DBraun 5
  • RTAudio.cpp: 24 Bit input conversion to anything else produces erroneous output

    RTAudio.cpp: 24 Bit input conversion to anything else produces erroneous output

    I just ran into this problem while working with a sound card that supports 24 bit inputs and below. I was requesting RTAUDIO_FLOAT32 as my output format, but because my card only supported 24, 16, and 8 bit inputs, it defaulted to 24 bit. The callback function for openStream was getting called twice as often as it should, and the internal stream time reflected that (i.e., the internal time thought 10 seconds had passed when only 5 had). This was true no matter the target output format AFAICT, which makes me think the S24 class (defined in RTAudio.h) is broken. For sure it was broken when my target output was Float 32.

    I "fixed" this by commenting the code

    deviceFormat = SND_PCM_FORMAT_S24; if ( snd_pcm_hw_params_test_format(phandle, hw_params, deviceFormat ) == 0 ) { stream_.deviceFormat[mode] = RTAUDIO_SINT24; goto setFormat; }

    so the input format from the card was SND_PCM_FORMAT_S16 by default. Perhaps the inJump/outJumps are miscalculated or there is a bug in the .asInt() method?

    Edit - I should mentioned this was compiled for an Armv7 board in Little Endian.

    opened by aschneid1 5
  • Dynamic Library needs absolute path in OS X

    Dynamic Library needs absolute path in OS X

    (Preface: Previously, https://github.com/thestk/stk/issues/28 co-mingled two separate issues: naming problems in the installation of the dynamic library and need for absolute pathnames within the dynamic library. I've migrated out the comments specific the latter to this issue.)

    When I create an executable linked against the dynamic library, I get:

    Mu[~/Projects/Mu/examples]$ ./mune31
    dyld: Library not loaded: libstk.dylib.4.4.4
      Referenced from: /Users/r/Projects/Mu/examples/./mune31
      Reason: image not found 
    Trace/BPT trap: 5
    

    When I run otool -L on the executable, I can see why:

    ./mune31:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.16.0)
        /System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 73.0.0)
        /Users/r/Projects/Mu/usr/lib/libgsl.0.dylib (compatibility version 18.0.0, current version 18.0.0)
        libstk.dylib.4.4.4 (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    

    For reasons beyond my ken, libstk.dylib.4.4.4 is a relative pathname. I can fix this manually with install_name_tool:

    install_name_tool -change libstk.dylib.4.4.4 /Users/r/Projects/Mu/usr/lib/libstk.dylib.4.4.4 ./mune31
    

    And everything is happy now:

    Mu[~/Projects/Mu/examples]$ otool -L ./mune31
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
            /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
            /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.16.0)
            /System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 73.0.0)
            /Users/r/Projects/Mu/usr/lib/libgsl.0.dylib (compatibility version 18.0.0, current version 18.0.0)
            /Users/r/Projects/Mu/usr/lib/libstk.dylib.4.4.4 (compatibility version 0.0.0, current version 0.0.0)
            /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    

    ... but this just goes to prove that I have much to learn. Any suggestions?

    opened by rdpoor 5
  • The samplerate should be a member property of Stk base class

    The samplerate should be a member property of Stk base class

    It seems that the sample rate is a global static variable in the Stk class, which makes it impossible to use the framework in a multi-samplerate environment (eg. with oversampling).

    Is there a reason why it can't be made a member variable of the Stk base class and adding a virtual function

    
    // Two new members:
    double objectSampleRate = -1.0;
    bool usingObjectSampleRate = false;
    
    /** Can be used to set a samplerate for this object.
     If you call this method, this class instance will use this value 
    instead of the global sample rate value. */
    virtual void setObjectSampleRate(double sampleRate)
    {
        objectSampleRate = sampleRate;
        usingObjectSampleRate = true;
    }
    
    /** Returns the sample rate that was set with a call to setObjectSampleRate()
     or the global samplerate as fallback. */
    double getObjectSampleRate() const noexcept
    {
        if(usingObjectSampleRate)
            return objectSampleRate;
        else
            return getSampleRate() // return the global static as fallback
    }
    }
    

    Also, this way functions which need to update their state when the samplerate changes can simply override the function:

    class DerivedStk: public Stk
    {
        void updateState()
        {
             // setup the processing
        }
    
        void setObjectSampleRate(double sampleRate) override
        {   
            Stk::setObjectSampleRate(sampleRate);
            updateState();
        }
    };
    

    DISCLAIMER: the naming is poor (ideally it should be just called setSampleRate() / getSampleRate(), but it allows 100% backwards compatibility to legacy code.

    EDIT: Also, the handling should be more flexible - the API states that you can't change the samplerate after object instantiation, which might happen for several reasons (the end user changing audio device settings might be the most prominent example).

    opened by christoph-hart 4
  • non-free asio files

    non-free asio files

    At least src/include/asio.{h,cpp} are part of the steinberg sdk, which is licensed under quite strict terms:

    
    1.1
    The object of this agreement consists of the Steinberg ASIO (Audio
    Stream I/O) Software Development Kit version 2.3, respectively any
    preview version of this Kit, comprising of documentation, example code,
    and several ASIO examples. These are described hereinafter as the
    "Licensed Software Developer Kit".
    
    The license goes on to include other terms which seem to prohibit
    modification or redistribution in most cases:
    
    2.3
    The Licensee has no permission to sell, license, give-away and/or
    distribute the Licensed Software Developer Kit or parts of it for the
    use as software developer kit in any way, for example, integrated in
    any framework application, on any medium, including the Internet, to
    any other person, including sub-licensors of the Licensee or companies
    where the Licensee has any involvement. This includes re-working this
    specification, or reverse-engineering any products based upon this
    specification.
    
    2.4
    In case the Licensed Software Developer Kit is modified, it shall not
    be published, sold or distributed without agreement of Steinberg.
    Furthermore, the naming of the Licensed Software Developer Kit shall
    not include “ASIO 2.3 SDK” or any combination containing the VST brand
    without permission of Steinberg.
    

    The files should probably be stripped from the stk sources.

    opened by fsateler 4
  • FMVoices call to Phonemes::formantFrequency() off by one

    FMVoices call to Phonemes::formantFrequency() off by one

    Hi!

    I got Phonemes::formantFrequency: index is greater than 31! and it saddened me a bit. If you give FMVoices a Spectral Tilt argument of 128.0 it will ask for phoneme 32.

    opened by zonkmachine 4
  • STK configuration fails in dash shell

    STK configuration fails in dash shell

    When I try to build STK in /bin/dash shell, in configuration phase I get the following errors:

    checking for audio API... ./configure: 6162: test: x: unexpected operator
    ./configure: 6337: test: x: unexpected operator
    ./configure: 6398: test: x: unexpected operator
    ./configure: 6504: test: x: unexpected operator
    ./configure: 6558: test: unexpected operator
    

    It works fine in bash.

    opened by BlueManCZ 0
  • Is it possible to integrate STK lib with android?

    Is it possible to integrate STK lib with android?

    Hi, I am developing Karaoke app in android and i am using oboe livestream to record a voice and merge with music using ffmpeg. and i want to add effects to output audio file. Is it possible to process the audio to get effects? If you know please help me or please guide me. Thanks in advance

    opened by YogarajRamesh 4
  • Issues after creating stk::FreeVerb instances repeatedly

    Issues after creating stk::FreeVerb instances repeatedly

    I discovered that reverb effect is changing sound after I create remove repeatedly that I made simple test like this and it proved my theory that some value or something get modified and is shared across instances..

    You can reproduce it like this:

     stk::FreeVerb *freeVerb20 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb19 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb18 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb17 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb16 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb15 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb14 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb13 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb12 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb11 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb10 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb9 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb8 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb7 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb6 = new stk::FreeVerb();
        stk::FreeVerb *freeVerb = new stk::FreeVerb();
    

    Here just use the last instance .. It has broken sound..
    I am trying to find out why now but not yet with luck.

    opened by renetik 3
  • Potential Integer Overflow vulnerability in src/Stk.cpp

    Potential Integer Overflow vulnerability in src/Stk.cpp

    It seems that there exists a potential integer overflow. Please find the following description:

    1. Call to function FileRead :: open(...) https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/FileLoop.cpp#L50

    2. In FileRead :: open(...), Call to function getWavInfo(...) https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/FileRead.cpp#L100

    3. In getWavInfo(...), variable temp is read from external source https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/FileRead.cpp#L223

    4. channels_ can be an arbitrary integer https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/FileRead.cpp#L227

    5. Back to function in #1, call to fileSize(...) https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/FileLoop.cpp#L53 https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/include/FileRead.h#L77

    6. In the same function with #6, Call to function StkFrames :: resize(...) with channels_ as second argument https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/include/FileRead.h#L80 https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/FileLoop.cpp#L56

    7. In function StkFrames :: resize(...), if channels_ is large enough, the multiplication can cause integer overflow https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/Stk.cpp#L296 https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/Stk.cpp#L299

    8. In the same function with #8, if channels_ is large enough (from #8), allocation of memory with multiplication may cause integer overflow https://github.com/thestk/stk/blob/1fec6e015749f6f1f0171e30af78dd2e7939aaaa/src/Stk.cpp#L302

    opened by KSB21ST 0
  • soname change with every release (with 4.6.1 in a patch level release)

    soname change with every release (with 4.6.1 in a patch level release)

    The current setup introduces a shared object name change on a patch level release, which leads to rebuilds of all dependants in a Linux distribution!

    drwxr-xr-x root/root         0 2019-04-18 18:56 usr/lib/
    -rw-r--r-- root/root    904296 2019-04-18 18:56 usr/lib/libstk-4.6.1.so
    lrwxrwxrwx root/root         0 2019-04-18 18:56 usr/lib/libstk.so -> libstk-4.6.1.so
    

    This is not what should happen on a patch level release, as it breaks the assumption of using semver, as specified in RFC 2119. If the API has changed significantly, at least a version 4.7.0 or 5.0.0 should have been released instead of 4.6.1. If the API was not changed, a soname change is not required.

    In a situation where an API change did not take place, the versioning of the shared object should be changed to e.g.:

    libstk.so -> libstk.so.4
    libstk.so.4 -> libstk-4.6.1.so
    
    opened by dvzrv 7
  • Use libtool, fix Mac library issues

    Use libtool, fix Mac library issues

    Hi, I'm the maintainer of stk in MacPorts. I've been meaning for years to report to you that there are several issues with the way your library is being created: it doesn't have an install_name set; it doesn't have versioning information set; its filename is unusual; your library versioning scheme may be incorrect or nonexistent. When I updated MacPorts stk to 4.5.0 I added patches to fix it well enough for our use, but your code has changed in the meantime.

    It looks like @rdpoor has beaten me to it and reported some of this in https://github.com/thestk/stk/issues/28 and https://github.com/thestk/stk/issues/40 but no solutions seem to have been committed yet and those issues were closed.

    The problems seem to stem from the fact that you generate shared libraries manually. Generating shared libraries accurately is apparently a complex topic. I could tell you all about how to make shared libraries on the Mac, but I have only a theoretical understanding of them on other systems. I could try to update my patches and submit PRs to you, but I'm not confident that I would make the best choices for everyone.

    If you used libtool to generate the shared libraries, it would know the right thing to do on every operating system. Is there a reason why you don't use it here?

    opened by ryandesign 1
Releases(4.6.2)
  • 4.6.2(Nov 18, 2021)

    • see github site for complete details (github.com/thestk/stk)
    • bug fixes in LentPitShift and Granulate classes
    • Makefile fixes
    • miscellaneous bug fixes
    • updated versions of RtAudio, RtMidi and ASIO SDK files

    A distribution of the release with the configure script and documentation already generated is available at:

    • https://ccrma.stanford.edu/software/stk/release/stk-4.6.2.tar.gz
    
    Source code(tar.gz)
    Source code(zip)
  • 4.6.1(Apr 18, 2019)

    • see github history for complete details
    • various documentation updates
    • new Recorder (flute a la Verge) class (thanks to Mathias Bredholt)
    • updated Modulate class to allow noise rate control
    • new VS2017 project files
    • fix in FileLoop::getSize() to return file size (not chunk size)
    • updated versions of RtAudio and RtMidi

    A distribution of the release with the configure script and documentation already generated is available at:

    • https://ccrma.stanford.edu/software/stk/release/stk-4.6.1.tar.gz
    
    Source code(tar.gz)
    Source code(zip)
  • v4.6.0(Sep 1, 2017)

    • see github site for complete details
    • various build system updates
    • fixes in FileWvIn / FileLoop for normalisation and scaling, as well as file opening
    • bug fix for MAT-files in FileWrite
    • bug fix in MidiFileIn.cpp for timing and time-code formats
    • updated versions of RtAudio and RtMidi

    A distribution of the release with the configure script and documentation already generated is available at:

    • https://ccrma.stanford.edu/software/stk/release/stk-4.6.0.tar.gz
    Source code(tar.gz)
    Source code(zip)
  • 4.5.1(Feb 23, 2016)

    • fix for FileWvIn / FileLoop classes to avoid keeping files open if not necessary
    • miscellaneous bug fixes, documented on GitHub site (github.com/thestk/stk)
    • update to play.cpp example to play mono files as stereo
    • bug fix in DelayL::setDelay() function
    • miscellanous build bug fixes

    A distribution of the release with the configure script and documentation already generated is available at:

    • https://ccrma.stanford.edu/software/stk/release/stk-4.5.1.tar.gz
    Source code(tar.gz)
    Source code(zip)
  • 4.5.0(Apr 26, 2014)

    • updated versions of RtAudio and RtMidi, with associated renaming of RtError class to either RtAudioError or RtMidiError and addition of WASAPI support in Windows
    • added support in FileRead for little-endian AIFC file format
    • new iOS project files (thanks to Ariel Elkin)
    • bug fix in FreeVerb that could cause crackling for stereo input
    • various bug fixes and updates to minimize compiler warnings
    • ADSR fix for decay/release time calculations
    • various updates to build system
    Source code(tar.gz)
    Source code(zip)
Digital Signal Processing Library and Audio Toolbox for the Modern Synthesist.

Digital Signal Processing Library and Audio Toolbox for the Modern Synthesist. Attention This library is still under development! Read the docs and ch

everdrone 79 Jun 18, 2022
Open-source node system framework, to change your algorithmic code into useful tools to create much more complicated simulations!

Open-source node system framework, to change your algorithmic code into useful tools to create much more complicated simulations!

Zenus Technology 563 Jun 26, 2022
A minimal header-only audio synthesis and processing library

Aurora A minimal header-only C++ audio synthesis and processing toolkit. Getting Started Aurora is a collection of header files which can be included

null 11 Apr 27, 2022
The AudioUnitSDK contains a set of base classes as well as utility sources required for Audio Unit development.

The AudioUnitSDK contains a set of base classes as well as utility sources required for Audio Unit development.

Apple 68 May 17, 2022
Digital control and signal processing library for DSPs developed in C

digital-control Overview Thisis a simple C library containing very useful digital control and signal processing functionalities destinated for DSP's a

CLECIO JUNG 2 Jun 8, 2022
Aquila is a digital signal processing library for C++11.

What is Aquila? Aquila is an open source and cross-platform DSP (Digital Signal Processing) library for C++11. Example #include "aquila/aquila.h" int

Zbigniew Siciarz 383 Jun 22, 2022
PLP Project Programming Language | Programming for projects and computer science and research on computer and programming.

PLPv2b PLP Project Programming Language Programming Language for projects and computer science and research on computer and programming. What is PLP L

PLP Language 5 Jun 23, 2022
A toolkit for pointcloud processing, including: filter, bounding box, ground segmentation, cluster

A toolkit for pointcloud processing, including: filter, bounding box, ground segmentation, cluster. And implemented by different algorithms(some with pcl wrapper). c++17 supported

Au1ong 8 Jun 23, 2022
StarkScript - or the Stark programming language - is a compiled C-based programming language that aims to offer the same usability as that of JavaScript's and TypeScript's

StarkScript StarkScript - or the Stark programming language - is a compiled C-based programming language that aims to offer the same usability as that

EnderCommunity 5 May 10, 2022
The PNT Integrity Library provides users a method to verify the integrity of the received GPS data and ranging signals, thereby improving resiliency against potential GPS signal loss.

PNT Integrity Library The PNT Integrity Library provides users a method to verify the integrity of the received GPS data and ranging signals, thereby

Cybersecurity and Infrastructure Security Agency 40 Apr 28, 2022
Vectron VGA Plus generates a [email protected] VGA signal and has an interface that works with retro computers or microcontrollers.

Vectron VGA Plus Vectron VGA Plus generates a [email protected] VGA signal and has an interface that works with retro computers or microcontrollers. Screen

Nick Bild 29 Jun 7, 2022
6D - Pose Annotation Tool (6D-PAT) - is a tool that allows the user to load a set of images and also a set of 3D models and annotate where in the 2D image the 3D object ist placed.

6D - Pose Annotation Tool (6D-PAT) For detiled explanations checkout the WikiPage. What is it? With 6D-PAT you can create 6D annotations on images for

Florian Blume 59 Jun 14, 2022
multi-sdr-gps-sim generates a IQ data stream on-the-fly to simulate a GPS L1 baseband signal using a SDR platform like HackRF or ADLAM-Pluto.

multi-sdr-gps-sim generates a GPS L1 baseband signal IQ data stream, which is then transmitted by a software-defined radio (SDR) platform. Supported at the moment are HackRF, ADLAM-Pluto and binary IQ file output. The software interacts with the user through a curses based text user interface (TUI) in terminal.

null 57 Jun 20, 2022
mstatus is a super minimal entirely signal based statusbar for DWM.

mstatus is a uber-minimalistic signal based statusbar for DWM. All components of the statusbar are modules that must either be written by the user, or written by someone else and copied by the user.

Thomas Voss 1 Feb 2, 2022
JUCE Signal Generator

JUCE Signal Generator Application This project serves as a re-introduction to JUCE programming (I haven't used it since under-grad, circa 2012). Build

Tom Wilson 1 Dec 22, 2021
Thread aware Signal/Slot library

CsSignal Introduction CsSignal is a library for thread aware Signal/Slot delivery. This library does not depend upon CopperSpice or any other librarie

CopperSpice 56 Jun 27, 2022
C++11 signal/slot implementation

sigslot C++11 signal/slot implementation Requirements c++11 How to use For a code sample, see test.cpp class Emitter { public: Signal<int>

Supergrover 70 Jun 21, 2022
oZKS (Ordered Zero-Knowledge Set) is a library that provides an implementation of an Ordered (and Append Only) Zero-Knowledge Set.

Ordered Zero-Knowledge Set - oZKS Introduction oZKS is a library that provides an implementation of an Ordered (and Append Only) Zero Knowledge Set. A

Microsoft 6 Mar 25, 2022