Subject: MAX Digest - 24 Feb 1999 to 25 Feb 1999 (#1999-65)
Date: Fri, 26 Feb 1999 00:00:20 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 6 messages totalling 212 lines in this issue.

Topics of the day:

  1. Deglitched Groove~
  2. preferences
  3. groove~ development (2)
  4. Presets in a bpatcher (2)

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

Date:    Wed, 25 Feb 1998 12:32:15 +0100
From:    wolfgang heiniger 
Subject: Re: Deglitched Groove~

>Take the right outlet of groove~ and run it into the right inlet of a
>cylcle~ that's loaded with a 512 sample windowing function stored
>in a buffer~ (ie. sine-like rise from 0.0 to 1.0, flat top, sine-like
>fall
>back to 0.0, and  written into the buffer~with a peek~, then stored on
>disk if you like). Then take the output of the cycle~ multiply it
>with the left outlet of groove~,

>and Voila! The amplitude rises and falls in sync with every loop!

well, I used that too, but that works fine only with "short" samples.
The longer your buffer is, the slower the ramps get. And with samples
longer than eg. 5 secs you start loosing attacks.

wolf

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

Date:    Thu, 25 Feb 1999 10:32:57 -0500
From:    Don Malone 
Subject: Re: preferences

using pcontrol
if i load a top level patcher from folder "T"
that contains a bpatcher from folder "x" in folder "B"
MAX forgets about folder "T"
both "T" & "B" are in the preferences
how can i remind MAX that "T" is still in the pathway?

btw how about curved patch cords so patches can look like my moog ;-)

happy tunes
Don

312)341-6477

Don't anthropomorphize computers. They hate that.

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

Date:    Thu, 25 Feb 1999 11:00:08 EST
From:    Bob Ostertag 
Subject: groove~ development

While we are discussing groove~, if anyone out there is interested in
developing a groove~ that can do forward/reverse looping that would be
GREAT!

I know you can do it with MAX patching.  But actually TRY it sometime.  If
you
want to be able to reliably switch, on the fly, between forwards, reverse,
and
forward/reverse looping.  The example patch that comes with MSP does not do
this.  It will quickly hang.  After extensive fussing around, I have a patch
that does this, but it requires a lot of MAX stuff, and since it has to be
executed with each pass of the sample, if you are trying to run a lot of
voices it really bogs everything down.

If it was all in an object, then all that horsepower could go to other
things.

Thanks!

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

Date:    Thu, 25 Feb 1999 11:58:02 -0800
From:    Jeff Rona 
Subject: Presets in a bpatcher

Has anyone found that preset objects that are within a bpatcher don't
appear to save their memory? My workaround has been to add READ and WRITE
messages to it and manually save them as a file. I suppose I could even
loadbang it in. But is this the way it should be?

:--------------------:
      Jeff Rona
:--------------------:
 jrona@earthlink.net
:--------------------:
    BE, HEAR, NOW
:--------------------:

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

Date:    Thu, 25 Feb 1999 15:09:36 -0500
From:    Stephen Kay 
Subject: Presets in a bpatcher

Jeff Rona:
>Has anyone found that preset objects that are within a bpatcher don't
>appear to save their memory? My workaround has been to add READ and WRIT=
E
>messages to it and manually save them as a file. I suppose I could even
>loadbang it in. But is this the way it should be?

Since you are not actually resaving the bpatcher, how can it save the
changes?  In other words, you've got a bpatcher that was originally
saved to disk as a patcher.  That has the presets file in it.  If you =

change the preset file, you must resave the original object to save
the changes.  Even if you save the enclosing main patcher, you
have not resaved the patcher that makes up the bpatcher. Therefore, =

your workaround is basically correct.

This also relates to the issue of making a collective or application
from a patcher.  Once you do this, your Max "document" becomes its
own application, and must have its own "documents" if you wish to
allow users to save changes.  In this case, the documents may take
the form of coll files, or preset files which must be loaded when
the app starts up.

I know that you recently joined the list.  Since we recently went
through a thread about presets, I won't recap it for everyone other
than to say that I (and others) recommend avoiding the preset
object other than a down and dirty method of saving changes, and
recommend using a coll object based system for storing and retrieving
data, as it is far more flexible and avoids many of the problems
associated with the preset object.

A comprehensive example patcher showing how to set up a coll-based
data storage and retrieval system for multiple UI objects in
multiple instances of bpatchers can be downloaded at:

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

Stephen Kay
--------------------------------------------------------------------
The MegaMAX Collection: =

   http://www.musikinetix.com/MegaMax/MegaMax.html
Free Max objects!:
   http://www.musikinetix.com/MaxCorner/PublicDomain.html
--------------------------------------------------------------------

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

Date:    Thu, 25 Feb 1999 12:53:33 -0800
From:    Alex Stahl 
Subject: Re: groove~ development

>While we are discussing groove~, if anyone out there is interested in
>developing a groove~ that can do forward/reverse looping that would be
GREAT!
>
>I know you can do it with MAX patching.  But actually TRY it sometime.  If
you
>want to be able to reliably switch, on the fly, between forwards, reverse,
and
>forward/reverse looping.  The example patch that comes with MSP does not do
>this.  It will quickly hang.  After extensive fussing around, I have a
patch
>that does this, but it requires a lot of MAX stuff, and since it has to be
>executed with each pass of the sample, if you are trying to run a lot of
>voices it really bogs everything down.

Here's a similar-but-different idea:

You know how you can send a list to line~ to make it generate several ramp
segments? And that in the new MSP update there was a comment that "line~ is
now sample accurate" (which may or may not imply that groove still isn't)?

Well, it seems to me that if there was a way to tell line~ to repeat a list
until a new list was received, and ideally even finish the current list
before jumping to a new list, then we might queue up lists and build long,
sample accurate chains of ramps for play~.

This could do many things, including I think what Bob's asking for from
groove~.

One little trick is to notice that line~ seems to understand how to make
zero-length line segments. For example send the following messages to a
line~ that's feeding a play~:

[0, 1000 1000 0 0 1000 1000 0 0 1000 1000] loops a one-second chunk forward
three times at normal speed ("start at zero, go to 1000 over 1000 msec,
then go to 0 over 0 msec, then go to 1000 again, etc);
[1000, 0 2000 1000 0 0 2000] loops backward twice at half-speed;
[0, 1000 1000 0 1000] is a single forward-backward loop.

This imaginary repeat mode would repeat only the last list received, so the
initial setting value in the above examples would not be repeated, which I
think would be a good thing. I guess since this is all imaginary it can be
all good.

Personally, I'd love to see real enhancements to line/play over groove
because I think they would be more flexible, for example you could make two
loops that stay in exact sync but are offset, or you might even use the
line to control recording into the buffer at the same time. Warning: don't
try this at home! It can thoroughly challenge your concept of "the same
time".

In any case, I'll bet either idea is easier to write than fixed-length
curved patch cords (which would be hilarious).

-Alex Stahl

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

End of MAX Digest - 24 Feb 1999 to 25 Feb 1999 (#1999-65)
*********************************************************