This forum section was originally created while we were discussing a new, additional engine and sampler format designed from scratch. In the meantime this resulted in our new SFZ2 engine, which is already implemented to a large extent. However this is still the right place for ideas, feature requests, drafts and plans for new engine / format concepts and ideas. We now have 3 sampler engines (Gig, SFZ2, SoundFont 2). Why not having more?

Event mapper* The mapper receive control events and note events as inputs. Internally it store states affecting mappings that control events will change.* It output a value or set of values that represents what the event and the current states map to.

Note event+ on/off+ channel+ key+ velocity

Control event+ controller+ value

MapsThe mapper has a set of maps loaded into it. Each map is just a nice way of grouping regions, let them share common settings and enable/disable a whole group of regions at once. All enabled maps are processed when mapping incoming events. Each map contain a set of regions and each region has a set of hi/lo parameters that should be evaluated by AND'ing them together during mapping of events.

Things like key switching, round robin and smart MIDI is implemented by a scripts enabling/disabling maps rather than directly in the mapper. (Update: On a second thought, key switching and round robin should be part of the mapper, otherwise it would just make things too complex.) The output value or values is completely source agnostic (while the mapper as a device is mostly useful for a set of locked ocillators i.e. samples) and the mapper can't be bothered with what it actually means as long as the source understands it.

Last edited by dahnielson on Thu Feb 28, 2008 1:19 pm, edited 2 times in total.

lowkey wrote:What about an environment like patchage, Reactor or energyXT. People would be able to patch modules how they want especially if if was compatible with ladspa or LV2.

Yes, but there are always Pd, Csound (with GUI editor) and the likes. I view the next generation design being more of a meta-sampler engine, if you see what I mean. That the reason I tried to stress the separation of engine definition and instrument loader (even though a completely native instrument could have them both baked in as a one-off). In addition to there being certain patterns when it comes to how building blocks are put together, instead of being complete free-form, that can be used to simplify the defining of engines and as I try to show without limiting what actually can be achieved.

Btw, I'm working on a larger block diagram to show how the stuff I've discussed so far would fit together.

Well, I'm glad to see some activity in this thread finally, at any rate.

I know we aren't really trying to build some twisted version of Reaktor here, but in a way, that's exactly what I'd like: the ability to make building blocks that can be combined with other building blocks made by anyone else. PD just doesn't do it for me, as I find it extremely difficult to understand its paradigm, which is odd considering it was supposed to be easy to understand. Reaktor, on the other hand, I managed to dive into right away and do cool things with.

If we can get the master framework to function, everything else can be made, as Anders said, from our own dog food. I find this prospect exciting, but it does seem to stray a ways away from the core mission of making a new sampler. I just don't see the point of a new monolithic sampler, though. We already have one of those, and it works great, and it's expandable in capability as it sits.

Consul wrote:The first question I have is, where would we start? This is a big project, and it needs planning. Top-down, or bottom-up? I can put together a design doc skeleton that we can fill in as we go. Or will this whole idea be rejected out of hand? I don't know. I personally don't see the point in just making another sampler with a fixed architecture. LinuxSampler as it is now already works great for that. I really want something I can dive into.

Personally, I'm happy with tossing around ideas for the moment. If you're going to try implement something, my advice would be to not make any big-plan-up-front but to implement the simplest thing that could possibly work.

At the moment, I'm not very interested in how things will actually be implemented. Because each basic building block could easily be a instance in a object-oriented programing paradigm or a function in a functional programming dito and be "patched together" either in their native source code syntax, a high level "DSP language" or simply expressed in XML. In the end all methods would have created the same synthesis and all would have shared the same patterns in doing so.

X2's main strength is that the cables are modulators. Reason's is that it has a Control Voltage paradigm so it was easy (for me) to see whats linked into what in a fun way (Im a sucker for wobbly cables lol). Shortcircuit's "spreadsheet" look makes it easy to see what's happening at a glance. VSampler is the most flexible sampler I've used but it really suffered because it didn't have a technical manual.

Reactor is a different world and Ive almost bought it twice (untill I came to my senses about how badly NI treats their customers) Even though you could get any sound you want out of it and has been like that for year's most people head's pop when they try to use it. You'd have to be a Synth Ninja to use it while composing!

lowkey wrote:Reactor is a different world and Ive almost bought it twice (untill I came to my senses about how badly NI treats their customers) Even though you could get any sound you want out of it and has been like that for year's most people head's pop when they try to use it. You'd have to be a Synth Ninja to use it while composing!

One of the best hardware synths was the modular Moog. But unless you were Wendy Carlos or had the resources to hire someone to do the job, like the Beatles, it was frustrating to get a decent sound out of it. Hench the Minimoog and the signal path we all know.

Wendy Carlos is one of my hero's. The Tron soundtrack still kick's ass after all these years. Delia Derberyshire http://en.wikipedia.org/wiki/Delia_Derbyshire is definitely my all time hero when it comes to sampling thoughHmm Doctor Who Theme

You have to think of Reaktor as being something of a synth-making application. At one level, you can load up lots of different instruments and use it as a straight synthesizer. At the deeper level, you get access to lots of DSP objects (adders and multipliers, delay lines, basic filters, etc.) which you can use to make your own synth pieces, which can then be made into a complete synth with GUI. If you're operating at the deeper level, you're being a scientist rather than a composer. You'll want to be a composer at the higher level, when you're done building your synth and it can be loaded as a VST instrument.

Like you, I really wanted to buy Reaktor (as part of NI Komplete, really), but I got stopped by not having the money (I had it together, but the reason I couldn't go for it is way to complicated to get into here), plus I'm not happy with the idea of being treated like a criminal by default. In short, if I want it, I'm going to have to make it myself.

The thing is, the commercial guys, like NI, have the best sounding stuff out there, it seems. Absynth's filters are just phenomenal. One thing I would really love to see happen is for some of the open-source audio people to get together as a sort of DSP think tank to develop algorithms for filters, oscillators, and the like, that will rival the commercial guys. Just some food for thought there.

To be complete, Delia Derbyshire did not compose the Doctor Who theme, but had recorded the first-used version of it. That in no way diminishes her genius, though. I personally think there are a lot of things we can learn from the BBC Radiophonics Lab and musique concrete in general. In fact, you'll find most of my feature requests for the new engine revolve around being able to mangle and process samples in interesting ways.