Subject: MAX Digest - 2 Apr 1998 to 3 Apr 1998
Date: Sat, 4 Apr 1998 00:00:30 -0500
From: Automatic digest processor 
Reply-To: MAX - interactive music/multimedia standard environments
     
To: Recipients of MAX digests 

There are 5 messages totalling 190 lines in this issue.

Topics of the day:

  1. MaxPlay Save erases patcher objects? (3)
  2. 3.5 - MUST use OMS??? WHY!?
  3. CD-ROM drives for audio

----------------------------------------------------------------------

Date:    Fri, 3 Apr 1998 16:14:27 -0000
From:    Nick Rothwell 
Subject: Re: MaxPlay Save erases patcher objects?

> Since the patch has a preset object and the user wants to save his
> presets, he goes up to the File menu and choses Save.

Is this supposed to do anything interesting in patchers run by
MaxPlay? I would have assumed that MaxPlay didn't do any kind of
patcher saving at all, and would be surprised if File->Save were
enabled or operational at all.

(Aside: does coll editing work either?)

For saving and restoring state in MaxPlay's patchers, or in
collectives or whatever, perhaps you should look into using my
Registry object (in http://www.cassiel.com/software/).

--
        Nick Rothwell, CASSIEL            contemporary dance projects
        http://www.cassiel.com            music synthesis and control

        NOTICE - this vessel has triple screws - keep clear of blades

------------------------------

Date:    Fri, 3 Apr 1998 11:36:33 -0800
From:    David Zicarelli 
Subject: Re: MaxPlay Save erases patcher objects?

Ben Thigpen, a.k.a. Nikki Halpern <101762.3705@COMPUSERVE.COM> writes:

>I make a patch & have the user open it in MaxPlay, so he won't
>accidentally change it and save the changes.  Since the patch has
>a preset object and the user wants to save his presets, he goes up
>to the File menu and choses Save.  Result:  He has successfully
>saved his presets, but from now on when the patch is opened (with
>Max or MayPlay) all the patcher objects are _empty_.

You're not missing anything. It's a bug. The solution would be
to use the menubar object to eliminate the Save item from the
File menu.

David Z.

------------------------------

Date:    Fri, 3 Apr 1998 11:43:30 -0800
From:    David Zicarelli 
Subject: Re: 3.5 - MUST use OMS??? WHY!?

Elliott Earls  writes:

>could some one please explain to why MAx 3.5 requires the USE of OMS!!!!
>
>am I missing something?? one of the really nice things about 3.0 was the
>ability to make a SUPER DUPER SMALL self contained standalone.

Elliot isn't missing anything either, except in the sense that
he misses the "native" MIDI driver included in Max 3.0 and
earlier versions.

This MIDI driver code was extremely hardware dependent, mostly
written in 68K assembly, and not really updated since the late
1980s. Can you say tech support nightmare? Sure you can. That's
why anyone who isn't a fool would rely on professionally-written
MIDI driver code by people who have the time and energy to
follow all of the stupid hardware changes that occur with each
new Powerbook.

Max 3.5 does not require OMS 2.x by the way (although the timein
and timeout objects will use OMS 2.x Timing services if available).

My favorite feature of 3.5 is that, unlike 3.0, it will actually
not worry about MIDI if it can't find a suitable MIDI driver.

David Z.

------------------------------

Date:    Fri, 3 Apr 1998 11:29:11 -0800
From:    David Zicarelli 
Subject: Re: CD-ROM drives for audio

Simon Gatrall  writes:

>Also, last time I checked there was a nasty bug with the CD input to adc~.
>It creates nasty distortion.  It may have been fixed in one of the last
>updates.

It was fixed in the version of 3/14, in the sense that I reduced the
amplitude of the audio input slightly so it wouldn't distort.

Those who think cd~ is a good idea for an object are right, it would
allow digital output through sound cards not possible when using the
Sound Manager. Think also of another reason it would be cool: instant
triggering of CD tracks, in the mannger of sfplay~, since locations
on the CD could be preloaded.

David Z.

------------------------------

Date:    Fri, 3 Apr 1998 15:23:17 -0500
From:    Stephen Kay 
Subject: Re: MaxPlay Save erases patcher objects?

>I make a patch & have the user open it in MaxPlay, so he won't
accidentally
>change it and save the changes.  Since the patch has a preset object and=

>the user wants to save his presets, he goes up to the File menu and chos=
es
>Save.  Result:  He has successfully saved his presets, but from now on
when
>the patch is opened (with Max or MayPlay) all the patcher objects are
>_empty_.

I just tried to duplicate your problem, and was unable to.  I put some
UI objects and a preset object into a patcher, saved some presets. I
connected a 'read' and 'write' message to the preset object, and saved
the patcher (with 3 presets in the preset object).

Opened it in MaxPlay 3.0.  Made a few new presets (up to 5). Clicked
'write' and wrote the preset file to disk.  Quit MaxPlay 3.0.  Loaded
MaxPlay again, and the patcher.  The patcher still has 3 presets in
the preset object (naturally, since that is the way it was saved). I
click on the 'read' message, and read in the preset file - I now have
5 presets in the preset object.

However, you will never be able to change the number of presets that
the patcher first loads with in MaxPlay.  If you saved it with 0 presets,=

it will have 0 presets when it is first launched.  The user must read
in the preset file every time upon opening the application.  That is
why I recommend you switch to storing data in the coll object.  Also,
the coll object is far more robust for development, and gets around
all the various problems that the preset object has (which you may =

not discover until your application grows to a certain size, such as
adding/removing UI objects screwing up the presets, inability to
store presets in bpatchers, etc. Data stored in coll files is easily
edited (as text), so you can add/remove parameters easily.) It's
much harder to get working initially, but then you can have data
files that load automatically when the user launches an app.  If you
want more info on how to do this, I think I have a tutorial I wrote
laying around here somewhere on how to set up a whole coll file
based memory management scheme.

>Nick Rothwell:
>Is this supposed to do anything interesting in patchers run by
>MaxPlay? I would have assumed that MaxPlay didn't do any kind of
>patcher saving at all, and would be surprised if File->Save were
>enabled or operational at all.

File->Save is enabled and operational if you use a menubar object.
I'm assuming he has a menubar object taking control of the Save/
Save As..., and is using those to read/write a preset file as I
outlined above. Therefore, it should work.

>(Aside: does coll editing work either?)

In the same fashion, editing a coll file will also work, provided
you write the changed coll file to disk, and then load it when
the app is reloaded.

You could also check out my 'collX' object, which allows you to
give a coll file custom creator and file types, so you can have
custom icons for coll files (not max icons) and also limit more
easily which types of files are available to be loaded into
various collXs (i.e. give different colls different file types,
and it will be impossible for the user to load a coll file meant
for one coll into a coll object storing data in a different
format).

collX is available for free at: =

http://www.musikinetix.com/Download/Download.html

Stephen Kay
---------------------- The MegaMAX Collection ----------------------
 Over 30 Max objects for the creation of more professional looking, =

         feeling, and functioning patchers and applications.
                     http://www.musikinetix.com
                         sk@musikinetix.com
--------------------------------------------------------------------

------------------------------

End of MAX Digest - 2 Apr 1998 to 3 Apr 1998
********************************************