E-mu Emulator Sampler User Forum for the EIII EII EI and EIII XP

Hello everyone,

I'm dissecting, as an example, a patch from the Universe of Sounds Vol1 called "Bass Picked" using EMXP.

Here is the following info about the voices and key area of the patch.

1.  C1 > D#1  -  Voice 1  -  Key/Root = E1
2.  E1 > G#2  -  Voice 1  -  Key/Root = E2
3.  A2 > E3  -  Voice 2  -  Key/Root = C#3
4.  F3 > C4  -  Voice 3  -  Key/Root = A3
5.  C#4 > E5  -  Voice 4  -  Key/Root = E4
6.  F5 > C6  -  Voice 4  -  Key/Root = E5

First, what I don't understand is why Voice 1 is mapped twice and not just once from C1 directly to G#2.  Also why not the same with Voice 4 being mapped from C#4 directly to C6.  Is there a technical or sound reason for this?  I notice lots of samplers do this but am not sure why.

Second,  I notice when converting this patch to SF2 using EMXP, everything is pitched up one octave.  So the patch now becomes the following:

1.  C2 > D#2  -  Voice 1  -  Key/Root = E2
2.  E2 > G#3  -  Voice 1  -  Key/Root = E3
3.  A3 > E4  -  Voice 2  -  Key/Root = C#4
4.  F4 > C5  -  Voice 3  -  Key/Root = A4
5.  C#5 > E6  -  Voice 4  -  Key/Root = E5
6.  F6 > C7  -  Voice 4  -  Key/Root = E6

Is this standard as well?  Of course you can just transpose everything up or down, but again I notice a lot of sampling translating programs do this.  I wasn't sure if there was a specific reason.

I notice that when doing any sort of conversion, having "four" samples in the example above mapped across "six" zones can create a lot of problems for other sample programs to understand.  It seems that if there simply was a "one to one" matching of a sample to a zone it would make things a lot easier in understanding the mapping structure.  In addition, having the key/root modified from the original can be tricky as well.  A bass sound now sounds like a guitar...laugh.  Why Voice 1 is mapped into two zones when it could be mapped to just one makes more sense.  Perhaps the sound quality or "stretching" of the sample too far is the reason.  Not sure.

Any insight into this structure would be greatly appreciated.  As I mentioned in the title, this all could come down to "basics" of sampling structure which I am attempting to catch up and learn.  Thanks!!

Jim

Very interesting question !

First, regarding the same voice being assigned to two successive key areas, e.g.
- V01 being assigned to both C1 > D#1 and E1 > G#2
- V04 being assigned to both C#4 > E5 and F5 > C6
In fact, key areas C1 > D#1 and F5 > C6 are not very useful and in practice are tuned to the same octave as their neighbouring key area.
The reason can be found in the transposition limits of the Emulator-II.
The Emulator-II can not transpose more than one octave up or down from the root key.
OMI has sampled the sounds of voice 1 and voice 4 at a pitch of E2 and E4 respectively. This means that the lowest playable key is E1 and the highest playable key is E5.
Normally two additional samples with another pitch should have been used to fill up the remaining lowest and highest keys, but... there was not enough memory available anymore (the 4 samples already take up 471155 bytes of the 485887 bytes available in the E-II)  
So OMI had three options:
- ignore these limits; the consequence would be that the lowest and highest keys would not be transposed any further and probably also sound a bit out of tune
- don't assign any sample to these keys; the consequence would be that these keys would be silent
- use existing samples and assign them explicitly again to the two remaining key areas but using a root key which is exactly one octave lower or higher than the one of the successive key area; the result is that the keys are "in tune" but "shifted one octave".
OMI seems to have chosen the last option; I would have chosen the second option ;)


Second, regarding the presumed transposition after conversion.
In fact, there's no shift in pitch at all.
Samplers use the root key relatively to the key area to which the sample is assigned.
So, a sample assigned to C1 > D#1 with root key E1 sounds exactly the same as the same sample assigned to C2 > D#2 with root key E2.
So from an audio point of view, there's no problem.
But from a practical point of view, one would have to use other keys (12 keys to the right) on a keyboard to hear the same sound/pitch.
However... fortunately even that is not true !
The reason is that EMXP is using the old E-Mu "key numbering system" to label the keys, while almost all other instruments use the MIDI key numbering system.
E.g. the lowest C-key on the physical keyboard of an Emulator-II or Emax is referred to as C1 by E-Mu.
But according to the MIDI standard, the key is called C2.
The MIDI note value that is sent when pressing this "C1" key on the Emulator-II is 36 (=C2 according to MIDI standard), and this is also the value used by EMXP when converting sound banks.
So the conversion results are correct.
You can check this by looking at the instrument's zone details of the SF2 file in EMXP: the E2 root key of the first key area is being reported as E1 by EMXP.

I admit this is quite confusing, but EMXP was originally based on the numbering system mentioned in the E-Mu Emax/Emax-II and Emulator-II manual. I don't know why E-Mu used another reference system, or whether this is simply an error in both the Emax manual and the Emulator-II manual (which state that their keyboard is covering the C1->C6 area) In fact the Emax-II manual is even more confusing because in the first chapters the keyboard is said to be C1->C6 while in the MIDI annex they start using the MIDI numbering system, hence C2->C7...
Anyway, I will probably change this in the next version of EMXP and start using the MIDI numbering system consistently.
For now, the most important thing to remember is that everything is OK "behind the scenes" - it's just another presentation of key labels on the screen output of EMXP ;)

///E-Synthesist

> Anyway, I will probably change [from C1->C6 versus C2->C7] in the next version
> of EMXP and start using the MIDI numbering system consistently.

Make it an Option rather than a forced change. I'd go for maintaining Legacy.

As for:
> OMI had three options - amd seems to have chosen to use existing samples and
> assign them explicitly again to the two remaining key areas but using a root key
> which is exactly one octave lower or higher than the one of the successive key
> area; the result is that the keys are "in tune" but "shifted one octave".

and

> I would have chosen the option to use existing samples and assign them explicitly
> again to the two remaining key areas but using a root key which is exactly one
> octave lower or higher than the one of the successive key area; the result is that
> the keys are "in tune" but "shifted one octave".

What prevents you from adding your way as an Option? Think Arturia: Update where
a change or an addition to the feature set makes sense.

In Emulator II terminology this would belong to module "Special"! ;)