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

There are 10 messages totalling 507 lines in this issue.

Topics of the day:

  1. Presets in a bpatcher
  2. grab causing infinite loops/stack overflow.
  3. perennial PowerGlove question (2)
  4. groove~ development
  5. glitch-free play~
  6. looping with line~ and play~ (2)
  7. Bpatchers, presets
  8. groove~, play~, wave~

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

Date:    Fri, 26 Feb 1999 01:21:09 -0500
From:    Alex Burton 
Subject: Re: Presets in a bpatcher

 embedding the bpatchers in the main patcher will produce the desired
behavior. (to embed a bpatcher will basically make it a sub-patcher,
whereas an un-embedded bpatcher (default) acts as an abstraction). You
decide if you want it to be embedded when you create or "get info" the
bpatcher object. This applies not only to presets, but to all those objects
that can save data in a patcher (colls and tables must of course have their
"save with patcher" toggle on).

 *however*, i think embedded bpatchers are not extremely safe. Working with
them often generates weird behavior such as "zgetfn (pupdate): corrupt
object" and "freeobject: bad object" errors; i've had these happen just now
while testing the coll and preset when embedded. You have to be carefull
when modifying an embedded bpatcher's source.

 for instance, i created a patcher with a preset ("TheBP"), embedded as bp
it in another ("TheMain"). Fooled with the preset, saved TheMain, all fine.
Closed all, trashed TheBP, re-opened TheMain, no problem. Created a new
document saved as TheBP, kaboom... TheMain completely confused and broken
(with weird behavior such as the bpatcher outline not showing).

 it feels as though embedded bpatchers don't completely let go of their
ancestry, and some sort of  re-loading tries to happen (whereas my guess is
that embeddeds should be "set in stone" and not be "alive", since they are
integral to the parent). Someone else may be able to explain exactly what
goes on when saving a patcher that's been embedded as a bpatcher.

 Alex.

>From:    Stephen Kay 
>
>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 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?
>
>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.

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

Date:    Thu, 25 Feb 1999 21:37:45 +0000
From:    Trond Lossius 
Subject: grab causing infinite loops/stack overflow.

Thanks a lot, Stephen, for taking a look at the patch!

I ran into several other problems of the same kind in the time between
posting the question and receiving your answer, so I ended up mailing David
Z. as well. Apart from giving the same explanation as you, he added:

> ...Both of your problems are related to the same thing, which is
> that Max works unpredictably in feedback situations. You'll need
> to introduce a "pipe 0" somewhere in the calculations to break
> the feedback, and then everything will work fine. (....)
>
> There are so many of these "bugs" that it's best to get out of
> the habit of programming this way.

del 0 or pipe 0 solved the problem locally, but caused problems in the
mother patch that the example was extracted from. The subpatch was started
by a trigger object, and it turned out that del/pipe held back data until
all other outlets of the trigger was completed, even with a delay time of 0.

What I was trying to do was to make a loop that would be running until a
certain condition was met. However I just dicovered the "pause" message to
the Uzi object, which seems to be "a better habit". ;-)

Thanks once more!

Trond L.

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

Date:    Fri, 26 Feb 1999 09:29:17 +0100
From:    Ken Beesley 
Subject: perennial PowerGlove question

New subscriber question:  PowerGlove and MAX

I have a PowerGlove and MAX (an old version, but with
the 'glove' object), and I know that it is possible
to control the glove object with a PowerGlove via
an old Gold Brick interface (no longer available from the
apparently defunct Transfinite Systems).

Question:  1.  Does someone out there have a Gold Brick interface
                        to sell, or
           2.  Is there an alternative?  Will the PGSI work, for
                        example?  http://www.acm.uiuc.edu/sigarch/pgsi/

In short, what can one do right now to use the PowerGlove
as an external controller for MAX patches?  What does the latest
MAX documentation say about possibilities for Glove control?

I did search the MAX archives and found the same question,
but no answers.

Many thanks,

Ken

*********************************************************************
Kenneth R. Beesley              ken.beesley@xrce.xerox.com
Xerox Research Centre Europe    Tel from France:   04  76 61 50 64
6, chemin de Maupertuis         Tel from Abroad: 33 4  76 61 50 64
38240 MEYLAN                    Fax from France:   04  76 61 50 99
France                          Fax from Abroad: 33 4  76 61 50 99

XRCE:           http://www.xrce.xerox.com
Beesley:        http://www.xrce.xerox.com/people/beesley/beesley.html
Arabic:         http://www.xrce.xerox.com/research/mltt/arabic
*********************************************************************

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

Date:    Fri, 26 Feb 1999 13:16:03 +0200
From:    Tom Mays 
Subject: Re: groove~ development

>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~.

Here's my vote for "the Max concept of generalized objects is a
beautiful thing..."

this patcher repeats a list until a new list is received, and even finishes
the
current list before jumping to a new list.

        tm

max v2;
#N vpatcher 91 47 476 496;
#P user uslider 119 284 18 128 1001 1 0 0;
#P newex 121 113 44 196617 TogEdge;
#P message 140 32 221 196617 0 0 1000 1000 0 0 1000 1000 0 0 1000 1000;
#P message 83 188 248 196617 0 0 1000 1000 0 0 1000 1000 0 0 1000 1000;
#P newex 43 136 60 196617 prepend set;
#P toggle 138 88 15 0;
#P newex 145 142 27 196617 gate;
#P button 183 141 15 0;
#P message 12 33 113 196617 0 0 1000 1000 0 1000;
#P user number~ 75 258 114 273 9 3 3 2 0. 0. 0 0. 250 0.;
#P newex 90 213 30 196617 line~;
#P comment 155 84 35 196617 loop on;
#P connect 1 0 2 0;
#P connect 1 1 4 0;
#P connect 2 1 11 0;
#P connect 3 0 7 0;
#P connect 4 0 5 1;
#P connect 6 0 10 0;
#P connect 6 0 5 0;
#P connect 5 0 8 0;
#P connect 7 0 8 0;
#P connect 8 0 1 0;
#P connect 9 0 7 0;
#P connect 10 0 8 0;
#P pop;

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

Date:    Fri, 26 Feb 1999 12:42:20 +0000
From:    filip 
Subject: glitch-free play~

--------------90D639B4071E802683E533F4
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854";
x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

hi maxers,
i was working on a patch some month ago, where the main problem was this
thing to make a loop not-glitching. it was also important to change all
parameters of that loop on the fly AND i wanted to avoid having a
message-level in that machine since this is causing timing-problems in
extrem situaions.
i ended up using 2 play~ objects synchronized and crossfaded
but its a lot of cpu-eating stuff and still not "perfect"
this "play~-machine" is the heart of "lloopp" and maybe someone is
interested to have a look on it:

rhiz.org/patches

happy masping
klaus

--------------90D639B4071E802683E533F4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


hi maxers,

i was working on a patch some month ago, where the main problem was this thing to make a loop not-glitching. it was also important to change all parameters of that loop on the fly AND i wanted to avoid having a message-level in that machine since this is causing timing-problems in extrem situaions.
i ended up using 2 play~ objects synchronized and crossfaded
but its a lot of cpu-eating stuff and still not "perfect"
this "play~-machine" is the heart of "lloopp" and maybe someone is interested to have a look on it:

rhiz.org/patches

happy masping
klaus --------------90D639B4071E802683E533F4-- ------------------------------ Date: Fri, 26 Feb 1999 04:22:02 -0800 From: Christopher Dobrian Subject: looping with line~ and play~ Alex Stahl wrote: >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~. One could certainly do this with a "loop 1/0" message to line~, and I'm not saying such a flag might not be a cool addition to line~, but here are two points to consider: 1) Looping a list, or triggering a new list of line segments, is extremely easy to program already in Max because line~ sends a bang out its right outlet when it reaches its goal. (This is only accurate to the nearest vectorlength, not to the nearest sample, but it's pretty darn good for most situations.) Here's an example patch. (Note that the bang out of line~ could trigger a more compex list, or could even increment through a coll of lists, or whatever...) -----loopabufferinMSP----- max v2; #N vpatcher 40 55 301 272; #P comment 7 110 35 1310730 Audio On/Off; #P toggle 16 136 15 0; #P comment 45 25 155 1310730 Load a sound \, turn loop on \, and play; #P comment 103 44 60 1310730 Load a sound; #P message 71 43 32 1441802 read; #P newex 48 158 43 1441802 dac~ 1; #P newex 48 135 80 1441802 play~ asound; #P newex 71 62 134 1441802 buffer~ asound 1000 1; #P comment 166 109 35 1310730 Loop On/Off; #P button 48 58 15 0; #P newex 134 154 38 1441802 sel 1; #P toggle 151 113 15 0; #P newex 134 133 27 1441802 i; #P message 48 89 62 1441802 1000 1000; #P message 113 89 14 1441802 0; #P newex 48 112 96 1441802 line~; #P comment 42 44 25 1310730 Play; #P connect 7 0 3 0; #P fasten 6 0 3 0 139 175 204 175 204 85 53 85; #P fasten 2 0 1 0 118 108 53 108; #P connect 3 0 1 0; #P connect 1 0 10 0; #P connect 10 0 11 0; #P fasten 15 0 11 0 21 154 53 154; #P connect 12 0 9 0; #P fasten 6 0 2 0 139 175 204 175 204 85 118 85; #P fasten 7 0 2 0 53 85 118 85; #P connect 1 1 4 0; #P connect 4 0 6 0; #P connect 5 0 4 1; #P pop; -----endofpatch----- 2) As for the loop option in line~, the suggestion below is problematic. >[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. In many cases, line would still need an initial value from which to progress, in order to give the desired results. The above case works fine because it returns to the initial value. But what about [0, 1000 1000 0 1000 1000 1000]? If not told to go back to 0 somehow, it will spend one second staying at 1000 whenever it replays the list. Or, with [0, 1000 1000 0 1000 2000 1000], it will go from 2000 to 1000 for the first second of the replay. So the list in question would have to ensure that it ends at the desired starting point for the replay of the list. Thus, the built-in loop idea (if loop=1 then repeat the last trajectory or list of trajectories) is fine, but the results may or may not correspond to one's hopes/expectations, depending on what the list was. --Chris ---------- Christopher Dobrian / Department of Music / University of California, Irvine Phone: (949) 824-7288 / Fax: (949) 824-4914 / http://www.arts.uci.edu/dobrian ------------------------------ Date: Fri, 26 Feb 1999 12:09:55 -0000 From: Nick Rothwell Subject: Bpatchers, presets > 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 Alternatively: I've written a custom object which deals with this problem. It's rather like a coll but has the structure of a directory tree, which means that your bpatcher instances can be parameterised or nested using path names to their data. URL: http://www.cassiel.com/software/ The object is 680x0 only at present. -- Nick Rothwell, CASSIEL contemporary dance projects http://www.cassiel.com music synthesis and control You've read the rant, now buy the album: http://www.cassiel.com/listenmove/ ------------------------------ Date: Fri, 26 Feb 1999 12:27:21 -0500 From: Eric Singer Subject: Re: perennial PowerGlove question At 3:29 AM -0500 2/26/99, Ken Beesley wrote: >New subscriber question: PowerGlove and MAX > >I have a PowerGlove and MAX (an old version, but with >the 'glove' object), and I know that it is possible >to control the glove object with a PowerGlove via >an old Gold Brick interface (no longer available from the >apparently defunct Transfinite Systems). > >Question: 1. Does someone out there have a Gold Brick interface > to sell, or Before anyone asks again, no, I don't have any more, nor do I know of anyone who does. Someone on the list recently got in touch with Donald Eastlake of Transfinite, but I don't know what the result was. It might be possible to get the schematic or PCB plot from him, so someone else could produce them. Eric ------------------------------ Date: Fri, 26 Feb 1999 10:14:27 -0800 From: Alex Stahl Subject: Re: looping with line~ and play~ A couple people kindly pointed out that line~ sends a bang when it finishes, and that you can use this bang to resend a message into the line~, thus achieving the looping behavior I am seeking. My understanding is that this method would involve the Max millisecond scheduler, so this approach is not necessarily even accurate to the vector unless "Scheduler in Audio Interrupt" is on. Also, my hunch was that groove~ may be looping on vector boundaries; just a guess, at least that is one explanation for some of the problems I've had with it. In any case, this was the first approach I tried, and I hear more clicks than I do when I take pains to count samples. I also get other problems, since I'm doing a lot of what used to be called sound-on-sound-- another thing you could do extremely easily with tapin/tapout, but if you do that you lose random access to the delay line, so I'm using buffers. After a few thousand regenerations, errors of a measely vectorsize can add up. Oh well, it figures that one the first things I try with msp is not "most situations" and really seems to demand sample accuracy. >2) As for the loop option in line~, the suggestion below is problematic. > >>[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. > >In many cases, line would still need an initial value from which to >progress, in order to give the desired results. The above case works fine >because it returns to the initial value. But what about [0, 1000 1000 0 >1000 1000 1000]? If not told to go back to 0 somehow, it will spend one >second staying at 1000 whenever it replays the list. Or, with [0, 1000 1000 >0 1000 2000 1000], it will go from 2000 to 1000 for the first second of the >replay. So the list in question would have to ensure that it ends at the >desired starting point for the replay of the list. Certainly, the list would need to specify a line that ends where it started for normal looping, but that's not hard to do. A sample you wish to use as an oscillator waveform should generally end where it starts, too. -Alex Stahl ------------------------------ Date: Fri, 26 Feb 1999 14:19:19 -0500 From: Robin Davies Subject: groove~, play~, wave~ Hi: With all this discussion about updating groove... I made a "super-looper" of sorts using phasor~ and wave~ objects. Seems to work pretty well. The fundamental patch looks like this: (Sorry, it uses one of those nasty preset objects...) max v2; #N vpatcher 214 168 637 495; #P message 215 213 35 13762569 \$1 20; #P newex 215 191 55 13762569 * 0.00787; #P newex 215 233 30 13762569 line~; #P newex 145 252 27 13762569 *~; #N vpreset 6; #X append 1 1 9 124 145 number float 0.44 \;; #X append 2 1 9 124 145 number float 0.74 \;; #X append 4 1 9 124 145 number float 0. \;; #X append 5 1 9 124 145 number float -0.44 \;; #X append 6 1 9 124 145 number float -0.74 \;; #P preset 145 88 47 27; #P user meter~ 121 204 134 262 100; #P flonum 145 124 35 9 0 0 0 210; #P user uslider 215 119 25 51 128 1 0 0; #P newex 145 170 60 13762569 wave~ fred; #P message 42 152 41 13762569 replace; #P newex 42 171 91 13762569 buffer~ fred 1000; #P newex 145 144 44 13762569 phasor~; #P toggle 123 282 15 0; #P newex 145 281 29 13762569 dac~; #P comment 33 35 356 13762569 1. Place your favourite loop in the buffer. 2. Try some presets to loop forwards and backwards (negative frequencies) 3. Multiple wave~ objects can follow the same phasor~ to sync up loops.; #P comment 242 119 64 13762569 main volume; #P connect 15 0 13 0; #P connect 14 0 15 0; #P connect 13 0 12 1; #P connect 12 0 2 0; #P connect 12 0 2 1; #P connect 11 0 9 0; #P connect 9 0 4 0; #P connect 8 0 14 0; #P connect 7 0 10 0; #P connect 7 0 12 0; #P connect 6 0 5 0; #P connect 4 0 7 0; #P connect 3 0 2 0; #P pop; ------------------- Hope that helps. Robin Davies Music Technology McGill University ------------------------------ End of MAX Digest - 25 Feb 1999 to 26 Feb 1999 (#1999-66) *********************************************************