EXS 24 Logic Sampler Users Group

I should mention that Logic tech support did offer a solution.
However, I feel that it's so impractical and unorthodox that it's not
even worth mentioning.  My plan -- until Logic offers a satisfactory
upgrade to the EXS24 -- is to record a single EXS24 (audio instrument)
track...violin, for example.  Then create as many other additional
tracks as necessary to accomodate the program changes I want:
sustained long notes, staccato, diminuendo, tremolo, etc...  I'll then
cut notes from my original track and paste them into the other EXS24
tracks I've created that have the programs I want.  After I've
completed this cut and paste separation of my violin track I'll bounce
them all together into a single audio track.  It sounds completely
ridiculous to have to even think of doing such a thing, but I don't
know of any better alternative.

Mike Policastro
ArtsGuild, Inc.
Franklin Park, NJ
732-951-9595

This idea of an EXS24 instance loading new instruments during the playback
of a song is more problematic than some seem to suppose. 

This operation is going to put a serious load on your sample drive if the
instruments being loaded are at all large. Think about how long it takes
some of them to load when the transport isn't running. Do you think this
would disrupt playback of your big orchestral mix? 

This is one of the reasons why Giga on a separate machine is more suited to
this approach - all the resources of the machine are devoted to sample
playback and gig files also have the option of compression to accelerate
loading. It would be great if EXS24 also operated in stand alone mode or
better still if it could work with another instance of the Logic mixer on a
second machine. Of course synching multiple machines introduce all sorts of
issues and things like delay compensation go out the window.

The best solution at present is to load all your instrument sounds into
separate instances.

Regards,
Murray

On a fine day, 08-03-2004, artsguildinc wrote:

>I should mention that Logic tech support did offer a solution.
>However, I feel that it's so impractical and unorthodox that it's not
>even worth mentioning.  My plan -- until Logic offers a satisfactory
>upgrade to the EXS24 -- is to record a single EXS24 (audio instrument)
>track...violin, for example.  Then create as many other additional
>tracks as necessary to accomodate the program changes I want:
>sustained long notes, staccato, diminuendo, tremolo, etc...  I'll then
>cut notes from my original track and paste them into the other EXS24
>tracks I've created that have the programs I want.  After I've
>completed this cut and paste separation of my violin track I'll bounce
>them all together into a single audio track.  It sounds completely
>ridiculous to have to even think of doing such a thing, but I don't
>know of any better alternative.

A better alternative along the same lines would be: create a channel 
splitter and cable it into max. 16 EXS instances.  Assign the channel 
splitter to the midi track.  Now open a Matrix window, with a 
floating event list.   In the Matrix select the notes you want to 
assign to e.g. the 3rd EXS, and in Event change their channel to 3. 
Sure beats having to cut & paste across different sequences -- both 
w.r.t. amount of work, and conceptually (since all notes remain in 
the original sequence).

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

I don't know why the EXS dosn't respond to midi's MSB(?) messages to first select the bank 
(then ya send a prg#)?... I'm doing that now with my emu stufff in Logic because of 
multiple roms or banks... I suppose the MSB message could select a folder at least...
rRand

From: Julie Larson <julielarson@...>

>So....if you've got all of your exs instruments loaded into separate
>tracks....How do you access them them from your midi controller?
>You're not making a program or bank change...what message do you send?

You just select the track you want, and that's the one you're 
playing. If you want to get tricky with multiple zones, you insert 
and then bypass an I/O plug-in on each channel you want to be active.

  From: ArtsGuildInc@...

>At first, I work one track at a time.   All violin, for example.   I
>concentrate on the composition at first.   Then once everything is 
>written, I start to
>sculpt the sequences to sound realistic.   Part of this process would be
>creating other exs24 tracks with different violin programs: i.e. 
>violins playing
>pizz., trremolo, etc...   So, from my original violin track/sequence, I cut
>notes and paste them into the other violin tracks that have different exs24
>violin programs (pizz, trem,...).   Once all the notes are separated into the
>appropriate tracks with the program sounds I want. I bounce them down into one
>audio track.\ufffd\ufffd\ufffd
>
>I've heard other suggestions on how to similate program changes on exs24, but
>they really don't seem practical to me.   This seems like the best way for me
>to work until Emagic comes out with a version of Logic or the EXS24 that
>supports automated program changes in a practical way.
>
>Mike Policastro

That's the way everyone works, Mike, and program changes are just a 
subtle variation of the same technique. I've written many times that 
a real-time performance interface is the next hurdle for sampling 
technology. The sounds are certainly there, but you can't perform 
them in real time yet. If the Yamaha VL1 can respond the way it does 
to input, then selecting the appropriate articulation in response to 
your performance can't be impossible.
-- 
___
Nick Batzdorf
818/905-9101, fax -5434, cell 590-9101

On a fine day, 08-03-2004, artsguildinc wrote:

>  >I should mention that Logic tech support did offer a solution.
>>However, I feel that it's so impractical and unorthodox that it's not
>>even worth mentioning.  My plan -- until Logic offers a satisfactory
>>upgrade to the EXS24 -- is to record a single EXS24 (audio instrument)
>>track...violin, for example.  Then create as many other additional
>>tracks as necessary to accomodate the program changes I want:
>>sustained long notes, staccato, diminuendo, tremolo, etc...  I'll then
>>cut notes from my original track and paste them into the other EXS24
>>tracks I've created that have the programs I want.  After I've
>>completed this cut and paste separation of my violin track I'll bounce
>>them all together into a single audio track.  It sounds completely
>>ridiculous to have to even think of doing such a thing, but I don't
>>know of any better alternative.

It's not ridiculous, it's the way people do it every day all around 
the world. Again, program changes aren't going to make a real 
difference; the fundamental problem is that you still have to 
*program* music instead of performing it.

From: Hendrik Jan Veenstra <h@...>

>A better alternative along the same lines would be: create a channel
>splitter and cable it into max. 16 EXS instances.  Assign the channel
>splitter to the midi track.  Now open a Matrix window, with a
>floating event list.   In the Matrix select the notes you want to
>assign to e.g. the 3rd EXS, and in Event change their channel to 3.
>Sure beats having to cut & paste across different sequences -- both
>w.r.t. amount of work, and conceptually (since all notes remain in
>the original sequence).

Well, that would be a different way to do it in some situations, but 
not necessarily a better one when you're dealing with 100+ 
articulations loaded up at a time across multiple machines.

Yes it takes time to program music well, but splitting notes is not 
as big a deal as it sounds. You have a screenset with an Arrange 
window on the left and a Matrix (or whatever) editor on the right; 
select the notes, click on the destination track in the list on your 
left, and Paste at Same Position.*

It's close to mandatory to have two monitors (or one very large one), 
but that's just part of the overhead.

* MasterTracks Pro had a feature 5000 years ago that would be great: 
an All button that selected all underlying MIDI data - i.e. all 
associated controller data - when you selected notes or a region in 
their Matrix-equivalent window.
-- 
___
Nick Batzdorf
818/905-9101, fax -5434, cell 590-9101

At 09:25 AM 03/09/2004, Nick wrote:
>I've written many times that
>a real-time performance interface is the next hurdle for sampling
>technology. The sounds are certainly there, but you can't perform
>them in real time yet.

There just aren't enough knobs and buttons, fingers and feet available for 
the mind-boggling selections now available in the libraries---even with 
very clever programming. I see fancy foot controller boards in our future. 
We'll all start to look like harpists, changing pedal positions on the fly, 
and will need the limb independence of drummers.

Thanks Nick,
Yeah....I just wanted to be able to change the "active" track from the 
keyboard.  I've done it though...just assigned a midi command to the 
select next track command in the key command window.  Don't know why I 
didn't think of it sooner.  I guess I just don't deal too much in 
performance issues.

Thanks again

julie

On Mar 9, 2004, at 11:25 AM, Nick Batzdorf wrote:

> From: Julie Larson <julielarson@...>
>
>  >So....if you've got all of your exs instruments loaded into separate
>  >tracks....How do you access them them from your midi controller?
>  >You're not making a program or bank change...what message do you 
> send?
>
>  You just select the track you want, and that's the one you're
>  playing. If you want to get tricky with multiple zones, you insert
>  and then bypass an I/O plug-in on each channel you want to be active.
>


[Non-text portions of this message have been removed]

Nick wrote:

>  >I've written many times that
>>a real-time performance interface is the next hurdle for sampling
>>technology. The sounds are certainly there, but you can't perform
>>them in real time yet.

From: Sean McCoy <osr@...>

>There just aren't enough knobs and buttons, fingers and feet available for
>the mind-boggling selections now available in the libraries---even with
>very clever programming. I see fancy foot controller boards in our future.
>We'll all start to look like harpists, changing pedal positions on the fly,
>and will need the limb independence of drummers.

It's more a matter of selecting the right articulation automatically, 
the way I see it. For example, if blew quickly into a breath 
controller, it could know to switch to an articulation with a harder 
attack or a rapid rise. Or if you start very slowly, it would know to 
switch to a program with a longer attack, etc. I've done some playing 
around with a rate of change controller without much success, but 
that's just because my programming skills aren't refined enough to 
make the programs respond well to a breath controller.

Some track-switching is always going to be necessary, but I think a 
lot of it could be done in real time. It's just a matter of some 
intelligence to know which of several keyswitch programs to switch to.
-- 

Nick Batzdorf
818/905-9101, cell 590-9101, fax 905-5434

At 07:58 AM 03/10/2004, you wrote:
>It's more a matter of selecting the right articulation automatically,
>the way I see it. ......
>
>Some track-switching is always going to be necessary, but I think a
>lot of it could be done in real time.

I like your thinking, Nick. It's science fiction, of course, but I like it 
anyway. But then, most of what we do every day was science fiction not too 
long ago...

On Thursday, March 11, 2004, at 02:05  AM, exs-users@yahoogroups.com 
wrote:

> That's the way everyone works, Mike, and program changes are just a
> subtle variation of the same technique. I've written many times that
> a real-time performance interface is the next hurdle for sampling
> technology. The sounds are certainly there, but you can't perform
> them in real time yet. If the Yamaha VL1 can respond the way it does
> to input, then selecting the appropriate articulation in response to
> your performance can't be impossible.
> -- 
> ___
> Nick Batzdorf
> 818/905-9101, fax -5434, cell 590-9101
>
>

Interesting thread. IMO the technique of using orchestral samples to 
simulate the real thing is all in the hands, feet and ears.
I am terrible at doing this, no matter how I try. I will always hand 
that work on to an expert.
The reason I feel I can contribute to this thread is because I have 
learned that no matter what great samples I have at my disposal it is 
my lack of playing technique that will always let me down.
I also try to layer this with that and bring that up under this and 
find a great room ambience etc. Never works for me.
But I've watched and seen it done by a friend of mine so I know it can 
be done.
When he programs it's all about playing technique. He is a master of 
the pitch wheel, the volume control AND a foot pedal controlling the 
filters of the EXS. It's a performance and it all happens all at the 
same time.
He usually mixes his programing under the real score in his film 
soundtracks but there have been occasions when his computer strings 
were superior to the real ones.
So maybe it's not the tools or the method of manipulation. Perhaps more 
time should be spent on performance and creating the correct parts.
It's very hard to do and like learning any instrument, there is a 
lifetimes work involved.
Phil Buckle.

On 10.03.2004, at 16:58, Nick Batzdorf wrote:

> For example, if blew quickly into a breath
> controller, it could know to switch to an articulation with a harder
> attack or a rapid rise. Or if you start very slowly, it would know to
> switch to a program with a longer attack, etc. I've done some playing
> around with a rate of change controller without much success, but
> that's just because my programming skills aren't refined enough to
> make the programs respond well to a breath controller.

I never tried a breath controller but this problem sounds more like a 
matter of sampling than of programming. It is similar with keys: 
hammering down very fast should select a "harder" sample.

As far as I know wind's and reed's producing a soft tone (long attack) 
is never loud and a sharp blow mostly results in a louder tone. If you 
can live with this than the usual velocity switching with two or more 
zones will work reasonable.

There is certainly an over-proportional amount of work necessary to get 
a more realistic behavior. I believe in real live it is very hard to 
play a gentle but high tone on a transverse flute because you need some 
pressure. And sometimes those tones have more breath noise than 
auditable pitch. You see were we are going - it's the direction of the 
huge sample libraries of these days.

I am not sure if I should work many many hours to force an EXS nearer 
to Andersons's flute on a much harder way than Ian Anderson himself - I 
haven't even a flute :-)


Peter Ostry

On 10.03.2004, at 16:58, Nick Batzdorf wrote:

>  > For example, if blew quickly into a breath
>>  controller, it could know to switch to an articulation with a harder
>>  attack or a rapid rise. Or if you start very slowly, it would know to
>>  switch to a program with a longer attack, etc. I've done some playing
>>  around with a rate of change controller without much success, but
>>  that's just because my programming skills aren't refined enough to
>>  make the programs respond well to a breath controller.

From: Peter Ostry <po@...>

>I never tried a breath controller but this problem sounds more like a
>matter of sampling than of programming. It is similar with keys:
>hammering down very fast should select a "harder" sample.

No, no, it's much more complicated than that, and I'm thinking about 
playing keys with a breath controller being used for extra 
expression. I play EWI as well, but that's just a variation.

Advanced libraries like VSL have plenty of velocity layers, and 
velocity (or modwheel) works very well for selecting them. But that's 
just a matter of selecting the right attack, or possibly the start 
point in a sample, or crossfading between layers (when that works).

I'm talking about "anticipating" (i.e. switching very quickly to) the 
right articulation in response to your playing. Do you want a really 
hard, short bow, for example? Then the natural thing would be to 
blast air in and stop blasting it in very quickly.

It's the *rate* of cc change that it has to read, not just the value.

But this is just one example. My point is that today you have to load 
up several violin articulations to program a performance well. Some 
of the switching could be done in response to your playing.

>As far as I know wind's and reed's producing a soft tone (long attack)
>is never loud and a sharp blow mostly results in a louder tone. If you
>can live with this than the usual velocity switching with two or more
>zones will work reasonable.

Yes, what we have today works really well. I'm just saying that the 
next big nut to crack is the performance interface.

>There is certainly an over-proportional amount of work necessary to get
>a more realistic behavior. I believe in real live it is very hard to
>play a gentle but high tone on a transverse flute because you need some
>pressure. And sometimes those tones have more breath noise than
>auditable pitch. You see were we are going - it's the direction of the
>huge sample libraries of these days.
>
>I am not sure if I should work many many hours to force an EXS nearer
>to Andersons's flute on a much harder way than Ian Anderson himself - I
>haven't even a flute :-)

I play a Yamaha VL1 with an EWI for that kind of thing. It works beautifully.

That instrument came out 10 years ago, by the way.
-- 

Nick Batzdorf
818/905-9101, cell 590-9101, fax 905-5434

I see people occasionally referring to indications of memory usage for 
specific programs, or overall memory used or available after loading groups 
of programs, but I have no idea how to access that information. Can someone 
enlighten me? (still on OS 9.2.2)  Thanks,

Sean McCoy
Oregon Sound Recording

On a fine day, 11-03-2004, Nick Batzdorf wrote:

>I'm talking about "anticipating" (i.e. switching very quickly to) the
>right articulation in response to your playing. Do you want a really
>hard, short bow, for example? Then the natural thing would be to
>blast air in and stop blasting it in very quickly.
>
>It's the *rate* of cc change that it has to read, not just the value.
>
>But this is just one example. My point is that today you have to load
>up several violin articulations to program a performance well. Some
>of the switching could be done in response to your playing.

As far as rate of cc change goes: an obvious problem with that is 
that you play a note, the sampler picks a sample based on how hard 
you play/blow, starts playing the sample, registers a certain rate of 
controller change and then decides that, o no, we need another sample 
because this is going to be staccato...  So the sampler has to switch 
samples somewhere midway.  I yet have to see the 1st sample lib that 
will smoothly switch from one sample to another somewhere halfway 
without the sample-switch being completely obvious.  Now if we were 
talking _synths_ here, things would be a lot easier -- a synth is 
just a massive calculator, and so should be able to calculate any 
required smoothness in timbre changes.  But a sampler...

<speculation>
I wonder if samplers are the real future at all btw.  In a sense a 
sampler is the poor man's solution to a complicated problem.  You 
want strings that are as realistic as possible, so... you simply 
record (sample) them and use those recordings...?  Basically that's 
still the 30 year old mellotron approach (ignoring "artistic" uses of 
samplers, but thinking purely about recreation of e.g. orchestral 
sounds).
Isn't it far more likely that instead of some super-sampler with 
1000+ articulations and intelligent smooth-switching, that one day 
we'll have a 20 THz computer with physically modelled instruments and 
orchestras -- i.e. synthetic realtime sounds that closely mimic their 
acoustic counterparts?
The only downside then probably is that you'll actually have to learn 
to play a french horn before being able to correctly play the 
physically modelled electronic instrument :-)).
</speculation>

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

On a fine day, 11-03-2004, Sean McCoy wrote:

>I see people occasionally referring to indications of memory usage for
>specific programs, or overall memory used or available after loading groups
>of programs, but I have no idea how to access that information. Can someone
>enlighten me? (still on OS 9.2.2)  Thanks,

Finder: Apple Menu: About this computer.  The EXS takes its memory 
from the free system memory.  If you load a massive EXS instrument, 
you'll see Logic's memory usage increase and the free memory 
indicator decrease.  Not sure if there isn't another way to figure 
this out, but this is the most obvious one (to me at least, at 8 in 
the morning, after 5 hours sleep :)

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

Hendrik Jan Veenstra wrote:
> 
> <speculation>
> I wonder if samplers are the real future at all btw.  In a sense a 
> sampler is the poor man's solution to a complicated problem.  You 
> want strings that are as realistic as possible, so... you simply 
> record (sample) them and use those recordings...?  Basically that's 
> still the 30 year old mellotron approach (ignoring "artistic" uses of 
> samplers, but thinking purely about recreation of e.g. orchestral 
> sounds).
> Isn't it far more likely that instead of some super-sampler with 
> 1000+ articulations and intelligent smooth-switching, that one day 
> we'll have a 20 THz computer with physically modelled instruments and 
> orchestras -- i.e. synthetic realtime sounds that closely mimic their 
> acoustic counterparts?

Interesting speculation, Hendrik, especially since Nick has already 
mentioned his use of Yamaha's physical modelling technology, and I agree 
with you wholeheartedly.

I've been bitten by the physical modelling bug with the Yamaha VL70-m, 
so I can certainly understand how Nick would be keen on the idea of a 
sound source responding to your playing style with different 
articulations, etc. It's a wonderfully organic way to play a synth! Even 
with a puny 1 voice of polyphony the VL70-m became my all-time favourite 
synth as soon as I started playing it.

And like you, I don't see how a sampler could make good use of 
parameters like the rate of change of a controller.

I still think samplers will be perfect when a "photo-realistic" but 
relatively straight sound is required (and they'll chew up less CPU 
power), but physical modelling IS fantastic when you need lots of 
organic-sounding nuances!

Bring on Emagic's "Sculpture", I say! :-)

> The only downside then probably is that you'll actually have to learn 
> to play a french horn before being able to correctly play the 
> physically modelled electronic instrument :-)).

Awwww, diddums!!! ;-)

Realistically, I reckon it'd be handy to know something about the 
instruments you're emulating, but I don't think virtuosity'll be 
necessary. It's the same with samplers anyway, I reckon...

Once again, 
I don't know why the EXS (etc) doesn't just respond to midi's MSB messages to get beyond 
the 128 prg limit? 
I suppose one would hope the MSB message could at least select a folder & a preset 
within...

In logic MSB is in the Multi Instru object settings... 
MSB first selects the bank, then it sends a prg# (I believe)... 
I'm doing that now with my emu stufff in Logic because
of multiple roms in the Proteus2k or banks in the E4... 
rRand

On a fine day, 12-03-2004, randwman wrote:

>Once again,
>I don't know why the EXS (etc) doesn't just respond to midi's MSB 
>messages to get beyond the 128 prg limit?  I suppose one would hope 
>the MSB message could at least select a folder & a preset within...

128 banks of 128 programs would still give "only" some 16000 
programs.  Too little for quite a few users.  And such a system would 
require you to have folders with max. 128 sampler instruments, _and_ 
it would probably require you to not use nested folders (which would 
be utterly confusing -- which bank would a folder nested in a folder 
nested in a folder be?).

In other words: if they did what you ask, then within days people 
would find plenty of problems and shortcomings with the new system, 
and once more there would be something to complain about.  Heck, I 
already found 3 problems with your proposal even _before_ they 
implemented it :-).

Oh, and 4th problem: changing programs with a sampler isn't very 
practical.  If you have a busy song playing and then tell the EXS to 
load that 2 GB grand piano... well, good luck to you, but I'm quite 
sure Logic will simply grind to a halt and interrupt song-play. 
Better to have multiple pre-loaded instances of the EXS then...

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

At 11:09 PM 03/11/2004, you wrote:
>Finder: Apple Menu: About this computer.


Ah, thank you! I had never seen that before because I had always clicked on 
the apple while Logic was the front window, in which case it says "about 
Logic Audio" instead.

>The EXS takes its memory
>from the free system memory.  If you load a massive EXS instrument,
>you'll see Logic's memory usage increase and the free memory
>indicator decrease.


So apparently there's no way to differentiate between the memory assigned 
to Logic upon launch, and the free memory used by the samples loaded. 
Still, a simple before and after comparison does the job.

On a fine day, 12-03-2004, Sean McCoy wrote:

>  >The EXS takes its memory
>>from the free system memory.  If you load a massive EXS instrument,
>>you'll see Logic's memory usage increase and the free memory
>  >indicator decrease.
>
>So apparently there's no way to differentiate between the memory assigned
>to Logic upon launch, and the free memory used by the samples loaded.

Huh?  Sure there is:

>Still, a simple before and after comparison does the job.

Right...

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

On a fine day, 11-03-2004, Nick Batzdorf wrote:

>  >I'm talking about "anticipating" (i.e. switching very quickly to) the
>>right articulation in response to your playing. Do you want a really
>>hard, short bow, for example? Then the natural thing would be to
>>blast air in and stop blasting it in very quickly.
>>
>>It's the *rate* of cc change that it has to read, not just the value.
>>
>>But this is just one example. My point is that today you have to load
>>up several violin articulations to program a performance well. Some
>>of the switching could be done in response to your playing.

From: Hendrik Jan Veenstra <h@...>

>As far as rate of cc change goes: an obvious problem with that is
>that you play a note, the sampler picks a sample based on how hard
>you play/blow, starts playing the sample, registers a certain rate of
>controller change and then decides that, o no, we need another sample
>because this is going to be staccato...

>So the sampler has to switch
>samples somewhere midway.  I yet have to see the 1st sample lib that
>will smoothly switch from one sample to another somewhere halfway
>without the sample-switch being completely obvious.

Right, it doesn't exist yet. But I think there  are some ways the 
interface could be set up to work.

>  Now if we were
>talking _synths_ here, things would be a lot easier -- a synth is
>just a massive calculator, and so should be able to calculate any
>required smoothness in timbre changes.  But a sampler...

Maybe it would have to look at the MIDI performance and substitute 
articulations later.

><speculation>
>I wonder if samplers are the real future at all btw.  In a sense a
>sampler is the poor man's solution to a complicated problem.  You
>want strings that are as realistic as possible, so... you simply
>record (sample) them and use those recordings...?  Basically that's
>still the 30 year old mellotron approach (ignoring "artistic" uses of
>samplers, but thinking purely about recreation of e.g. orchestral
>sounds).
>Isn't it far more likely that instead of some super-sampler with
>1000+ articulations and intelligent smooth-switching, that one day
>we'll have a 20 THz computer with physically modelled instruments and
>orchestras -- i.e. synthetic realtime sounds that closely mimic their
>acoustic counterparts?
>The only downside then probably is that you'll actually have to learn
>to play a french horn before being able to correctly play the
>physically modelled electronic instrument :-)).
></speculation>

Maybe, but right now I don't know that any company is working on 
taking physical modeling in that direction. As I said, the Yamaha VL1 
does some emulations amazingly well, and it responds like an acoustic 
instrument. But you're right- the reason it didn't sell all that well 
is that you have to learn how to play it. It's not all that difficult 
to add that kind of control to your keyboard technique, but as Avery 
Burdette from Yamaha put it, "it sounds broken" until you do learn.
-- 

Nick Batzdorf
818/905-9101, cell 590-9101, fax 905-5434

Hi

What about in OS X ? The function doesn t seems to be there anymore.

Louis
> 
> 
>>> >  >The EXS takes its memory
>>> >>from the free system memory.  If you load a massive EXS instrument,
>>> >>you'll see Logic's memory usage increase and the free memory
>>> >  >indicator decrease.



[Non-text portions of this message have been removed]

At 07:58 AM 03/12/2004, you wrote:
>On a fine day, 12-03-2004, Sean McCoy wrote:
>
> >So apparently there's no way to differentiate between the memory assigned
> >to Logic upon launch, and the free memory used by the samples loaded.
>
>Huh?


I meant that there's a single indicator for Logic's memory usage, as 
opposed to separate indicators for Logic's program memory usage (which 
includes certain VSTI's) and its free memory usage utilized by EXS24.  Hey, 
I can wish it were laid out on a silver platter, can't I?

On Friday, March 12, 2004, at 10:31 AM, Gramophone wrote:

> Hi
>
> What about in OS X ? The function doesn t seems to be there anymore.
>
> Louis
>>
>>
>> The EXS takes its memory
>> from the free system memory.  If you load a massive EXS 
>> instrument,
>> you'll see Logic's memory usage increase and the free memory
>> indicator decrease.

Try Applications/Utilities/Process Viewer.

Take care
Jesse Widener

Thanks a lot.


louis
> 
> Try Applications/Utilities/Process Viewer.
> 
> Take care
> Jesse Widener
> 
> 
> 



[Non-text portions of this message have been removed]

On 3/15/04 7:25 PM, "Gramophone" <gramophone@...> wrote:
> Thanks a lot.
> 
> louis
>> 
>> Try Applications/Utilities/Process Viewer.

There is a VERY VERY VERY nice utility called "Bigtop" in CHUD package on
Apple develloper's site

Thanks in advance.

Best regards
 
Cyril Blanc
Independent Quantum Leap Symphony orchestra forum (QLSO) for Mac
http://groups.yahoo.com/group/qlso/"
A6 Andromeda forum :  http://groups.yahoo.com/group/A6_andromeda/"
Petition :  ³Support of the APPLE LaserWriter 300 in MAC OS X²
http://www.PetitionOnline.com/Ap1c1/petition.html

--- In exs-users@yahoogroups.com, Julie Larson <julielarson@m...> wrote:
> Thanks Nick,
> Yeah....I just wanted to be able to change the "active" track from the 
> keyboard.  I've done it though...just assigned a midi command to the 
> select next track command in the key command window.  Don't know why I 
> didn't think of it sooner.  I guess I just don't deal too much in 
> performance issues.


http://gate.tenhauser.com

I have a Key Switcher environment there that works just like key switching in Giga.