How do I build a simple breakpoint shaper?

Michael O'Hagan

Building my own little custom multi-breakpoint shaper has been a long standing goal of mine, but I have no clue how to actually build one.

Are there any good tutorials on building the simplest little breakpoint shaper possible.

I just want to create a sort of automation lane type device, I have a modified version of the MPB envelope that does the job, but I'm looking to build something smaller and less confusing to work with in the long term.

I want to make the simplest, most basic little breakpoint system as a learning point, something with the smallest number of parts to learn the basics of how to create a larger more complex one later.

Anyone here have any experience making a custom breakpoint system?

Thanks.

colB

'Simple' and 'breakpoint' are not words that should be in the same sentence in a Reaktor context ;)

A 'simple' one might not be similar internally to a complex one. You would have to approach it differently. E.g. a fixed number of breakpoints would be much easier than a system where breakpoints can be inserted and removed arbitrarily.

Something that just allows GUI control over breakpoints might look very different compared with something that allows some sort of modulation of points or curves via envelopes or LFO. Does modulation have to be reflected graphically?!

I would recommend that you sit down and work out your design, with every feature, in detail, before building. That way you won't get to the stage where you have to completely start again with a full re-write just to add a single feature later in development.

There are some breakpoint type things in the factory library and user library, start by reverse engineering those.

----------------------

Fundamentally, you need three sections:

interface, data structure(s), and output process.

The data structure needs to be implemented so that it can be updated by the interface in as flexible a way as possible, and be efficiently accesses by the output process.

The pitfalls here are to focus the design on the interface or on the output process. The intermediate data structure is the most important thing to get right, particularly if you want something scalable.

Come up with as many ways as possible to implement it, then for each one, consider how interface and output will work in the context of that approach. How access to and from the data structure can be passed around the larger structure, how will it be saved and loaded in snapshots, how will initialisation work...

e.g.

you might have a system where there are an arbitrary number of breakpoints, inserted and removed on the GUI interface, the output section accesses them serially using cubic interpolation to directly generate the output.

Or alternatively, you might have a system where the breakpoints are scanned every time they are edited, and processed using bezier curves into a much larger set of data that is then linearly interpolated by the audio rate output process.

Both of these have strengths and weaknesses, each having potential features that the other cant do.