EXS 24 Logic Sampler Users Group

On a fine day, 08-05-2004, Sascha Franck wrote:

>Hendrik Jan Veenstra wrote:
>>  I agree that this would be nice,
>>  but 1) I guess such a change would involve some major coding on the
>>  part of the EXS programmers,
>
>No. It's allready working in case you're using the EXSP in Cubase. So the
>code is allready there.
>The Logic code is there as well as it's working with thrid party
>instruments.

Hmm... I feel tempted to say something about armchair programmers 
here :-)  The fact that the EXSP implements something doesn't 
necessarily say it's easy to implement the same feature in the EXS.

>I don't know why they don't implement such a thing into their own
>instruments, but as this was heavily asked for since years I can only
>imagine: Pure ignorance. Sorry to say so, but it just seems to be that.

Even though I myself don't feel the need for program changes as 
strongly as others (such a you) seem to do, I tend to agree with you 
here.  It _is_ rather bizarre that such a basic part of the midi-spec 
is totally ignored.  In my previous post I merely tried to explain 
why the programmers might have thought it wise/convenient to omit 
this part of the midi-spec.

>  > and 2) imagine having to hand-assemble
>>  your 10000 EXS instruments in 100 banks...
>
>Well, that's all up to you. I'd gladly put together some banks, just for the
>benefits of not having to either scroll through them with the mouse or load
>them incrementally by amounts of +/- 1.
>I would like to just sit at my MIDI keyboard and select program changes,

Agreed...  I too wouldn't mind being able to assemble an "all 
strings" bank and use prog-changes to select between them. Still: the 
fact that you can have 20000 instruments _might_ have been the reason 
prog-changes were never implemented.

>  > As for 1: one can wonder if you really want to do
>>  that with a sampler.  What happens if you load a 500 MB piano while
>>  20 other virtual instruments are playing and your CPU load is near
>>  the max?  Right...  I think it's far better and wiser and safer to
>>  just load up a second EXS instance and thus avoid the need for a
>>  program change mid-song.
>
>Yes and no. I agree with you on complexed patches, but very often I would
>just like to change one instrument a bit, maybe even using the same
>samples - a good example might be a string patch that I want to change from
>slow attack with vibrato to one with attack and no vibrato - fooling around
>automating these IMO is more of an effort than just inserting an appropriate
>program change).

Hmm... yes, you got a point here.  The only workaround I can think of 
is: load 2 EXs instances with different strings.  Send the midi notes 
trough a Cable Switcher (which thus should be used as the track 
instrument), and automate the switch position.  Rather 
straightforward, but the disadvantage is that the Cable Switcher 
track then can't contain automation data for the EXS's, for which you 
thus need 2 additional tracks.

>  > As for 2: since the whole setup is saved with the song there simply
>>  is no need to send the instruments a program change at song-start...
>
>Well, have you ever tried to playback some MIDI file using all 16 channels
>through the EXS?

I don't use midi files :-).  And if I ever have to, I use a simple 
midifile player that utilises the GM-bank from the quicktime synth.

>  > The drop down hierarchical menus are
>>  a navigational nightmare, and program changes would be just _one_ of
>>  many possible ways to overcome that problem somewhat -- but it
>>  wouldn't be the best possible way imo.
>
>Sure, there might be better ways in addition. But why not give us program
>changeability as a start?

Why not give us the _best_ solution from the onset?  Automation 
currently is 10-bit, allowing for 1024 possible values.  Hyperdraw 
and the environment objects are still 7-bit though.  It's thus 
impossible to utilise the full precision that automation allows if 
you don't have a Logic Control (which _does_ use the full 10 bits). 
So a good solution would be: rewrite the environment to allow for 
10-bit objects, update hyperdraw to allow for manual entry of 10-bit 
automation data, and introduce a new Fader Event (or an extended 
prog-change event, or whatever) that allow for 10-bit program- and 
bank-changes.  Then implement 10-bit banks in all Emagic instruments. 
Bingo: you get 1024 banks of up to 1024 instruments each, for a grand 
total of more than 1 million patches per virtual instrument.  It 
wouldn't even be difficult to design these 10-bit events such that 
they're downward compatible with the midi-spec's standard program 
changes, so that you would have the choice: either use the usual 
7-bit bank/prog changes (allowing for 128 x 128 instruments) -- in 
case you use an external midi controller -- or use the extended 
10-bit messages (allowing for 1024 x 1024 instruments) -- in case you 
use the 10-bit automation capability.

-- 
Hendrik Jan Veenstra   h @ k n o w a r e . n l
Omega Art: http://www.omega-art.com/