EXS 24 Logic Sampler Users Group

I think the current way to navigate through your sound is absolutely 
hopeless. Very annoying. Why don't they implement a drawer or add a 
panel on the bottom (for MacOS X) which works the same as column view 
in the finder? This would be much more logical and much more handy.

Remco

> From: Remco Muntz <rmuntz@...>
> 
> I think the current way to navigate through your sound is absolutely
> hopeless. Very annoying. Why don't they implement a drawer or add a
> panel on the bottom (for MacOS X) which works the same as column view
> in the finder? This would be much more logical and much more handy.
> 
> Remco
> 
> 

Co-sign!!!!!!!!!!!!!!!!

>  > From: Remco Muntz <rmuntz@...>
>>
>>  I think the current way to navigate through your sound is absolutely
>>  hopeless. Very annoying. Why don't they implement a drawer or add a
>>  panel on the bottom (for MacOS X) which works the same as column view
>  > in the finder? This would be much more logical and much more handy.
>
>Co-sign!!!!!!!!!!!!!!!!

Good ideas
Include me please

Regards - Colin

I agree that an OS X style column browser would be an improvement 
over the current (hierarchical menus) EXS file management system.

However, it seems to me that the larger issue is whether the current 
EXS file structure (with separate samples and instruments) is the 
best solution.  I'd almost prefer a self-contained instrument / 
sample file along the lines of Soundfonts (without the cheezey 
Soundfont limitations).

Of course, combining samples and instruments into one file would 
inevitably lead to quite a bit of duplicate sample data on your hard 
drive.  However, since we'll probably see 200 GB drives for under a 
hundred bucks in a year or two (if not sooner), I don't think this 
is a such big concern.

I think the operative design philosophy for the EXS file management 
system should be ease of use and not disk space conservation.  Self-
contained files would eliminate the current hassle / confusion 
relating to sample data conflicts. Moreover, you would no longer 
need to scan / "resolve" the EXS sample locations in order to speed 
up the instrument browsing and loading process.

I'm curious what other people think about this suggestion.  All I 
know is that managing my current 50 GB EXS sound library is a total 
pain in the ass.  There has to be a better way.


--- In exs-users@yahoogroups.com, Colin Shapiro <musos@i...> wrote:
> >  > From: Remco Muntz <rmuntz@g...>
> >>
> >>  I think the current way to navigate through your sound is 
absolutely
> >>  hopeless. Very annoying. Why don't they implement a drawer or 
add a
> >>  panel on the bottom (for MacOS X) which works the same as 
column view
> >  > in the finder? This would be much more logical and much more 
handy.

> >
> >Co-sign!!!!!!!!!!!!!!!!
> 
> Good ideas
> Include me please
> 
> Regards - Colin

>However, it seems to me that the larger issue is whether the current 
>EXS file structure (with separate samples and instruments) is the 
>best solution.  I'd almost prefer a self-contained instrument / 
>sample file along the lines of Soundfonts (without the cheezey 
>Soundfont limitations).

I don't like that idea in the least.

>Of course, combining samples and instruments into one file would 
>inevitably lead to quite a bit of duplicate sample data on your hard 
>drive.  However, since we'll probably see 200 GB drives for under a 
>hundred bucks in a year or two (if not sooner), I don't think this 
>is a such big concern.

I think it is. For once you forget us notebook people. There
even 60GB aren't yet that common. Not to speak about bandwidth.

>I think the operative design philosophy for the EXS file management 
>system should be ease of use and not disk space conservation.

I don't think these are opposite goals.

>Self-
>contained files would eliminate the current hassle / confusion 
>relating to sample data conflicts.

This could be easily "solved" by adding an optional checksum to
identify the samples.

However your suggestion does drop another IMO very nice feature:
as of now when you tweak a sample you can do so by an external
program. Once you'd done some editing you simply start the EXS
and already the samples are included with your instruments. Do
some more tweaking etc.

Your suggestion obviously does drop this.

Not to speak of the additional hazzle by having yet another
soundfile format.

>Moreover, you would no longer 
>need to scan / "resolve" the EXS sample locations in order to speed 
>up the instrument browsing and loading process.

You know about EXS Manager, do you ?

>I'm curious what other people think about this suggestion.  All I 
>know is that managing my current 50 GB EXS sound library is a total 
>pain in the ass.  There has to be a better way.

I can't imagine blowing this up into a 200 GB SF-like EXS sound
library will greatly improve here.

As I asked above: you know about EXS Manager ?
If not it is high time you get it: http://www.redmatica.com/

Best,
Michael
--
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 For a good time, call 1-800-3IBMOS2
 GPG/PGP-keys available on request or at public keyserver

on 5/31/03 3:24 AM, hottesttoddy at hottesttoddy@... wrote:

>>I agree that an OS X style column browser would be an improvement
>>  over the current (hierarchical menus) EXS file management system.


I'd be happy just to see a file selector that stayed open like a logic
window.  Can't tell you how many time's I been looking for a EXS instrument
buried deep in the hierarchy found it, and had to let go of the mouse to do
something, and then have to go back in to find it again.  A stay open OSX
column style window would be great!  find a file and double click to open
the EXS instrument on the current track.

JR




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

On a fine day, 31-05-2003, hottesttoddy wrote:

>However, it seems to me that the larger issue is whether the current
>EXS file structure (with separate samples and instruments) is the
>best solution.  I'd almost prefer a self-contained instrument /
>sample file along the lines of Soundfonts (without the cheezey
>Soundfont limitations).

Ohw, that's by far the worst suggestion I could imagine...  So if you 
have a 250 MB piano and make 5 variations of it, you would end up 
having 1.25 GB of data???  Not a very nice idea.
And then you discover that the "C3 mf" sample has a small transient 
spike at the end which you'd like to edit out... but you now have to 
perform the same edit 5 times instead of only once...
IMO there's nothing wrong with having samples and "sample mapping 
files" (instruments).  I do agree though that EXS file management and 
esp. navigation could (and should) be improved massively.

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.omega-art.com/

>You know about EXS Manager, do you?

I used to run Logic on my PC but switched back to my Mac even before 
Apple purchased Emagic.  Before the switch back to the Mac, I was in 
fact using EXS Manager on the PC.  But it was a less-than-optimal 
solution.  Every time I would create a new EXS instrument (with new 
samples), I would have to either wait 15 minutes (!) for the EXS to 
scan my 50 GB library or run EXS Manager again.  God, what a drag.

The situation was so unworkable that I ended up buying a processor 
upgrade for my Mac just so I could run Logic on my Mac again.  I'm 
now a happy camper with the EXS on my 1GHz Mac.

Incidentally, on the Mac you don't need to perform any of 
this "resolving" samples BS.  It's still a bit slow to open the EXS 
Instrument flip menu when when your sound library grows beyond a few 
gigabytes, but at least the system is usable.  And now with the 
Project Manager in Logic 6, you can perform an EXS Manager -style 
scan as well if you really want to.

> Ohw, that's by far the worst suggestion I could imagine...  So if 
you 
> have a 250 MB piano and make 5 variations of it, you would end up 
> having 1.25 GB of data???  Not a very nice idea.
> And then you discover that the "C3 mf" sample has a small 
transient 
> spike at the end which you'd like to edit out... but you now have 
to 
> perform the same edit 5 times instead of only once...
> IMO there's nothing wrong with having samples and "sample mapping 
> files" (instruments).  I do agree though that EXS file management 
and 
> esp. navigation could (and should) be improved massively.

Think this through a bit more before dismissing the suggestion out 
of hand.  You wouldn't need to duplicate a 250 MB piano five times!  
You would just store all the variations within the Instrument / 
Sample file the same way you can with Soundfonts.  This would be 
much more convenient since all your variations would be stored 
within one file for easier file management and portability.

Also, it would be really simple to implement a "sample edit" button 
within the EXS editor so that a sample (your C3 mf) would open in 
your editor of choice and get automatically updated.  Sort of the 
way SampleCell used to work.

Anyway, with the new Project Manager, Emagic basically assumes that 
you would WANT to save your Instruments/Samples (and all other files 
associated with the song) with each song.  So you're probably going 
to duplicate that piano anyway.

I don't think my suggestion is completely daffy as this is the 
approach Native Instruments is taking with the next version of 
Kontakt.  You'll still be able to organize your library the old 
(i.e., lame) way, but you'll also be able to save a complete multi 
and all its programs and samples in a single file.

> From: "hottesttoddy" <hottesttoddy@...>
> 
>> Ohw, that's by far the worst suggestion I could imagine...  So if
> you 
>> have a 250 MB piano and make 5 variations of it, you would end up
>> having 1.25 GB of data???  Not a very nice idea.
> 
> Think this through a bit more before dismissing the suggestion out
> of hand.  You wouldn't need to duplicate a 250 MB piano five times!
> You would just store all the variations within the Instrument /
> Sample file the same way you can with Soundfonts.  This would be
> much more convenient since all your variations would be stored
> within one file for easier file management and portability.

this would be a bitch when it's time to back up your projects. say u have
that 250mb piano file and u edit something in the "instrument" part of it.
this means u have to shove another 250mb to backup every time u make a small
change like that.

very important imo

/nassau

On a fine day, 01-06-2003, hottesttoddy wrote:

>  > Ohw, that's by far the worst suggestion I could imagine...  So if
>  > you have a 250 MB piano and make 5 variations of it, you would end up
>  > having 1.25 GB of data???  Not a very nice idea.
>
>Think this through a bit more before dismissing the suggestion out
>of hand.

<thinking through...>  Uhm, still don't like the idea :-).  I simply 
don't like proprietary formats where a bunch of files are packed into 
one archive-like construct, such that you can no longer access 
individual files without using special software (the EXS in this 
case).  A file should simply be a file -- out there in the open and 
ready for me to do with it whatever I like.

>You wouldn't need to duplicate a 250 MB piano five times!
>You would just store all the variations within the Instrument /
>Sample file the same way you can with Soundfonts.

So if I have one collection of samples and use different filter 
settings for various songs, I would be forced to back up the entire 
xxx meg worth of samples instead of the few kb that an instrument 
file is?  Still don't like the idea...

>This would be much more convenient since all your variations would be stored
>within one file for easier file management and portability.

A solution for the backup/portability problem would be an option to 
"collect all used soundfiles", much like QuarkXpress allows you to 
"collect all files for output" when sending print-stuff to a 
print-shop.  But then, the EXS already _does_ have this option, 
doesn't it?  So I fail to see the problem, to be honest.

>I don't think my suggestion is completely daffy as this is the
>approach Native Instruments is taking with the next version of
>Kontakt.

I didn't say it was daffy.  I just said I didn't like it -- matter of 
taste.  And the fact that some company decides to implement something 
some way doesn't necessarily mean your idea is _not_ daffy :-).

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.omega-art.com/

There are definitely pluses and minues to each file management 
approach.  I'm really just playing devil's advocate with the 
Soundfont "all-in-one" file structure.

I guess I tend to move my sound library around more than some people 
do.  For instance, I might move some EXS Instruments (and samples) 
onto an external FireWire drive in order to go to a friend's studio 
to work on a track.  With the current EXS format, this can be a bit 
of a hassle (especially if the "destination" computer is a PC).  If 
all the EXS Instruments and associated samples were stored together, 
it would be much easier to move sounds from one studio to another.

But, to each his/her own. :-)


--- In exs-users@yahoogroups.com, Hendrik Jan Veenstra <h@k...> 
wrote:
> On a fine day, 01-06-2003, hottesttoddy wrote:
> 
> >  > Ohw, that's by far the worst suggestion I could imagine...  
So if
> >  > you have a 250 MB piano and make 5 variations of it, you 
would end up
> >  > having 1.25 GB of data???  Not a very nice idea.
> >
> >Think this through a bit more before dismissing the suggestion out
> >of hand.
> 
> <thinking through...>  Uhm, still don't like the idea :-).  I 
simply 
> don't like proprietary formats where a bunch of files are packed 
into 
> one archive-like construct, such that you can no longer access 
> individual files without using special software (the EXS in this 
> case).  A file should simply be a file -- out there in the open 
and 
> ready for me to do with it whatever I like.
> 
> >You wouldn't need to duplicate a 250 MB piano five times!
> >You would just store all the variations within the Instrument /
> >Sample file the same way you can with Soundfonts.
> 
> So if I have one collection of samples and use different filter 
> settings for various songs, I would be forced to back up the 
entire 
> xxx meg worth of samples instead of the few kb that an instrument 
> file is?  Still don't like the idea...
> 
> >This would be much more convenient since all your variations 
would be stored
> >within one file for easier file management and portability.
> 
> A solution for the backup/portability problem would be an option 
to 
> "collect all used soundfiles", much like QuarkXpress allows you to 
> "collect all files for output" when sending print-stuff to a 
> print-shop.  But then, the EXS already _does_ have this option, 
> doesn't it?  So I fail to see the problem, to be honest.
> 
> >I don't think my suggestion is completely daffy as this is the
> >approach Native Instruments is taking with the next version of
> >Kontakt.
> 
> I didn't say it was daffy.  I just said I didn't like it -- matter 
of 
> taste.  And the fact that some company decides to implement 
something 

> some way doesn't necessarily mean your idea is _not_ daffy :-).
> 
> -- 
> Hendrik Jan Veenstra  <h@...>
> Omega Art: http://www.omega-art.com/

> this would be a bitch when it's time to back up your projects. say 
u have
> that 250mb piano file and u edit something in the "instrument" 
part of it.
> this means u have to shove another 250mb to backup every time u 
make a small
> change like that.


If the software was smart enough, you wouldn't need to save 250 MB 
of data every time you make a small parameter change.  The program 
could easily keep track of what has changed since the last save and 
then save only those portions of the data (just parameter data or 
individual samples if necessary) that have been updated.

This saving method has been in place for at least 8 years now.  For 
example, the Roland S-760 has a "Save Parameters" function that 
doesn't require a full sample save in order to update your patches.

I know this sounds a "bit" arrogant, but you guys are not really 
thinking this through before posting your reservations.

Okay, now that I sound like a complete know-it-all, I should say for 
the record that I do indeed understand that there are advantages and 
disadvantages to each approach.

On a fine day, 02-06-2003, hottesttoddy wrote:

>For example, the Roland S-760 has a "Save Parameters" function that
>doesn't require a full sample save in order to update your patches.

Ah, you mean something like the EXS's "save instrument" command? :-)) 
So, that brings us back to where we already were, doesn't it?

-- 
Hendrik Jan Veenstra  <h@...>
Omega Art: http://www.omega-art.com/

I've thought that using OS X's bundles would be an ideal solution.  An 
.exs file could contain all the samples, should the user/developer 
choose, and access to the individual .wav files would be as easy as 
choosing "Show Package Contents" under the contextual menu like you can 
do now for any application.  Then you could still save an .exs file 
with any programming changes as a separate file without the samples, or 
a sub patch within the uber .exs file like .gig files have.  To me this 
makes managing sample content a lot easier.

On Monday, June 2, 2003, at 06:56  AM, exs-users@yahoogroups.com wrote:

> <thinking through...>  Uhm, still don't like the idea :-).  I simply
> don't like proprietary formats where a bunch of files are packed into
> one archive-like construct, such that you can no longer access
> individual files without using special software (the EXS in this
> case).  A file should simply be a file -- out there in the open and
> ready for me to do with it whatever I like.

At 12:35 PM 6/2/2003 -0400, you wrote:
>I've thought that using OS X's bundles would be an ideal solution.  An
>.exs file could contain all the samples, should the user/developer
>choose, and access to the individual .wav files would be as easy as
>choosing "Show Package Contents" under the contextual menu like you can
>do now for any application.  Then you could still save an .exs file
>with any programming changes as a separate file without the samples, or
>a sub patch within the uber .exs file like .gig files have.  To me this
>makes managing sample content a lot easier.

That's a good idea.

My preference would be an option of saving as one file, saving as separate 
files, or everything inbetween.

It's like Pagemaker, you can link a graphic to an external file, or include 
it in the file, and you have control for every instance where it happens.

Just imagine, just add a check box in the Zone - "Save data in file"

Garth Hjelte
Sampler User

hi,

i'd like to know if the below is caused by my system or if someone
(everyone) else is experiencing this:

the window behavior in LAM 6.x under os 9 is somewhat broken.
when i use os 9 window "shrink" or "reduce to titlebar" feature (the icon in
the upper right corner of a window) the window shrinks as usual but: it will
open as soon as the mouse touches (for example to move) the titlebar.

this is especially irritating for the exs (and other instrument foats). i
often double click on the exs window to have a look whats underneath. but
now the windw always gets into my way only when i move the titlebar.

if someone could please let me know if this is a new bug in 6.x or do i have
to reinstall my system software.

thanks

ulf.

sorry, i used a wrong subject line for my message below

> hi,
> 
> i'd like to know if the below is caused by my system or if someone
> (everyone) else is experiencing this:
> 
> the window behavior in LAM 6.x under os 9 is somewhat broken.
> when i use os 9 window "shrink" or "reduce to titlebar" feature (the icon in
> the upper right corner of a window) the window shrinks as usual but: it will
> open as soon as the mouse touches (for example to move) the titlebar.
> 
> this is especially irritating for the exs (and other instrument foats). i
> often double click on the exs window to have a look whats underneath. but
> now the windw always gets into my way only when i move the titlebar.
> 
> if someone could please let me know if this is a new bug in 6.x or do i have
> to reinstall my system software.
> 
> thanks
> 
> ulf.

hi,

could someone do me a favor and test the below.
i reinstalled my system, but logic 6 remains close to unusable with the
behavior mentioned.

it simple & tankes two seconds:

in os 9.2 click on the very upper righthand conrer icon in the title bar of
a window. with window will collapse and remain as a title bar only, now try
to drag the window.
in my case the window unfolds which is wrong according to os 9 guidelines
and does not to this in any other app or logic < 6.

it would be of great help to me to know if this is a bug in logic of still
my system.

thanks in advance,
ulf.

> sorry, i used a wrong subject line for my message below
> 
>> hi,
>> 
>> i'd like to know if the below is caused by my system or if someone
>> (everyone) else is experiencing this:
>> 
>> the window behavior in LAM 6.x under os 9 is somewhat broken.
>> when i use os 9 window "shrink" or "reduce to titlebar" feature (the icon in
>> the upper right corner of a window) the window shrinks as usual but: it will
>> open as soon as the mouse touches (for example to move) the titlebar.
>> 
>> this is especially irritating for the exs (and other instrument foats). i
>> often double click on the exs window to have a look whats underneath. but
>> now the windw always gets into my way only when i move the titlebar.
>> 
>> if someone could please let me know if this is a new bug in 6.x or do i have
>> to reinstall my system software.
>> 
>> thanks
>> 
>> ulf.

On a fine day, 08-06-2003, uswitalski@... wrote:

>in os 9.2 click on the very upper righthand conrer icon in the title bar of
>a window. with window will collapse and remain as a title bar only, now try
>to drag the window.
>in my case the window unfolds which is wrong according to os 9 guidelines
>and does not to this in any other app or logic < 6.
>
>it would be of great help to me to know if this is a bug in logic of still
>my system.

I'll get my LA6 upgrade somewhere next week (hopefully). If you still 
haven't had  a response to this question, ask again in a week or so, 
and I'll test it.

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

>>in os 9.2 click on the very upper righthand conrer icon in the title bar of
>>a window. with window will collapse and remain as a title bar only, now try
>>to drag the window.
>>in my case the window unfolds 

Just checked it and, yes, you're right. If you try and drag the 
title bar with the window collapsed, it moves but also opens up. 
Very strange. I would definitely say this is a bug.


-- 
Eli Krantzberg
Nightshift Orchestra / Almat Productions
http://www.nightshiftorchestra.com

thanks eli,

so i guess it _is_ a bug.
well at least i got a fresh installed system now...

i think for a company owned by apple its a pretty big one to break their own
os guidelines.

pfff,

thanks again,
u.

>>> in os 9.2 click on the very upper righthand conrer icon in the title bar of
>>> a window. with window will collapse and remain as a title bar only, now try
>>> to drag the window.
>>> in my case the window unfolds
> 
> Just checked it and, yes, you're right. If you try and drag the
> title bar with the window collapsed, it moves but also opens up.
> Very strange. I would definitely say this is a bug.
> 
> 
> -- 
> Eli Krantzberg
> Nightshift Orchestra / Almat Productions
> http://www.nightshiftorchestra.com
>

> so i guess it _is_ a bug.

> pfff,


It is, as is this same kind of odd behaviour that has been in there 
since 6.0: 
Doubleclicking the titlebar (same as clicking the square if 
checked in the finder preferences) closes the window, but 
clicking it once opens it up again, where it used to be doubleclick 
also. Very annoying, especially for people with less screenspace 
who open and close plugin windows in this manner often. (I can 
tell, cause I used to, duh).

Slowly it starts to grow on me that 6.x might be the least stable 
update ever, with all the bugz and cucarachas! Are we ever going 
to see Emagic act like say Propellerheads, who's software is 
stable as a house upon release!!

O.