added CMakelists based on https://github.com/arunoda/cmake-boilerplate.

mkdir _build
cd _build
cmake ..
make

will compile the lib and the standalone example, no iOS yet

Release build works; there's an odd stack-overwriting crash in the Debug build which is worth looking into further, since it seems to be triggered by the debug runtime's memory guards.

This is the same pull request as before, with fixes for all the demos and more illustration of the new features.

Smart Pointers

• Templated reference counting smart pointer TonicSmartPointer that is used instead of duplicate code in several places
• BufferFiller and all its subclasses are now true Generator subclasses wrapped in smart pointers, and can also be used as Generators (see SynthsAsGenerators.cpp for example)
• Synth no longer needs to be directly heap-allocated now that it's wrapped in a smart pointer. All demos and objects handling Synth instances now store as value rather than pointer.
  • Default constructor for Synth uses a passthrough generator, so uninitialized instances will produce no output

Sample Tables and Input

• Using a new class SampleTable to wrap instances of TonicFrames with shared data access, so the same data can be accessed in multiple places.
• TableLookupOsc uses these to provide the lookup table. Can be provided externally (ArbitraryTableLookupSynth) or by a subclass (SineWave).
• RingBuffer is a very simple ring buffer with over/underrun detection, based on SampleTable. Can be used to acquire/process input from a mic, etc (see the input demo - it will glitch out in the simulator fairly quickly, but that's a known simulator bug).

Misc

• TonicDictionary is an easier way to work with std::map for storing/retrieving objects keyed by strings.
• Mutexes removed from Generator level for performance reasons, no hot-swapping supported right now. Currently living in BufferFiller
  • Another approach is in this branch. Uses smart pointer for SynthContext, which owns the mutex and passes down to Generators. This approach needs review. @Dewb would you mind providing some feedback here? We can chat about it offline, too.

I was expecting RampedValue::setValue to result in a smooth ramp back to the target, rather than a hold at the value being set. Is there a precedient in some other system (Pd maybe?) for setValue on a ramp de-activating the ramp? Seems more intuitive to me if both setTarget and setValue operate more or less the same. In any case, RampedValue isn't idiot-proof, and I'd love it if we could make it more so.

The current state of the development branch is pretty stable, IMO. I'd like to get it into master soon-ish.

The primary changes are:

• Windows demo(s)
• Universal smart-pointer usage for Synths
  • Smart pointer base class
• Input processing via RingBuffer
• Globally-registered sample tables
• Smart pointer pass-by-value fixes
• Multiple other fixes, some fairly critical

@Dewb if there are still any loose ends for Windows that you'd like to get in before this goes to master, can you tie those up (ideally in the next few weeks)? Thanks.

Linux build configuration is getting closer but still needs some attention. Personally I'd prefer to put that off til a future merge in the interest of continuing to move things forward.

In addition to accepting an "index" parameter, controlswitcher now accepts an "advanceTrigger" parameter, which increments the index.

I've started working on this in the MP-ThickLeap3 branch. Here's my plan:

To Synth, add the following methods ControlUIMessenger addUIMessenger(string name); void addUIMessageResponder(string name, UIMessageResponder* resp);

UIMessageResponder is an abstract class with one method, which is called (on the UI thread) when a value changes. A lambda function would be better, but I don't think oF is using C++11 yet. Might be worth adding a C++11 preprocessor macro and giving the option to add a lambda instead of an object pointer.

ControlUIMessenger is a ControlConditioner which can store a UIMessageResponder.

The end result of all of this is we can have ControlGenerators in our signal chain which contain callbacks which are set by UI code. A couple things to figure out:

• How does the UI thread actually trigger the callbacks?
  • My first thought is to add a uiTick method to Synth, and have the UI call this on every frame.
• How can we support ControlUIMessengers that aren't part of the regular signal chain?
  • Maybe we just don't. It's assumed that the messengers need to be part of the generator graph.
• It would be nice if any ControlGenerator could just have a exposeToUI(string) method. This would take some thought to work out though, since it would mean we wouldn't be able to just call a method on the Synth to register the messenger.

This is what Nick was describing a while back -- an object that can take an arbitrary number of inputs, and an index which is used to control which of the inputs is used.

I would like to point out that identifiers like "__Tonic__TonicCore__" and "__Tonic__BufferPlayer__" do not fit to the expected naming convention of the C++ language standard. Would you like to adjust your selection for unique names?

Nick -- I'm guessing you're on this page already, but wanted to be explicit about it just in case. I like the idea of always tying timing of ControlGenerators (the Metro object you mentioned, for example) to tics, rather than using any sort of system-based clock. Advantages of this:

• better cross-platform-wise
• enables off-line rendering
• stops with the debugger

Looks to me like ControlGenerators which need to have a sense of advancing time can handle that just fine based on the hasChanged method, though I wonder if a more explicit tick method might be a good idea for controlGenerators too. ControlGenerator::tick() could return a ControlGeneratorTickStatus flag like ControlGeneratorTickStatusValueChanged or ControlGeneratorTickStatusNoValueChange.

context.forceNewOutput is set to true in the constructor, which results in the code below sending a trigger signal.

 inline void ControlValue_::computeOutput(const SynthesisContext_ & context){
      output_.triggered =  (changed_ || context.forceNewOutput);
      changed_ = context.forceNewOutput; // if new output forced, don't reset changed status until next tick
      output_.value = value_;
}

When I try to compile the code as shown in your video, I get errors:

/Users/scherbakov.al/Desktop/Tonic-master/examples/Standalone/TonicStandaloneDemo/main.cpp:11:10: 'iostream' file not found /Users/scherbakov.al/Desktop/Tonic-master/src/Tonic/TonicCore.h:15:10: 'string' file not found /Users/scherbakov.al/Desktop/Tonic-master/src/Tonic/ControlConditioner.h:15:10: 'vector' file not found

(mac os 10.13.6, Xcode v.10.1) What could be the problem? I'm still quite a newbie. Thank you!

I have put a lot of thought about how to revive Tonic and i think all work on future versions should continue in a separate repository. I don't have a figure for how many projects use Tonic as it is, but there are 57 forks. That means to me that many people had to adapt tonic to their needs but it also means that overall what Tonic has to offer is great. Because of that I'd give retaining compatibility with the existing code base the highest priority. My suggestion would be to reject any API breaking changes and new features. We should also try to avoid changes that effect sound synthesis maybe even when the synthesis would be more correct. Security related issue should still be accepted. I'd like to do something like this:

• Rename Tonic to Tonic1
• Create a project named Tonic2 which initially is a copy of Tonic1
• Initially focus on creating benchmarks and tests for Tonic2 and hunt down problems
• Find out what the users need. Dig through the forks.
• Define goals based on those findings.
• Reevaluate existing issues based on those goals and fix where it makes sense.
• Here be dragons

You are all invited to continue in your respective roles in the new repository. If you want a different role that's alright with me.

I think your input would be very helpful. What do you think?

Would be great if there were a way for Tonic to process audio coming in to a system over Mic/Line inputs - as far as I can tell there is currently no way to do this with a component? If not, then adding an InputSource component would prove fruitful for those of us using Tonic for audio processing ..

When Tonic has just started and context.elapsedTime < sPerBeat in ControlMetro, CM will trigger first not right away but with a sPerBeat-context.elapsedTime delay.

I'm about to make a number of pull request, but realized the current upstream project file makes merging a pain, so first off I cleaned it out:

• Team and Dev IDs have been removed (compiles OK)
• Values where defaults are the same have been removed.
• Project-level values are used instead of identical target level values.
• Testability value added (by Xcode)
• Background Audio property removed (by Xcode)
• Mixed up deployment target now 7.1 for the whole project.