EXS 24 Logic Sampler Users Group

NEW ZONE PARAMETERS:

xmix map: 	[off/A/B/ ...]
xmix source: 	[mid/vel/wheel/ctrl/rand1-x ... /cycle1-x ... ]
xmix sens: 

pitch source 	[mid/vel/wheel/ctrl/rand1-x... /cycle1-x...]
pitch sens:



///USAGE:///
Basically, direct control of a zone's level and/or pitch, with 
controlling values routed via factory-preset value mappers.



==MAP==
Assigning a zone to use preset range "A" or "B", allows an increase 
in controlling value to bring the zone's level up ("A" zone) or down 
("B" zone). Switch to "off" and you have default behaviour (no 
change). 


=SOURCE=
[velocity]
Layering two zones and setting one to "A" and one to "B", with source 
set to "velocity" then gives velocity crossfading.

[wheel/ctrlX, ...]
Setting source to a different controller source allows manual real-
time control. 

Note that each zone is still totally independent, in this scheme a 
zone being crossfaded doesn't need to "know" who its partner(s) are 
(or even if they exist), it's just responding to control values 
routed via a preset lookup table. Setting different combinations of 
zones to different controller numbers lets you adjust levels (or 
other things) real-time via a faderbank, or from environment faders, 
so you can adjust relative zone levels or mixes inside your patch as 
part of the song.

[randomX]
Setting the source to one of the "random" sources generates a new mix 
value randomly for each keypress, so if you have layered and xmixed 
string samples or hihat samples, each note played could have a 
slightly different (or very different!) mix balance. Very useful for 
making a repetitive hihat track come alive (some drum machines have 
a "human feel" function that does this).
Set zones to use the same random[X] source if you want them to be 
controlled by the same random values (eg random mix A/B), set to 
different random[X] sources if you don't. 

[cycleX]
"Cycled value" sources run through one of a preset chain of valued 
when triggered, so "cycle1" might just alternate between minimum 
and maximum, cycle2 might step between three values, and so on.  

=SENS=
"Sensitivity" would adjust how strongly the mapped source affects the 
mix, so for two zones being crossfaded, low depth values mean that 
you get almost a 50:50 mix over the full range with only slight 
variation via controller, the default central value allows continuous 
control from "full on" to "full off" over the controller range, and 
higher values produce "shelving" with a smaller central transition 
range.



=PITCH SOURCE AND SENSITIVITY=
Having zone pitch source and depth parameters would allow similar fun 
things - you could have the pitch of a sound's percussive component 
altering with velocity while the tonal part had constant pitch (quick 
cheaty resynthesis), or you could have a subtle random variation in 
pitch on each keystrike (humanising a boring string patch or making a 
hihat line more interesting without affecting the other drum 
instruments), or a more dramatic variation for arpeggiator-style 
cycling pitches, or special effects (eg random-pitch noise shots as 
part of a drumkit). Imagine a layered hihat where each strike 
simultaneously used a different mix of hihat samples (>Random1) and 
an independent random variation in pitch (Random2), and allowed a 
third  "strike" sound component whose level was independently 
adjustable by controller number and have /it's/ pitch cycling around 
a pseudo-random loop (random3) or alternating between a pair (or 
sequence) of pre-set values (Cycle1, 2, 3...) 
Fun!


//ADVANCED APPLICATIONS//

If we wanted to get carried away, there could be a range of other 
preset "zone mix" or "zone window" options that could be called up to 
facilitate fading or switching between more than two layered zones. 
So assigning a zone to use map "3f-A", "3f-B" or "3f-C" might call up 
a response map that corresponds to the start, middle or end of a 
three-zone fade, or using "3sw-A", "3sw-B" or "3sw-C" might allow the 
zone to sound at full level, but only over a window representing a 
(preset) third of the range.


Taken together, these extra parameters would mean that you could then 
do things like taking a guitar patch and fading a feedback tone in 
and out with the modwheel, and using another controller to bend the 
pitch of the feedback while the note stayed constant, or have pseudo-
arpeggiator effects operating on part of the sound, and alternating 
background fret noises on every other note, or every third note 
(and/or have the background "fretnoise" sample changing pitch or 
level at random, or cycling around a loop).  

Or you could have the ultimate sampled TR808 kit, where the user can 
call up a range of samples on different keys by controller number 
(one fader switches between different kick samples, another calls up 
different snares, etc) or have a range of snare samples that can be 
continuously mixed between, and the varying mix played into a song, 
or have the mix between three or four similar 808 snare samples 
changing on every note, to provide a nice natural-sounding variation.



I think all this ought to be fairly easy to implement, it's not 
adding any complicated extra layers ot the EXS structure, just a few 
extra parameters to the zone edit bit, and adding a few preset 128-
byte lookup tables, and implementing the random/cycle presets.

Oh, and some sort of patch "notepad" would be handy, so that the 
person writing the patch could tell the user exactly what's been 
programmed into the patch for controllers, human feel, expression, 
etc. 

=Erk=

Thoughts from the mind of erk_relativity, 09-07-2002:

>NEW ZONE PARAMETERS:
>[...]

All very good ideas imo, and fully seconded.  If only the EXS was 
multi-timbral, you could already do most of what you describe in the 
environment.  E.g. have a transformer set up as random map to 
randomly change the channel and thus pick a different sample (out of 
16) each time you hit a key.  Et cetera.  Even velocity mapping and 
x-fading would be possible with a multitimbral instrument.  Not as 
convenient as dedicated, implemented functions with dedicated 
controls, but it _would_ work.

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.ision.nl/users/h/index.html

* Audio thumbnails (ESX24)

To help with the speedy selection of sounds, ESX24 could have 
a "thumbnail create" function that automatically generates a short 
low-quality preview of a few notes being played in a patch, and then 
saves the result as as a 11.05kHz mono wave preview file with the 
same location and name as the patch file. Then when you navigate the 
patch select menus, you could be hearing previews of each sound 
passed over by the mouse without having to stop and load each patch 
every time.
A "reset all thumbnails" function could run through a range of 
patches or folders and generate new default audio thumbnails for 
every patch found.

Using a standard format like .wav for the previews would also mean 
that when you are organising and renaming your sounds with the 
operating system's file management functions, a quick double-click on 
the associated .wav file would let you hear what a particular patch 
is like, without having to load the thing into logic. 


The main justification for audio thumbnails obviously be their use 
with sampled instruments like the ESX24 that can take a while to load 
and which already take up  a lot of disk space, but once this sort of 
previewing system is added to logic, it might be nice to allow the 
users the option of also using it with other logic software 
instruments like the ES2, if they want to. It might be quite a flashy 
feature.

=Erk=

Improved patch selection.


* Patch names displayed on arrange page.

The arrange page already lets MIDI tracks display the current 
assigned patchname for a MIDI instrument, so it would be nice if this 
trick also worked for logic's own integrated instruments. 
At the moment you can get it to display the assigned "mixer channel" 
instrument name, but not the type of instrument selected 
(ES2/ESX/etc.), or the currently selected patch.



* Improved Folder/Patch select (all logic soft-instruments)

The arrange page already lets us quickly change banks and patches 
from the arrange page, but only for MIDI instruments -- it would  
be very useful to be able to do this with logic instruments, too.
If a track is set to use a logic instrument, the counterpart of the 
MIDI "bank select" popup list ought to be populated with the relevant 
instrument folder names, and the counterpart of the "patch number" 
popup list ought to be populated with the names of instruments in the 
currently selected folder. 
Then we'd be able to browse EXS24 and ES2 patches from the arrange 
page. It wouldn't hurt for the volume and pan parameters to be 
duplicated here, too.

If these patch controls acted like their "MIDI instrument" 
counterparts, we could then use the computer keyboard to step quickly 
between sounds (select bank/folder or program/patch field and use the 
cursor or "+""-"keypad keys), and perhaps also change value by 
incoming program change and bank change numbers, so that we could 
call up ES2 sounds from our MIDI keyboard panel. 

Admittedy changes to these parameters would have to be flagged up 
as "not recordable real-time", and some ESX patches would still take 
a while to load, but it would make selecting sounds much easier.
At the moment it can be a real chore dealing with things like 
imported 128-patch GM soundfont banks, if you are replacing your 
stock soundcard sounds with EXS sounds, you need to be able to get at 
them quickly. 

=Erk=

* Reading S1000 floppies (indirectly)

If you are trying to tempt long-term Akai users to migrate to ESX, 
then lots of those guys will have personal libraries that they want 
to use, which can't easily be transferred to CDROM for import into 
ESX24. 

The guys I know with S1000/2000/etc series machines have walls 
stacked with floppies! (the guys who have their libraries on hard 
drive still tend to have the floppies as backups).

So, the "reads S1000 disks" EXS feature becomes a heck of a lot more 
appealing if that means "reads your existing patches off floppy". The 
S1000 floppy format is just a cut-down version of the HD/CDROM volume 
format, so changing the routines slightly so that they also cope with 
info off floppy ought to be a doddle.

The one problem might be that PC diskdrives are a bit variable, and 
you might not want an ESX function that isn't guaranteed to work 
every time on every machine (or you might not want the ESX to be 
doing odd low-level disk stuff at all) ... I'd suggest that the way 
around this is to forget about ESX trying to access the floppy drive 
directly and to just let the program read the floppydisk image files 
that are created by various freeware apps.

User uses freeware to convert the S1000 floppy to an image file on 
their harddrive, then EXS imports the contents of the image file. 
Sorted! 

Next question: reading S900 floppies, too? Maybe not such an 
atractive option, dunno.

=Erk=