Subject: MAX Digest - 21 Aug 1999 to 22 Aug 1999 (#1999-251)
Date: Mon, 23 Aug 1999 00:00:03 -0400
From:
Automatic digest processor <LISTSERV@LISTS.MCGILL.CA>
Reply-To: MAX - Interactive Music/Multimedia Standard Environments <MAX@LISTS.MCGILL.CA>
To: Recipients of MAX digests <MAX@LISTS.MCGILL.CA>


There are 9 messages totalling 470 lines in this issue.

Topics of the day:

  1. CPU and pcontrol problems
  2. SoftStep - somewhat off-topic
  3. MIDI / msp timing problem
  4. groove~ bug?
  5. more timing... (2)
  6. USB midi/Max and movie
  7. timing test 3
  8. max/msp on the new powerbook G3's

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

Date:Sat, 21 Aug 1999 14:27:20 +0100
From:Hans Tutschku <Hans.Tutschku@IRCAM.FR>
Subject: CPU and pcontrol problems

>According to manuals:

>-- Pcontrol/enable: ...enables the Midi objects...
>-- Mute~: ...turns off the signal processing in all...

>And for me mute~ works.
>johan

If I'm not wrong, "mute" is just disabling processing for signal objects on
the highest level of an
muted abstraction. This means, if inside the muted abstraction there are
other subpatchers containing
signal objects, their processing is not stopped. This could explain, why by
muting a havy patcher,
CPU is not going considerably down - the processing happens probably in
subpatchers inside the muted one.

I realized one year ago a quite huge sound-installation with 13 "modules".
Every module was taking between 50% and 80% of the CPU on a G3/266. No way
to have them running simultanuously.
I used pcontrol, which is not only disabling MIDI, but also Audio. Worked
fine for my.

But you have to organize the switching in two levels:

Toggel with fadein- fadeout-business for the levels of the muted abstraction
muting after a delay (depending on the fade-time)
unmuting should happen before fading in

This fade stuff can't be inside the muted abstraction of course.

Hope, this helps a bit. Hans


---------------------------
Hans Tutschku


http://www.multimania.com/hanstutschku

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

Date:Sun, 22 Aug 1999 03:22:53 -0700
From:Charles Lyons <charleslyons@EARTHLINK.NET>
Subject: SoftStep - somewhat off-topic

Not really about Max, but potentially of interest to Maxheads:

Algorithmic Arts has a new program called SoftStep that resembles Max in
concept (linked "objects" with specific functions processing MIDI data) but
seems to operate at a slightly higher (ie, less abstract) level, which may
make it unappealing to some of the more extreme innovators here. In
particular it's focused on creating modular sequence generators; I haven't
figured out yet how well it handles other types of MIDI processing. There's
a fairly well-done html manual online at www.geneticmusic.com, along with a
demo version. It's Windows only, I'm afraid.

Anyone else looked at this?

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

Date:Sun, 22 Aug 1999 12:59:15 +0200
From:Robert Henke <imbalance@SNAFU.DE>
Subject: MIDI / msp timing problem

Hi Jeff,
i tried your patcher on my G3/266 Wallstreet pb and i had values from 4995 up
to 5010.
this is independent of the processor usage. i tried it without any msp patch
and with a 60% cpu load patch and i saw no siginficant difference.

Wow, that makes me kind of unhappy. i really hope that some day timing is
going to be stable . cubase and logic are stable. why is this impossible for
max ?. it may need a total rewriting of the codebut at least i would pay
lots of money for a professional solution.
( I would also buy the "hardmax/msp" machine !!! )

btw.: why does this patch jump in steps of 5 ms ? ( scheduler in audio
interrupt and block size 1.45ms )

rob.


Jeffrey Burns wrote:
>
> >With regards to this discussion of Max timing, I remember a
> >long time ago there was a discussion of why 1 ms was not
> >1 ms in Max, and why 120 bpm was not 120 bpm in Max. Can
> >anyone remember/dredge up this information?
>
> I don't remember where it is, but here's a patch I wrote at the time, which
> shows how much Max timing on your individual machine differs from the same
> on other machines. Just open it and look at the values it displays for a
> minute. If Max gave you perfectly absolute timing, it would always show a
> value of 5000. On my old PPC 7200 it varied from 5020 to 5025, and on my G3
> it varies from 5140 to 5145.
>
> Jeff Burns
>
> max v2;
> #N vpatcher 371 74 566 174;
> #P hidden newex -36 -194 50 196617 loadbang;
> #P hidden newex 38 -23 50 196617 select 0;
> #P hidden newex 38 -47 74 196617 counter 0 4;
> #P number 38 26 113 36 0 0 164 3;


> #P hidden newex -36 -171 40 196617 metro;
> #P hidden newex 38 -72 40 196617 change;
> #P hidden message -36 -144 50 196617 time;
> #P hidden newex -36 -121 50 196617 date;
> #P hidden newex -16 -96 65 196617 unpack 0 0 0;
> #P hidden newex 38 1 39 196617 timer;
> #P hidden connect 8 0 0 0;
> #P hidden connect 8 0 0 1;
> #P hidden connect 9 0 5 0;
> #P hidden connect 0 0 6 0;
> #P hidden connect 3 0 2 0;
> #P hidden connect 5 0 3 0;
> #P hidden connect 4 0 7 0;
> #P hidden connect 2 1 1 0;
> #P hidden connect 1 2 4 0;
> #P hidden connect 7 0 8 0;
> #P pop;
>
> http://www.snafu.de/~jeff

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

Date:Sun, 22 Aug 1999 13:58:23 +0200
From:Gilbert Nouno <gilbert.nouno@FREE.FR>
Subject: Re: groove~ bug?

I must admitI often don't read documentation !

So, according to MSP documentation, you're right !

I've just notice that the sync signal can go beyond 1. if you load
another sound in the buffer~while groove~is playing,
in that case, you have to do a stop/start dac~ in order sync output to be OK.

But it don't bother me to work with it that way, I even
find it'seasier to loop samples in MSP than withhardware samplers .

Gilbert


>Your explanation is ingenious, Gilbert, but I _do_ think you're wrong.
>
>I think the bottom line is that groove~ should function the same way
>whether the looppoints are specified by floats or by signals. And the MSP
>documentation states:
>
>"signal
>
In middle inlet:Sets the starting point of the loop in milliseconds.
>
In right inlet :Sets the end point of the loop in milliseconds."
>
>"int or float
>
In middle inlet:Sets the starting point of the loop in milliseconds.
>
In right inlet :Sets the end point of the loop in milliseconds."
>
>"signal
>
Out right outlet:Sync output. During the loop portion of the sample,
>
this outlet outputs a signal that goes from 0 when the loop starts
>to 1
>
when the loop ends."
>
>If you specify the loop points with floats, everything functions as
>described here. But if you do so with signals, you get the other behavior
>(clever for you, unuseable for me) we've been discussing.
>
>Ben

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


Date:Sun, 22 Aug 1999 14:49:21 +0200
From:Robert Henke <imbalance@SNAFU.DE>
Subject: more timing...

Hi Max-l !

After thinking a while about Jeffrey Burns Patcher for messuring timing in MAX
i came up with a new solution which should providemore reliable results.
my results are these : on my powerbook g3/26610 seconds in max ( via metro )
are around 0.1 - 0.3 percent longer as 10 seconds from the powerbook internal
clock. the timing varies within a range of0.2 percent between two 10 second
intervals .
( it is not possible to get shorter messuring intervals without loosing
precission )
this is true if scheduler is in audio interrupt.
without marking this option i got a max 10 second interval which was 1.6
percent shorter then realtime. the derivation withi two intervals is kind of
up to 0.7 percent .

anyway, these resultsay nothing about timing MIDI versus MSP, they only
answer the question "how long are 10 seconds in max ? "

rob.


max v2;
#N vpatcher 330 74 787 286;
#P newex -24 -327 45 196617 loadbang;
#P user multiSlider 16 69 396 78 -2. 2. 1 3449 15;
#P newex 16 -27 35 196617 - 100.;
#P comment 333 -2 100 196617 > 0 means max is slower than realtime ( 10
seconds via metro take longer then they should );
#P flonum 16 6 129 36 0 0 0 3;
#P newex 16 -55 27 196617 / 6.;
#P newex 16 -85 27 196617 -;
#P newex -24 -231 67 196617 b 2;
#P newex 33 -115 27 196617 i;
#P toggle -24 -302 15 0;
#P newex -24 -268 68 196617 metro 10000;
#P message -24 -195 30 196617 ticks;
#P newex -24 -161 50 196617 date;
#P comment 68 -113 173 196617 subtracting new value from old value -->
difference in ticks between two bangs;
#P comment 210 15 100 196617 0. means max time = realtime;
#P comment 52 -255 100 196617 bang every 10 seconds;
#P comment -66 -348 323 196617 compare 10 seconds from internal computer clock
with max clock;
#P comment 150 5 51 196644 %;
#P comment 14 156 428 196617 watch timing over a period of time ( try this
with other cpu intensive patchers running !!! try this with scheduler in audio
interrupt ON / OFF !!! );
#P comment 148 55 123 196617 UPDATE EVERY 10 SECS.;
#P connect 14 0 17 0;
#P connect 12 0 8 0;
#P connect 12 1 11 0;
#P connect 9 0 12 0;
#P connect 8 0 7 0;
#P connect 7 2 13 0;
#P connect 7 2 11 1;
#P connect 11 0 13 1;
#P connect 10 0 9 0;
#P connect 17 0 15 0;
#P connect 19 0 10 0;
#P connect 13 0 14 0;
#P connect 15 0 18 0;


#P pop;


David Zicarelli wrote:
>
> jvkr <jvkr@KONCON.NL> writes:
>
> >According to manuals:
> >
> >-- Pcontrol/enable: ...enables the Midi objects...
> >-- Mute~: ...turns off the signal processing in all...
> >
> >And for me mute~ works.
>
> Richard Dudas pointed out to me recently that mute~ does not
> mute DSP objects in subpatchers of the patcher you're muting.
> For this you would want to send the enable 0 1 message to
> pcontrol and to reenable, enable 1 1. The second 1 argument to
> the enable message denotes a "deep" enable/disable that
> reaches all MIDI and DSP objects in all subpatchers of the patch
> you are enabling/disabling.
>
> enable 0, without the additional argument, merely disables
> MIDI and DSP objects in the immediate subpatcher. mute~ does
> this too, and only this. It will need to be changed.
>
> David Z.

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

Date:Sun, 22 Aug 1999 17:51:43 +0200
From:muki pakesch <mpakesch@T0.OR.AT>
Subject: Re: USB midi/Max and movie

At 0:00 -0400 22.08.1999, Peter Nyboer <pnyboer@SIRIUS.COM> wrote:
>One problem I encountered was that Movieplayer (and, subsequently, movie)
>.....
>movies on VHS, so there were probably radical changes in the noise patterns
>as well.

yes, that's because vhs is extremely noisy and therefore
hard to compress which, for the chosen codec, will result
in less compression and higher transfer rates

also, where did you render the transitions?

with some codecs it is possible to limit the datarate
if you don't the transitions will be rendered at a much
higher datarate resulting in choppy playback in MP

suggestion:
analyze what's your best transferrate your system can handle
and in your editing application (premiere or ediDV) set the codec
to be limited to that datarate

another thought:
since i suppose you're working in DV, it might also be possible
that you accidentally might have mixed codecs
for example your source material is in AppleDV codec whereas the transitions
are in EditDV codec
mixed codecs within one move will also result in choppy playback

cheers,
muki
__________________________________________________________________
| muki pakesch|
||


| mailto:mpakesch@t0.or.athttp://www.t0.or.at/~mpakesch|
|__________________________________________________________________|

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

Date:Sun, 22 Aug 1999 17:38:59 +0200
From:Robert Henke <imbalance@SNAFU.DE>
Subject: timing test 3

Hi Max-l !

I found a patch for visualizing the timing in a smal time scale.
I use the phase shift between two msp oscillators.
Max timing comes form a delay object which should delay a sync bang exactly
360 degrees. The most exiting thing i figured out is that the delay even in a
smal scale is STATIC if no other max process is running ! But a simple metro
which is not connected to anything leads to unpredicable results.....
this is true for scheduler in audio interrupt. if it is not checked than there
is no significant differnce between the presence of some other processes or not.

Rob.


max v2;
#N vpatcher 39 155 771 670;
#P comment 297 37 100 196617 2. press button to sync both oscillators with 1
cycle (360 degrees ) phaseshift;
#P comment 535 331 100 196617 result of 3. : unpredictable phase shift ......
wow !;
#P comment 424 330 100 196617 result of 2. : some phase shift due to the fact
that 100 ms in max are not really 100 ms . phase shift is constant as long as :;
#P button 433 72 15 0;
#P toggle 409 72 15 0;
#P newex 409 171 50 196617 metro 50;
#P button 301 89 15 0;
#P newex 301 118 27 196617 b 2;
#P newex 249 120 27 196617 b 2;
#P newex 79 91 45 196617 loadbang;
#P toggle 79 114 15 0;
#P button 171 46 15 0;
#P newex 231 254 38 196617 cycle~;
#P newex 159 253 38 196617 cycle~;
#P newex 318 142 53 196617 delay 100;
#P newex 79 136 29 196617 dac~;
#P user scope~ 159 327 289 457 256 3 128 -1. 1. 0 0. 0 0.;
#P message 308 179 14 196617 0;
#P message 236 179 14 196617 0;
#P newex 159 293 82 196617 -~;
#P newex 259 215 59 196617 phasor~ 10;
#P newex 187 215 59 196617 phasor~ 10;
#P comment 451 56 100 196617 3. turn on any process which needs the max
scheduler e.g a simple metro object and repeat step 2 a few times;
#P comment 190 38 100 196617 1. press button to sync both oscillators;
#P comment 38 39 100 196617 do all thesew things a few times :;
#P comment 19 115 56 196617 start msp;
#P comment 318 330 100 196617 result of 1. : no phase shift --> result of
subtraction = flat line;
#P connect 5 0 13 1;
#P connect 6 0 14 1;
#P connect 13 0 7 0;
#P connect 7 0 10 0;
#P connect 8 0 5 1;
#P connect 9 0 6 1;


#P connect 19 0 8 0;
#P connect 19 1 12 0;
#P connect 12 0 9 0;
#P connect 14 0 7 1;
#P connect 22 0 21 0;
#P connect 18 0 8 0;
#P connect 17 0 16 0;
#P connect 18 1 9 0;
#P connect 16 0 11 0;
#P connect 15 0 18 0;
#P connect 20 0 19 0;
#P fasten 23 0 19 0 438 114 306 114;
#P pop;

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

Date:Sun, 22 Aug 1999 10:23:49 -0600
From:Kevin Walker <kevin@SUWA.ORG>
Subject: Re: more timing...

>Hi Max-l !
>
>After thinking a while about Jeffrey Burns Patcher for messuring timing in MAX
>i came up with a new solution which should provide
more reliable results.
>my results are these : on my powerbook g3/266
10 seconds in max ( via metro )
>are around 0.1 - 0.3 percent longer as 10 seconds from the powerbook internal
>clock. the timing varies within a range of
0.2 percent between two 10 second
>intervals .
>( it is not possible to get shorter messuring intervals without loosing
>precission )
>this is true if scheduler is in audio interrupt.
>without marking this option i got a max 10 second interval which was 1.6
>percent shorter then realtime. the derivation withi two intervals is kind of
>up to 0.7 percent .
>
>anyway, these result
say nothing about timing MIDI versus MSP, they only
>answer the question "how long are 10 seconds in max ? "
>
>rob.

Another data point:Using two different methods to measure timing
drift, I find that Max's milliseconds are about 1.7% too fast.
(Desktop G3 266, MacOS 8.6, overdrive, _not_ scheduler in audio
interrupt, Max 3.5.9.)

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

Date:Sun, 22 Aug 1999 22:20:18 -0400
From:Alexander Hickox <arh22@COLUMBIA.EDU>
Subject: max/msp on the new powerbook G3's

>
>
> i have someone who wants to buy my older powerbook, which means that i'm looking
> at getting a G3/400 PB as soon as i can get the rest of the money together.
> the question is - is anybody using one of these
with max & msp yet? is there a
> midi interface that you can recommend? and is the audio quality any better than
> earlier models?
> and basically - does it work?????
>
>

I think it does. I recently bumped into D. Zicarelli in San Francisco and he was
using a translucent keyboard powerbook. I don't know if the sound is better.

Alex Hickox


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

End of MAX Digest - 21 Aug 1999 to 22 Aug 1999 (#1999-251)
**********************************************************