Implementing multiple multisamples as sound sources

RobLo...Maybe that will help you...


https://app.box.com/s/yqoojcd6amu558rst760cr9shh42hej5

 

Thank you, Yerry.
RobLo, there is a Kontakt version from SQ80 by an english software builder called crosswave.
No the builder is binarymusic. The product is Crosswave SQ-80!

 

The author of SQ8L(ight) passed away in 2014

Today it's more than 4 years later.

 

Very sad to hear...his SQ8L was a great inspiration. Still today, one if the best emulations of any hardware synth.

 

Thank you for this!

 

Robert, I found a collection by christian (2002): 227 aif. Are they the same you own? And a readme (2010)

 

Yes, that's the same set.

 

It's the Ensoniq SD-1 by Yerry similar to your ESQ-1? If yes you can create more snapshots please.

 

Similar in that it still uses the wavetable architecture. Has a good amount more features.

I haven't had the chance to open the ensemble to see the guts. If it used a lookup table for the oscillators that would be awesome for a template, or a starting point, to make the ESQ-1/SQ80.

I'm also going to go by Arachnauts suggestion to build the signal path with basic oscillators first, this way the infrastructure is complete and can just swap the wavetable oscillators in place once they are satisfactory.

This is very much a beginner project for me as I'm very raw with primary...and know nothing in core. So I have little knowledge of how much, if any, core will be needed.

 

I build in primary. If there is a core macro I use it but don't built in core or little smalls like in X/Y Modular. If Yerry is the builder he used a lot of samplers inside.
In the aif folders are more than one multiy-wave. Have they sound sound in layers or can we put them all (227) in a file containing more than 128 samples? In TSM a HG Fortune clone I have 384 samples in one map. Three banks á 128 controlling by a bank switch and sample select.

 

That's what the OP's concern was...how to map the multisamples. Basically, he wanted to know if he could just load all the multisamples into a single map and somehow have oscs 1,2 & 3 draw from the map...but so.eone mentioned Reaktor can only load the samples into memory once.??

Either way, Big Gnome laid out a solution. I haven't really wrapped my head around it yet. But will revisit that. I'm going to peek at the SD1 ensemble now.

 

Just looked at the SD1 ensemble....this is way over my head. I can't even see what the actual sample map modules are. The LFOs are also throwing errors when I try to route them.

Granted, the SD1 was a good deal more advanced than the ESQ/SQ so I'm still hopeful

 

So the two or three files in a folder are layers? To play at once?

 

Pretty sure this can't be done in primary directly since the primary samplers handle of both memory and playback (you could certainly do one and then save & load the map into the others). This would be doable in core, although I think it would be quite a bit more effort than it's worth--chances are you'd be trading three identical sample modules for as many tables containing the wave ROM and various information about the ROM map (e.g., sample length, etc.) Sample mapping in primary would be a lot more straightforward than rolling your own system in this case, although the new table framework may provide the best of both worlds--I'm no expert there, I'm afraid. While I've been critical of the primary's audio quality in terms of sample playback, I think in this sort of application it would be more than adequate as the hardware is A) nothing special in this regard, and is actually pretty mediocre even by the standards of the time, and B) mipmaps increasingly bandlimited waves in 8-note "buckets" to pick up the slack for the dodgy 80's transposition.

 

Thanks much for the responses.

Speaking of the mipmap approach Ensoniq used...how dodgy was the transposition in the ESQ-1 actually?? I'm no engineer by any stretch of the imagination....but I don't notice any aliasing. I am admittedly ignorant here.

I understand how bandlimiting deals with this at some level but I can't help look at some of the waveforms and think there's something huge missing in this equation. A few use a single cycle wave over an 8 note range only, seeing it on the sample map makes me cringe.

 

It's not awful or anything, but it is middle-of-the-road mid 80's vintage, and certainly nowhere near the same league as a contemporary E-mu or even like a Korg M1 (which is fine--old school Ensoniqs are aggressive, slightly crusty synths and I love them for that). Of course the ROM is laid out in such a way that potentially problematic upper partials are wicked away before they stress the interpolation hard enough to really be objectionable. Try this though if you have access to the hardware: with one of the brighter waves selected, dial in some fairly extreme pitch modulation via the mod wheel or an LFO or something. Modulation of course transposes a single wave, and once anything with a lot of harmonics (e.g., a sawtooth, or even one of the 'synth waves') is transposed more than, I don't know, an octave and a half or so, you're in alias city. Which can sound kind of cool.

 

SQ-80 in primary:
Big Gnome if you are afraid to build in core there is a possibility in primary. Send every sample by terminal to three or more receivers in each oscillator.
Any kind of receiver is your layer.

 

Hmm...do you have a working example of this?

 

No - all theoreticals. I'm on to bring TSM to version 3 with some beta testers.

Robert, please give me your example without the samplers. Do you build one?
Look, there is the module 'Beat Looper'. Load in a sample. Reaktor take an analyse. Name the module and the sender in the same name as the sample. Beat Looper can carry one sample only. Load as much as you need: 227 or 243. Now you've your radio stations. Set two or three receivers as layer. With pulldown menue it's too long and the letters are small. Take a spin or something with multitext. I use multitext in TSM3 for the sample names (384). Built not all at onces. For first time 10 or 20. And start layering.
If you've a sceleton from the first post in this thread - it's been wonderful.

If TSM3 is finished and uploaded I'll have a look. If someone have a basic instrument .. don't want to start at zero.

 

I may be misunderstanding you, but I'm quite sure you're mistaken--send/receive will neatly connect one thing to t'other, but in the case you describe, you'd just be sending a single oscillator to a variety of different locations.
By the way, I strongly prefer working in core personally, but an all-core approach to this would involve a ton of drudgery. Wavetable oscillators are fairly easy to build--the tricky part with this is managing all the metadata: the waves are mapped all over the place and moreover they are not a consistent length (although they are all powers of 2). None of that's insurmountable, but it does involve a ton of drudgery and rote data entry in getting the table to read the correct length from the correct position. The simple, low-level arrays that core tables are just aren't as well suited to this sort of thing as the primary samplers are.

I took a stab at a proof-of-concept basis for an oscillator using the table framework. I'm firmly convinced this is the best approach since it divorces all the wave memory stuff (handled in primary) from the reading stuff (handled in core); and I'm pretty sure the latter is more or less required for oscillator sync (in principle you could do that in with a Sample Lookup module, but then you'd be pushing all the issues with doing the whole thing in core into the rather less capable primary environment).