Forums > MaxMSP

issues with MSP timing

October 2, 2006 | 11:10 pm

Hi, I have been busy at work trying to make a phasor~ sync up with midi real time clock info (24 ticks per beat). I’ve gotten a pretty decent patch that continually checks the value of the phasor and either speeds it up or slows it down based on where it should be. Ok. cool.

But, in the course of doing all of that, I have noticed that something is very wrong…what that something is? Hopefully someone out there can help me.

Basically, I have noticed that my MSP is not right. For example, I set a phasor~ to 2 Hz and have it play a sample. At the same time, I use a metro set at 500ms to trigger another sample. I start them at the same time so they are perfectlly sync’d. However, after only 20 beats or so, they are completely out of phase. Now, I cannot believe that the timing is so bad that it would do this in normal operations. The patch that I wrote is "holding" the phasor to a frequency of around 1.9Hz when it should be at 2hz, now that is definately wrong.

Furthermore, I’ve also noticed other things are wrong. Unfortunately, I can’t find the patch that did this, but awhile back I noticed that when i did certain operations on signals, ie. attempt to multiply them, i was getting wrong answers.

Can anyone tell me why my computer might be doing this? Do i have some setting wrong? My i/o vector and signal vector sizes are 512, i’ve tried it in overdrive and with interrupt both on and off. I don’t know what else it could be, any ideas? Please help, this is really frusterating! thanks and hope to hear from all of you

matt


October 6, 2006 | 8:23 pm

Matthew Wilkens wrote:
> Basically, I have noticed that my MSP is not right. For example, I
> set a phasor~ to 2 Hz and have it play a sample. At the same time, I
> use a metro set at 500ms to trigger another sample. I start them at
> the same time so they are perfectlly sync’d. However, after only 20
> beats or so, they are completely out of phase.

It’s not MSP which is wrong, its Max! This has been around since ever.
You might get better results if you switch on "Scheduler in Audio
Interrupt" But in general in a "seperated scheduler worlds" approach,
you have to sync as you would do in analog/digital hardware components.
It’s a different way of thinking times, versus triggering of events.

This should be actually mentioned in 48 point size within the metro help
file: DO NOT EXPECT TO HAVE EXACT TIMING IF YOU LET THIS RUN FREELY.

And if you do not let run it freely, you just don’t need metro ;-)

Search the archives for different approaches to sync bangs to audio.
Look into edge~ and >~ 0.5 to get bangs perfectly synced to your phasor~….

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 6, 2006 | 9:24 pm

> Can anyone tell me why my computer might be doing this? Do i have some setting wrong? My i/o vector and signal vector sizes are 512, i’ve tried it in overdrive and with interrupt both on and off. I don’t know what else it could be, any ideas? Please help, this is really frusterating! thanks and hope to hear from all of you
>
> matt
—————————————————-

sorry Matt , catching up on this thread a little late , so i dont know if you figured everything out.
as Stephan mentionned doing evertything in MSP will b the safest way to go.
here are a few examples among stephan’s solution, the question remains open on which one of these is the best . and has been widely discussed on previuous threads .
good luck

#P user scope~ 428 228 537 286 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P user scope~ 943 226 1052 284 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P user scope~ 684 231 793 289 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P window setfont "Sans Serif" 9.;
#P flonum 855 268 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 855 245 35 196617 timer;
#P flonum 596 273 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 596 250 35 196617 timer;
#P number 830 336 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 830 312 77 196617 counter 0 1 16;
#P number 581 336 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 581 312 77 196617 counter 0 1 16;
#P newex 830 166 43 196617 change~;
#P newex 830 216 33 196617 edge~;
#P newex 830 191 45 196617 ==~ -1.;
#P newex 581 190 28 196617 < ~ 0;
#P newex 580 167 35 196617 delta~;
#P newex 581 209 34 196617 edge~;
#P flonum 110 269 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 110 246 35 196617 timer;
#P message 91 92 14 196617 0;
#P newex 72 119 31 196617 dac~;
#P newex 50 90 32 196617 t 1 1;
#P newex 50 63 48 196617 loadbang;
#P newex 196 183 58 196617 metro 500;
#P number 196 337 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 196 313 77 196617 counter 0 1 16;
#P number 286 337 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 286 313 77 196617 counter 0 1 16;
#P button 286 272 15 0;
#P flonum 339 270 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 339 247 35 196617 timer;
#P newex 339 180 39 196617 >~ 0.5;
#P user scope~ 371 75 480 133 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P newex 339 200 36 196617 edge~;
#P newex 340 45 58 196617 phasor~ 2.;
#P window linecount 2;
#P comment 233 358 100 196617 counts get out of sync pretty quickly;
#P comment 503 375 358 196617 a few different approaches : i can not tell which one would be the most reliable… :);
#P window linecount 3;
#P comment 106 45 100 196617 doubleclick on loadbang to start audio;
#P connect 18 0 17 0;
#P connect 7 0 8 0;
#P connect 9 0 10 0;
#P connect 10 0 11 0;
#P connect 4 0 7 1;
#P connect 4 0 7 0;
#P connect 4 0 9 0;
#P connect 12 0 13 0;
#P connect 15 0 16 0;
#P connect 16 1 17 0;
#P fasten 16 0 14 0 55 155 176 155 201 155;
#P connect 19 0 20 0;
#P connect 14 0 12 0;
#P connect 14 0 19 1;
#P connect 14 0 19 0;
#P connect 23 0 21 0;
#P connect 27 0 28 0;
#P connect 29 0 30 0;
#P connect 31 0 32 0;
#P connect 33 0 34 0;
#P connect 6 0 37 0;
#P connect 6 0 4 0;
#P connect 26 0 24 0;
#P fasten 3 0 26 0 345 142 835 142;
#P fasten 3 0 22 0 345 141 585 141;
#P connect 3 0 5 0;
#P connect 3 0 6 0;
#P connect 21 0 31 1;
#P connect 21 0 31 0;
#P connect 21 0 27 0;
#P connect 22 0 35 0;
#P connect 22 0 23 0;
#P connect 24 0 36 0;
#P connect 24 0 25 0;
#P connect 25 0 33 1;
#P connect 25 0 33 0;
#P connect 25 0 29 0;
#P window clipboard copycount 38;


October 6, 2006 | 10:05 pm

thanks for the feedback guys, unfortunately the reason I am trying to sync a phasor~ with bangs is because I want to sync it with an incoming midi time clock…which are basically bangs. Most people will immediately say why not use your computer as the master clock and sync your midi devices from that, well, the midi device I am using is Red Sounds SoundBite Micro, which takes an audio signal in and sends synchronized midi clock out. The whole point is so you can sync other devices up to an audio signal. The beat counting engine from red sound is really good.

Anyways, thanks for the feedback and I’ll keep plugging away


October 7, 2006 | 10:39 am

And it’s interesting to compare phasor with train …

David

max v2;
#N vpatcher 100 100 1235 734;
#P toggle 75 49 34 0;
#P window setfont "Sans Serif" 9.;
#P flonum 743 103 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 743 80 35 196617 timer;
#P window setfont "Sans Serif" 10.;
#P newex 272 182 52 196618 delay 20;
#P button 272 155 15 0;
#P user multiSlider 525 432 87 106 0. 16. 5 2665 15 0 0 2 1 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 50 160 6;
#M rgb5 0 11 166;
#M rgb6 232 0 158;
#M rgb7 248 139 0;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P newex 524 402 77 196618 pak 0 0 0 0 0;
#P toggle 272 47 36 0;
#P newex 309 45 27 196618 + 1;
#P newex 351 21 63 196618 phasor~ 2.;
#P window setfont "Sans Serif" 9.;
#P number 373 337 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 920 313 77 196617 counter 0 1 16;
#P user scope~ 593 78 702 136 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P window setfont "Sans Serif" 10.;
#P newex 593 21 69 196618 train~ 500.;
#P message 272 215 15 196618 0;
#P user scope~ 428 228 537 286 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P user scope~ 943 226 1052 284 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P user scope~ 684 231 793 289 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P window setfont "Sans Serif" 9.;
#P flonum 855 268 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 855 245 35 196617 timer;
#P flonum 596 273 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 596 250 35 196617 timer;
#P number 274 359 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 830 313 77 196617 counter 0 1 16;
#P number 188 358 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 581 313 77 196617 counter 0 1 16;
#P newex 830 166 43 196617 change~;
#P newex 830 216 33 196617 edge~;
#P newex 830 191 45 196617 ==~ -1.;
#P newex 581 190 28 196617 < ~ 0;
#P newex 580 167 35 196617 delta~;
#P newex 581 209 34 196617 edge~;
#P flonum 110 269 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 110 246 35 196617 timer;
#P newex 222 146 31 196617 dac~;
#P newex 196 183 58 196617 metro 500;
#P number 196 337 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 196 313 77 196617 counter 0 1 16;
#P number 286 337 80 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 0 1 16;
#X flags 0 0;
#P newobj 286 313 77 196617 counter 0 1 16;
#P button 286 272 15 0;
#P flonum 339 270 83 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 339 247 35 196617 timer;
#P newex 339 180 39 196617 >~ 0.5;
#P user scope~ 376 74 485 132 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P newex 339 200 36 196617 edge~;
#P window setfont "Sans Serif" 10.;
#P newex 340 45 76 196618 selector~ 2 1;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 254 385 100 196617 counts get out of sync pretty quickly;
#P comment 441 554 358 196617 a few different approaches : i can not
tell which one would be the most reliable… :);
#P window setfont "Sans Serif" 10.;
#P window linecount 1;
#P comment 90 89 100 196618 on/off;
#P comment 200 58 100 196618 phasor/train;
#P connect 15 0 17 0;
#P connect 17 0 18 0;
#P connect 15 0 17 1;
#P fasten 25 0 26 0 586 333 193 333;
#P fasten 50 0 15 0 80 173 201 173;
#P connect 15 0 13 0;
#P connect 13 0 14 0;
#P fasten 50 0 16 0 80 129 227 129;
#P fasten 36 0 13 2 277 295 233 295;
#P fasten 50 0 46 0 80 115 277 115;
#P connect 43 0 46 0;
#P connect 46 0 47 0;
#P connect 47 0 36 0;
#P fasten 27 0 28 0 835 333 279 333;
#P connect 5 0 10 0;
#P connect 10 0 11 0;
#P connect 11 0 12 0;
#P connect 43 0 42 0;
#P fasten 36 0 11 2 277 295 323 295;
#P connect 4 0 7 0;
#P connect 7 0 5 0;
#P connect 5 0 8 0;
#P connect 8 0 9 0;
#P connect 42 0 4 0;
#P connect 5 0 8 1;
#P fasten 41 0 4 1 356 42 378 42;
#P fasten 39 0 40 0 925 333 378 333;
#P connect 4 0 6 0;
#P fasten 37 0 4 2 598 42 411 42;
#P connect 7 0 35 0;
#P fasten 13 0 44 0 201 384 529 384;
#P connect 44 0 45 0;
#P fasten 11 0 44 1 291 384 545 384;
#P fasten 25 0 44 2 586 366 561 366;
#P fasten 27 0 44 3 835 366 577 366;
#P fasten 4 0 20 0 345 141 585 141;
#P connect 20 0 21 0;
#P connect 21 0 19 0;
#P connect 19 0 25 0;
#P fasten 39 0 44 4 925 366 593 366;
#P connect 37 0 38 0;
#P connect 19 0 29 0;
#P connect 29 0 30 0;
#P fasten 36 0 25 2 277 295 618 295;
#P connect 19 0 29 1;
#P connect 20 0 33 0;
#P connect 37 1 48 0;
#P connect 48 0 49 0;
#P connect 37 1 48 1;
#P fasten 4 0 24 0 345 142 835 142;
#P connect 24 0 22 0;
#P connect 22 0 23 0;
#P connect 23 0 27 0;
#P connect 23 0 31 0;
#P connect 31 0 32 0;
#P fasten 36 0 27 2 277 295 867 295;
#P connect 23 0 31 1;
#P fasten 37 1 39 0 657 67 1092 67 1092 302 925 302;
#P connect 22 0 34 0;
#P fasten 36 0 39 2 277 295 957 295;
#P pop;


October 7, 2006 | 12:33 pm

i just use audio for all timing. sample tight sounds better to me.
or you could use reaktor, which calculates the non audio path at signal rate so i hear…
other than that, rewire gives me best inter app communication


October 8, 2006 | 10:51 pm

Quote: david stevens wrote on Sat, 07 October 2006 03:39
—————————————————-
> And it’s interesting to compare phasor with train …
>
> David
>

More like depressing….


October 9, 2006 | 11:20 pm

I posted 2 topics about problems with metro and tempo. I have seen at least 4 others in the past couple months. Why is such an essential object/series of objects flawed? I don’t know of any other software including poor quality ones that go out of sync like this…

They should just completely recode it or rework the event scheduler somehow.


October 10, 2006 | 6:25 am

Hi Nicholas,

maybe you should think less of MaxMSP in terms of being a piece of
software than a programming language? If tempo/metro were to stay synced
to audio it would have to be implemented in a similar way to control
rate in Csound. That might put severe limitations on how much you could
expect to do following one bang without getting audio stutter due to
severe CPU spikes. Some of us might be quite dependent on the ability to
have the metro running in a different scheduler to audio.

Several examples have been posted illustrating how to run an audio rate
metro. If you want to use tempo/metro synced to audio, you are free to
do so. If you spend a day making wrappers (abstraction) for setclock,
metro, tempo, line, etc. you could easily set up setclock to be driven
by audio, and then link all of your timed objects to that clock. Max
provides you with a much higher degree of freedom than most audio/media
software, but sometimes that comes at the expense of having to do a
little extra work to tweak things to behave according to *your* needs
and preferences.

Best,
Trond

Nicholas C. Raftis III wrote:
> I posted 2 topics about problems with metro and tempo. I have seen at least 4 others in the past couple months. Why is such an essential object/series of objects flawed? I don’t know of any other software including poor quality ones that go out of sync like this…
>
> They should just completely recode it or rework the event scheduler somehow.
>


October 10, 2006 | 1:04 pm

Is ‘Scheduler in Audio Interrupt’ analogous to Reaktor or the Nord Modulars’ ‘audio-rate’ control rates? If so, would it be useful to allow one of several divisions of that rate to conserve cycles, if desired?


October 10, 2006 | 4:38 pm

Matthew Wilkens wrote:
> unfortunately the reason I am trying to sync a phasor~ with bangs is
> because I want to sync it with an incoming midi time clock…

In this case you have to create an MSP signal out of your bangs.
Same issue, just the other way around. But it needs to be synced…
Look at sync~, whic is exactly made for that. The help file explains all…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 10, 2006 | 5:31 pm

Trond, I tried those objects you mentioned, abstractions of audio rate tempo clock.. it crashes within minutes of running in my rather large sequencer patch. The regular metro runs fine but if I want to put the file I made into logic and sequence some stuff over it its a nightmare because its slightly off tempo. And for live shows, who knows if the tempo will stop in mid rocking out.

Im not just thinking of myself this is a problem for many people, thats what I was pointing out. And yeah its great to have freedom, thats why I use max/msp.. but at what cost? Im a clean programmer and I know all these problems aren’t in my patches, and Its really disappointing because everything else works so well…


October 10, 2006 | 5:32 pm

Hi matt,

Is it correct that what you are trying to do is illustated in the patch below? I think it’s true that you can’t use metro this way. It is not meant to be used this way.

The threading system as I came to understand it:

Low-priority events, such as mouse-clicks from a user, are put at the end of the low priority queue and will be executed whenever the events before it have been executed first. This doesn’t guarantee any exact timing. When too much events are in the queue, objects such as qmetro stop adding new events until there is room, resulting, for example, in a lower framerate.

Metro works on the scheduler system, which means there is no exact timing, only an ‘as close as possible’ timing. Every time the scheduler is ‘served’, it is allowed to execute its pending events. These servings don’t occur on an exact time but on a specified interval. This interval is perfectly short enough (2 ms default), for processing ‘realtime’ events, but definitly not short enough to compare to sample-accurate timing.

When you put max in overdrive, the scheduler interrupts the execution of events in the low priority queue even if the latter hasn’t finished processing all pending events. This matters only when your patch does ‘as much as possible’-kind-of tasks, such as banging a movie with a qmetro (see above).

The dsp (MSP) thread processes 44100 samples every second, which one can rely on to be timed right. Of course for it to know when to process what (for example when to start adding the values of a sample buffer to the output), it relies on events that are sent to dsp objects. These events are in turn processed in the queue or the scheduler. When you play a sample with a phasor~, all timing (except for the phase 0 event) is done in the dsp thread.

The above, I believe, makes two things clear.
1) metro doesn’t deliver sample-accurate timing. Its accuracy may vary up to 2 ms, which is more than enough to hear phasing effects.
2) you have to be aware of all this technological stuff to be able to use max effectively.

I for myself conclude (as Trond says): max is a programming language. If you want to use it, you’ll have to learn about programming.

Cheers,
Mattijs

My test patch:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 115 201 77 196617 ? start playing;
#P newex 103 81 68 196617 prepend read;
#P newex 33 82 68 196617 prepend open;
#P button 33 41 15 0;
#P newex 33 58 56 196617 opendialog;
#P newex 141 255 41 196617 t 0 0 0;
#P user ezdac~ 39 371 83 404 0;
#P user meter~ 104 339 184 352 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 238 338 318 351 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P newex 98 255 41 196617 t 0 1 2;
#P newex 98 223 41 196617 sel 1 0;
#P toggle 98 201 15 0;
#P message 192 320 14 196617 1;
#N sfplay~ 1 120960 0 ;
#P newobj 192 338 44 196617 sfplay~;
#P newex 192 300 61 196617 metro 500;
#P newex 39 339 62 196617 wave~ fred;
#P newex 39 318 55 196617 phasor~ 2;
#P newex 103 101 96 196617 buffer~ fred 500 2;
#P comment 50 41 284 196617 ? read in a sample to use (only first 0.5 second will be used);
#P connect 15 0 14 0;
#P connect 14 0 16 0;
#P connect 9 2 2 0;
#P connect 13 0 2 0;
#P connect 2 0 3 0;
#P fasten 5 0 12 0 197 366 44 366;
#P fasten 3 0 12 0 44 366 44 366;
#P fasten 5 0 12 1 197 366 78 366;
#P fasten 3 0 12 1 44 366 78 366;
#P connect 9 0 2 1;
#P connect 7 0 8 0;
#P connect 8 0 9 0;
#P fasten 14 0 17 0 38 78 108 78;
#P connect 17 0 1 0;
#P connect 3 0 11 0;
#P connect 8 1 13 0;
#P connect 9 1 4 0;
#P connect 13 1 4 0;
#P connect 4 0 6 0;
#P fasten 16 0 5 0 38 129 197 129;
#P connect 13 2 5 0;
#P connect 6 0 5 0;
#P connect 5 0 10 0;
#P window clipboard copycount 19;


October 10, 2006 | 5:44 pm

Quote: bin wrote on Sat, 07 October 2006 14:33
—————————————————-
> i just use audio for all timing. sample tight sounds better to me.
> or you could use reaktor, which calculates the non audio path at signal rate so i hear…

It’s true that Reaktor does event-processing based on sampling (up to 3200 Hz, not signal rate). That system is incredibly crapp..ahum.. inferior to max’s event handling and always gives me a headache when tring to actually program a new application in it. For example: what happens when your computer can’t handle the amount of events for a short moment? Reaktor turns all cpu off! Or (as I experienced with reaktor 4, don’t know about 5) events simply don’t reach their destination, or (just as bad) it starts detecting event loops!

Wow, all that -anger-.. ;)

Mattijs


October 10, 2006 | 5:46 pm

Quote: mattijs@samplemadness.nl wrote on Tue, 10 October 2006 19:44
> Reaktor turns all cpu off!

Eh.. cpu processing.


October 10, 2006 | 6:11 pm

For more on the scheduler and event timing, please check out Joshua’s article

http://cycling74.com/story/2005/5/2/133649/9742

-A


October 10, 2006 | 7:15 pm

So, for example, the (high priority) scheduler will run at the sample rate if the Signal Vector is 1 and the SIAI (Scheduler In Audio Interrupt) option is checked?


October 10, 2006 | 10:00 pm

Wow, that article was very enlightening, I wish I would have seen that before.. but in the end it still told me that basically no options make the scheduler totally reliable in all situations… ugh.


October 11, 2006 | 1:54 pm

Nicholas C. Raftis III wrote:
> I posted 2 topics about problems with metro and tempo. I have seen
> at least 4 others in the past couple months. Why is such an
> essential object/series of objects flawed? I don’t know of any other
> software including poor quality ones that go out of sync like this…

I think there where a lot more replies to it than 4. Did you understand
those? You do have to sync if you want them synced, thats basically all…

If the scheduler tick is so much worse than lets say a quartz driven
watch, it will help you to design your patches more solid. Realy, sync
them instead of free running. It directly points to a possible flaw of
your patch design…

In the last years we had probably hundreds of threads about it. (You
could read them all and see how they answer the same questions all the
time…) So I do see a problem here, but its more about how to teach
newcomers to understand and finally do it to their satisfaction…

As cycling is now concentrating on Max 5, I am sure any constructive
proposals are more than welcome. Complaints about "flaws" won’t help
though. If you have ideas how it should be done instead, I guess it will
at least be considered…

Also bug reports will be listened to if they follow the guidelines…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 11, 2006 | 2:13 pm

Quote: Stefan Tiedje wrote on Wed, 11 October 2006 15:54
—————————————————-
> So I do see a problem here, but its more about how to teach
> newcomers to understand and finally do it to their satisfaction…

That’s right, and honestly I believe there is some improvement possible there. New max users are aware that the learning curve is steep, but not that it so steep as that you actually have to be aware of pretty in-depth technical details.

I wouldn’t know how to fix this though. I can imagine putting a big warning IF YOU’RE BAD AT MATH, GO AWAY! sign on the first page of the manual wouldn’t encourage artists to get to work with max.

Perhaps some ducumentation/education talents can put together a ‘learn this first’ manual. I’d be quite a challenge though, it shouldn’t be bigger than 5 pages and cover all basics of dsp and multi-threaded programming..

Mattijs


October 11, 2006 | 4:04 pm

Im not a newcomer, and Ive tried every single possible performance adjustment, signal in audio interrupt, overdrive, performance options.. using abstractions. and I was saying ive read at least 4 other threads about this, and Im sure tons of post each thread. If your saying there have been hundreds.. shouldn’t something get re-thought?

All Im saying is maybe the priority of the metro and tempo should be bumped up to the top, and/or a signal rate tempo~ or metro~ object should be included that is dependable.

Thanks for listening

Quote: Stefan Tiedje wrote on Wed, 11 October 2006 07:54
—————————————————-
> Nicholas C. Raftis III wrote:
> > I posted 2 topics about problems with metro and tempo. I have seen
> > at least 4 others in the past couple months. Why is such an
> > essential object/series of objects flawed? I don’t know of any other
> > software including poor quality ones that go out of sync like this…
>
> I think there where a lot more replies to it than 4. Did you understand
> those? You do have to sync if you want them synced, thats basically all…
>
> If the scheduler tick is so much worse than lets say a quartz driven
> watch, it will help you to design your patches more solid. Realy, sync
> them instead of free running. It directly points to a possible flaw of
> your patch design…
>
> In the last years we had probably hundreds of threads about it. (You
> could read them all and see how they answer the same questions all the
> time…) So I do see a problem here, but its more about how to teach
> newcomers to understand and finally do it to their satisfaction…
>
> As cycling is now concentrating on Max 5, I am sure any constructive
> proposals are more than welcome. Complaints about "flaws" won’t help
> though. If you have ideas how it should be done instead, I guess it will
> at least be considered…
>
> Also bug reports will be listened to if they follow the guidelines…
>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>
—————————————————-


October 11, 2006 | 4:25 pm

Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:04
—————————————————-
> Im not a newcomer

But probably not a dsp programmer either.. from the internal architecture of max it’s obvious that metro shouldn’t work the way you expect it to. Of course, when you are not familiar with the architecture of max I wouldn’t expect you to know this. What has to be changed is the help files or tutorials or any other documentation, but not max.

metro~: think this through.. what would it do? It would trigger an audio loop every so-much milliseconds.. hey, wait! That is actually the same functionality as phasor~!

Maybe it would be a good idea for you to post a specific idea you’d like to realize so that ppl can advise you which path to choose given the architecture of max.

Regards,
Mattijs


October 11, 2006 | 5:05 pm

Metro~ would output bangs at signal rate, so we wouldn’t have to sit here with 10 different versions of phasor and train with edge and notice that they all are out of sync. At least when I ran that test patch above, they were all ms off, and they were reading that they were up to 2 ms off each metro beat.

> Maybe it would be a good idea for you to post a specific idea you’d like to realize so that ppl can advise you which path to choose given the architecture of max.

I think Ive said what it is I want a million times, but heres 1 million and one:

A trustworthy metro or tempo object that stays on exact beat so I can put it into logic and it will fit with anything else, and that I don’t have to know how to program in C to use.

Quote: mattijs@samplemadness.nl wrote on Wed, 11 October 2006 10:25
—————————————————-
> Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:04
> —————————————————-
> > Im not a newcomer
>
> But probably not a dsp programmer either.. from the internal architecture of max it’s obvious that metro shouldn’t work the way you expect it to. Of course, when you are not familiar with the architecture of max I wouldn’t expect you to know this. What has to be changed is the help files or tutorials or any other documentation, but not max.
>
> metro~: think this through.. what would it do? It would trigger an audio loop every so-much milliseconds.. hey, wait! That is actually the same functionality as phasor~!
>

>
> Regards,
> Mattijs
—————————————————-


October 11, 2006 | 5:52 pm

It sounds like you are getting pretty frustrated. Perhaps you could try
posting a patch that demonstrates what you are trying to accomplish so
that the nice people on the forum can help you in a more effective way.

Saying that you want a perfect metro is a pretty vague request for help,
considering that we have no clue what you are putting after your metro.

Cheers,
Andrew B.


October 11, 2006 | 6:21 pm

Well thats what I want. Funny how logic, reaktor, nord modular, live, fruityloops and every other software Ive ever used stays in perfect sync but not max. I love max, the flexibility, the infinite possibilites.. but why is it all objects preform flawlessly but (to me) the most essential one.

what am I putting after my metro? A very complex sequencer patch that has loads of 16 step sequencers and sampler modules and tons of things. but it doesn’t matter if I just put a sine wave with an ADSR, the problem is still the same.. its off by a few ms no matter what settings I use.. and often after an hour of messing with my patch it ends up randomly stopping the metro and when I start it it will stop after about another minute…

The thing thats frustrating me is that people are acting like this problem is with me and not with the metro objects, and yet there sitting here saying they have the same problem.


October 11, 2006 | 6:53 pm

show us the ADSR simple patch that doesnt work.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Oct 11, 2006, at 2:21 PM, Nicholas C. Raftis III wrote:

>
> Well thats what I want. Funny how logic, reaktor, nord modular,
> live, fruityloops and every other software Ive ever used stays in
> perfect sync but not max. I love max, the flexibility, the
> infinite possibilites.. but why is it all objects preform
> flawlessly but (to me) the most essential one.
>
> what am I putting after my metro? A very complex sequencer patch
> that has loads of 16 step sequencers and sampler modules and tons
> of things. but it doesn’t matter if I just put a sine wave with an
> ADSR, the problem is still the same.. its off by a few ms no matter
> what settings I use.. and often after an hour of messing with my
> patch it ends up randomly stopping the metro and when I start it it
> will stop after about another minute…
>
> The thing thats frustrating me is that people are acting like this
> problem is with me and not with the metro objects, and yet there
> sitting here saying they have the same problem.
>
> –
> -=ili!ili=- http://www.Axiom-Crux.net -=ili!ili=-


October 11, 2006 | 7:04 pm

just download those other patches on the page to see what Im saying.
This is pointless. Don’t worry no more posts from me on this topic.


October 11, 2006 | 8:55 pm

I don’t understand why you can’t post a patch. Language is ambiguous.
Patching is not.

wes

On 10/11/06, Nicholas C. Raftis III wrote:
>
> just download those other patches on the page to see what Im saying.
> This is pointless. Don’t worry no more posts from me on this topic.
> –
> -=ili!ili=- http://www.Axiom-Crux.net -=ili!ili=-
>


October 11, 2006 | 10:17 pm

It may be that the best, truly most enlightening way to come to terms with the timing issues of the Max and MSP worlds (and they *are* two different worlds) is to drop acid and read some parallel-universe SciFi (maybe some Bob Wilson or the last installments of H2G2).

And get used to it.

metro is not "flawed" (well, in a sense it may be, but not in the black-and-white sense Nicholas III seems to be suggesting).

For instance: what’s a MSP-synched metro supposed to do when DSP is turned off? Stop?? Synch to nothing??? There are literally millions of existing patches in the world relying on metro’s behavior. It actually can be made to work reliably in non-MSP contexts, as well as being synchable to external event-based clocks. It handles CPU-overload in a pretty robust way. And it ain’t metro’s fault when you program a patch that overloads the CPU. If your CPU’s overloaded, then you obviously should have invested in a faster machine.-) (What, you’ve *only* got a 2.3 GHz Dual Core? Then you’re gonna need those fourfold 6.2 Ghz HexaCores available since 1979 in the universe where Trisha McMillan didn’t hook up with Zaphod).

MSP time and Max time are two different animals, and it’s simply a fact of life that the two don’t sync well. It would be *nice* if the two synched more easily, but they don’t. Like most facts of life, there are pretty fundamental reasons why it’s not likely to change in a hurry.

I could go on, but there’s a baby lizard staring at me through the picture window here and it’s, frankly, a lot cuter than anything in this thread. Maybe he can introduce me to Trillian’s pan-dimensional mice.

– P.


October 12, 2006 | 3:16 am

ok, the following patch is what i would like to think, is the most intense precise banging. providing that scheduler is in audio interrupt and signal vector size is set to 1. however, once sig.VS is set to anything higher than 1 bangs can’t happen every other sample sample…………………………………………..
1)……………..right???

2)is there any way of making this into 1 bang per sample? as far as i understand dig.audio its because of nyquist, that it can only be as often as 1bang per 2samples..correct?

3)if signal vector size is set to anyhting higher than 1, then sampling rate should be set 48000, so that further calculations with time are more precise.

4)after doing this patch i just realized the banging is 1 sample late, because edge~ bangs when signal changes from 0-1, but that can be easily fixed with a bit of signal mathematics coming from count~

5)regarding max 5. i would suggest a helpfile link inside metro and other timing objects to a patch that does sample accurate banging

—————————————
please comment:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 136 259 27 9109513 + 1;
#P flonum 111 419 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 109 461 49 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 107 338 49 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 43 329 78 9109543 1 64 345 0;
#X add 44100;
#X add 48000;
#X add 96000;
#X add 192000;
#P button 43 282 15 0;
#P newex 43 304 59 9109513 adstatus sr;
#B color 5;
#P comment 123 327 110 9109513 choose a sampling rate;
#P newex 99 385 56 9109513 expr $i2/$i1;
#P newex 372 180 44 9109513 capture~;
#P user ezdac~ 142 110 186 143 0;
#P newex 10 124 45 9109513 loadbang;
#P number 124 220 42 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 39 222 78 9109543 1 64 238 0;
#X add 1;
#X add 2;
#X add 4;
#X add 8;
#X add 16;
#X add 32;
#X add 64;
#X add 128;
#P button 39 171 15 0;
#P newex 39 193 73 9109513 adstatus sigvs;
#B color 5;
#P comment 56 172 155 9109513 report signal vector size choices;
#P comment 121 218 129 9109513 choose a signal vector size;
#P flonum 329 353 146 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 329 322 29 9109513 timer;
#P button 299 250 15 0;
#P newex 301 197 34 9109513 edge~;
#P newex 301 147 60 9109513 count~ 0 2 1;
#P newex 330 285 28 9109513 sel 1;
#N counter 0 1 3000;
#X flags 0 0;
#P newobj 330 254 78 9109513 counter 0 1 3000;
#P connect 22 0 0 4;
#P connect 2 0 3 0;
#P connect 2 0 15 0;
#P connect 24 0 16 0;
#P connect 24 0 2 1;
#P connect 1 0 5 0;
#P connect 1 0 5 1;
#P connect 0 0 1 0;
#P connect 3 0 4 0;
#P connect 3 0 0 0;
#P connect 5 0 6 0;
#P connect 21 0 16 1;
#P connect 12 0 24 0;
#P connect 9 1 12 0;
#P connect 16 0 23 0;
#P fasten 23 0 22 0 99 444 115 429;
#P connect 18 1 21 0;
#P connect 18 0 20 0;
#P fasten 20 0 18 0 48 346 30 346 30 300 48 300;
#P connect 19 0 18 0;
#P connect 13 0 10 0;
#P connect 13 0 19 0;
#P connect 9 0 11 0;
#P connect 10 0 9 0;
#P fasten 11 0 9 0 44 236 26 236 26 189 44 189;
#P window clipboard copycount 25;


October 12, 2006 | 9:52 am

Quote: Axiom-Crux wrote on Wed, 11 October 2006 18:05
—————————————————-
> Metro~ would output bangs at signal rate, so we wouldn’t have to sit here with 10 different versions of phasor and train with edge and notice that they all are out of sync. At least when I ran that test patch above, they were all ms off, and they were reading that they were up to 2 ms off each metro beat.
>
>

A reminder that I posted an external that does what’s described above. Unless you’re on Windows, it might solve your problem for now. It is posted on this earlier thread:

http://tinyurl.com/l49ch

Cheers,
Eric


October 12, 2006 | 10:32 am

>
> A reminder that I posted an external that does what’s described above. Unless you’re on Windows, it might solve your problem for now. It is posted on this earlier thread:
>
>

I should clarify that a bit. You cannot send bangs at the signal rate since a bang is a control rate event. But my external allows you to have up to 256 metronomes at tempi specified in different ways (ratio, ms, samples) and they will all stay in sync (sample-accurate) for longer than you’ll ever run them. You can convert the metronomes to bangs with edge~ adding only local inaccuracy within the size of a signal vector, but not affecting the accuracy of the underlying clocks.

Eric


October 13, 2006 | 10:13 pm

Nicholas C. Raftis III wrote:
> All Im saying is maybe the priority of the metro and tempo should be
> bumped up to the top, and/or a signal rate tempo~ or metro~ object
> should be included that is dependable.

This is my metro~: let me know how it works for you…

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 153 64 20 196617 b 1;
#P message 153 84 35 196617 60000;
#P newex 153 107 42 196617 / 60.;
#P inlet 185 42 15 0;
#P newex 72 41 45 196617 loadbang;
#P newex 110 132 32 196617 sel 0;
#P outlet 59 184 15 0;
#N vpatcher 306 165 666 468;
#P window setfont "Sans Serif" 9.;
#P newex 128 87 50 196617 int $1;
#P newex 230 75 77 196617 0.499;
#P inlet 230 55 15 0;
#P newex 145 54 83 196617 loadbang;
#P inlet 128 55 15 0;
#P outlet 128 241 15 0;
#P newex 128 113 51 196617 !/ 1000.;
#P newex 128 189 43 196617 >~ 0.5;
#P newex 128 216 50 196617 edge~;
#P flonum 128 139 62 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 128 161 112 196617 phasor~ 0.5;
#P fasten 7 0 10 0 150 80 133 80;
#P connect 6 0 10 0;
#P connect 10 0 4 0;
#P connect 4 0 1 0;
#P connect 1 0 0 0;
#P connect 0 0 3 0;
#P connect 3 0 2 0;
#P connect 2 0 5 0;
#P connect 8 0 9 0;
#P connect 9 0 0 1;
#P pop;
#P newobj 59 157 61 196617 p MSPMetro;
#P newex 59 132 35 196617 mute~;
#P message 85 84 13 196617 0;
#P message 33 84 13 196617 1;
#P newex 59 107 28 196617 == 0;
#P newex 33 63 90 196617 route bang int stop;
#P inlet 142 41 15 0;
#P inlet 33 42 15 0;
#P fasten 11 0 14 0 190 60 158 60;
#P connect 11 0 12 1;
#P connect 13 0 12 0;
#P connect 14 0 13 0;
#P connect 9 0 7 1;
#P connect 3 0 6 0;
#P fasten 3 0 9 0 64 128 115 128;
#P connect 2 2 5 0;
#P connect 10 0 5 0;
#P connect 7 0 8 0;
#P fasten 1 0 7 0 147 153 64 153;
#P connect 6 0 7 0;
#P fasten 12 0 7 0 158 153 64 153;
#P fasten 5 0 3 0 90 103 64 103;
#P fasten 4 0 3 0 38 103 64 103;
#P connect 2 1 3 0;
#P connect 2 0 4 0;
#P connect 0 0 2 0;
#P window clipboard copycount 15;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 13, 2006 | 11:45 pm

(clock)JITTER: Heres a feature request. trigger the max scheduler
from an audio pulse such as train~ object? or MTC? that at least
would sync outgoing events.

DRAG:
Can I just inquire why this can’t be fixed with metro? to correct
drag, it would seem to me( a programming noob for sure) that you
could compare the mathematical ideal timing with the current cpu
clock and correct on the next beat.

I’ll try it soon.

-matt


October 14, 2006 | 6:36 am

This is what setclock is for.

Best,
Trond

matthew aidekman wrote:
> (clock)JITTER: Heres a feature request. trigger the max scheduler
> from an audio pulse such as train~ object? or MTC? that at least would
> sync outgoing events.
>
> DRAG:
> Can I just inquire why this can’t be fixed with metro? to correct
> drag, it would seem to me( a programming noob for sure) that you could
> compare the mathematical ideal timing with the current cpu clock and
> correct on the next beat.
>
> I’ll try it soon.
>
> -matt


October 15, 2006 | 6:28 am

me and him wrote:
> 5)regarding max 5. i would suggest a helpfile link inside metro and
> other timing objects to a patch that does sample accurate banging
>
> ————————————— please comment:

I think it would be much more helpfull to point to conceptual
differences between events and samples. Then you would not try to bring
your CPU down for no benefit at all.

What do you want to do with sample accurate bangs? Whatever really needs
to be sample accurate I’d do completely within audiorate and it still
would be less of a CPU hog than a vectorsize of 1.

MSP is dealing with a constant stream of computation…
Max is only calculating when needed/banged and thus event driven…
Our brain isn’t sample accurate on events, but it is on sound…
Usually we are happy with the accuracy of Midi which would be roughly
1ms, which is 48 samples at your suggested samplerate. Anything which
goes beyond that is waste of CPU…
I must admit, I like the difference in sound which might be audible by
the jitter which is introduced through scheduler events. I do not have
rythmical problems with it…

This whole demand sounds for me like overkill control and a very
theorethical issue…

just my 2.5 cents

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 15, 2006 | 11:37 am

> I must admit, I like the difference in sound which might be audible by
> the jitter which is introduced through scheduler events. I do not have
> rythmical problems with it…

This can be nice, but on the other hand, the user should have a choice on this point. When multiple soundfiles are being triggered on the same downbeat, in some cases it is desirable for them to all be triggered at the same sample point.

>
> This whole demand sounds for me like overkill control and a very
> theorethical issue…

In many cases you are certainly correct. However a reason to want sample-accurate timing (*) in other cases is that this minimizes accumulation of error over a long period of time. You might be acceptably in sync when you start a metro, but not doing so well three minutes into your groove. You would notice this if you tried to sync your metro to a long soundfile that articulates a beat with sample accuracy.

Eric

* Actually sub-sample accurate timing where the underlying clock is accumulating with accuracy limited only by word-size (not sampling rate), and is then rounded to the nearest sample.


October 15, 2006 | 12:36 pm


October 15, 2006 | 1:56 pm

>
> > In many cases you are certainly correct. However a reason to want
> > sample-accurate timing (*) in other cases is that this minimizes accumulation
> > of error over a long period of time. You might be acceptably in sync when you
> > start a metro, but not doing so well three minutes into your groove. You would
> > notice this if you tried to sync your metro to a long soundfile that
> > articulates a beat with sample accuracy.
>
> But with Scheduler in Audio Interrupt, there should be no long-term
> accumulation of errors, isn’t it?
>

According to my tests, even with scheduler in audio interrupt and overdrive turned on, drift occurs very quickly in Max with fairly minimal event input present. (Surprisingly, this is not the case for Pd.) I’ve only tested this as recently as 4.5.x so if you get a different result for 4.6.x please post it.

Eric


October 15, 2006 | 7:53 pm

Im glad you said it Eric. Now maybe people will take it to heart. Everyone seemed to argue when I said it.

> According to my tests, even with scheduler in audio interrupt and overdrive turned on, drift occurs very quickly in Max with fairly minimal event input present. (Surprisingly, this is not the case for Pd.) I’ve only tested this as recently as 4.5.x so if you get a different result for 4.6.x please post it.
>
> Eric
—————————————————-


October 17, 2006 | 12:59 am

stephan:

it is not necessary to run everything at 1 sample per chunk (signal v. size). you can use pfft~ to change things 16,32,64etc.

you’d be surprised how different some instruments react to the same sequence played sample accurately and played through banging metro…not always desirable


October 17, 2006 | 9:48 am

matthew aidekman wrote:
> (clock)JITTER: Heres a feature request. trigger the max scheduler
> from an audio pulse such as train~ object? or MTC? that at least would
> sync outgoing events.
>
> DRAG:
> Can I just inquire why this can’t be fixed with metro? to correct drag,
> it would seem to me( a programming noob for sure) that you could
> compare the mathematical ideal timing with the current cpu clock and
> correct on the next beat.

Like this? Just a patch to explore sync/out of sync with different
settings between metro and metro~ (the patch I posted in the same thread…)

#P button 251 86 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 245 72 32 196617 sync;
#P button 32 88 15 0;
#P newex 15 113 43 196617 onebang;
#P newex 218 113 43 196617 onebang;
#N vpatcher 30 89 630 489;
#P window setfont "Sans Serif" 9.;
#P newex 43 69 39 196617 t 1 0 b;
#P newex 71 93 27 196617 int;
#P inlet 43 49 15 0;
#P inlet 88 49 15 0;
#P outlet 43 115 15 0;
#P outlet 71 115 15 0;
#P connect 3 0 5 0;
#P connect 5 1 1 0;
#P connect 5 0 1 0;
#P connect 5 2 4 0;
#P connect 4 0 0 0;
#P connect 2 0 4 1;
#P pop;
#P newobj 138 63 63 196617 p sync -1;
#P button 138 44 15 0;
#P hidden newex 277 258 65 196617 sampstoms~;
#P flonum 303 235 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 243 234 44 196647 1 64 250 0;
#X add 1;
#X add 2;
#X add 4;
#X add 8;
#X add 16;
#X add 32;
#X add 64;
#X add 128;
#X add 256;
#X add 512;
#X add 1024;
#X add 2048;
#X add 4096;
#P comment 153 236 90 196617 Signal Vector Size;
#P comment 160 45 100 196617 or here here…. (-1);
#P comment 108 198 134 196617 Max Scheduler in Overdrive;
#P comment 108 216 135 196617 Scheduler in Audio Interrupt;
#P user umenu 243 196 44 196645 1 64 212 0;
#X add Off;
#X add On;
#P hidden newex 319 196 94 196617 adstatus overdrive;
#P user umenu 243 215 44 196645 1 64 231 0;
#X add Off;
#X add On;
#P hidden newex 319 215 89 196617 adstatus takeover;
#P number 60 201 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 130 154 15 0;
#P button 60 154 15 0;
#P newex 60 174 80 196617 timer;
#P newex 60 55 73 196617 t i 1;
#P number 130 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 60 135 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 130 26 25 196617 0 , 1;
#P toggle 60 35 15 0;
#P user ezdac~ 243 157 287 190 0;
#N counter;
#X flags 0 0;
#P newobj 130 113 50 196617 counter;
#N counter;
#X flags 0 0;
#P newobj 60 113 50 196617 counter;
#P newex 130 83 62 196617 metro 1000;
#P newex 60 83 67 196617 metro~ 1000;
#P comment 158 27 167 196617 you can restart metro here…. (+1);
#P comment 26 74 32 196617 sync;
#P comment 289 236 17 196617 =;
#P comment 337 236 20 196617 ms;
#P hidden newex 319 234 73 196617 adstatus sigvs;
#P fasten 5 0 33 0 65 108 20 108;
#P connect 34 0 33 1;
#P connect 10 0 14 0;
#P connect 14 0 5 0;
#P connect 5 0 7 0;
#P connect 7 0 12 0;
#P connect 12 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 18 0;
#P fasten 14 1 7 2 128 106 85 106;
#P fasten 33 0 11 0 20 136 10 136 10 22 135 22;
#P connect 31 0 6 0;
#P fasten 14 0 6 0 65 78 135 78;
#P connect 11 0 6 0;
#P connect 6 0 8 0;
#P connect 8 0 13 0;
#P connect 13 0 17 0;
#P connect 17 0 15 1;
#P fasten 32 0 30 0 223 139 290 139 290 42 143 42;
#P connect 30 0 31 0;
#P fasten 31 1 8 2 196 106 155 106;
#P fasten 14 1 8 2 128 106 155 106;
#P fasten 8 0 31 1 135 133 203 133 203 61 196 61;
#P fasten 6 0 32 0 135 103 223 103;
#P hidden fasten 21 0 22 0 324 216 319 216 289 194 248 194;
#P hidden fasten 19 0 20 0 324 235 320 235 290 213 248 213;
#P hidden fasten 0 0 27 0 324 255 317 255 287 233 248 233;
#P connect 36 0 32 1;
#P hidden connect 27 1 29 0;
#P hidden connect 29 1 28 0;
#P hidden fasten 22 0 21 0 248 214 293 214 319 193 324 193;
#P hidden fasten 20 0 19 0 248 233 294 233 320 212 324 212;
#P hidden fasten 27 0 0 0 248 253 291 253 317 232 324 232;
#P window clipboard copycount 37;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 17, 2006 | 12:13 pm

Eric Lyon wrote:
> This can be nice, but on the other hand, the user should have a
> choice on this point. When multiple soundfiles are being triggered on
> the same downbeat, in some cases it is desirable for them to all be
> triggered at the same sample point.

There is still the choice not to leave the audio domain.

> In many cases you are certainly correct. However a reason to want
> sample-accurate timing (*) in other cases is that this minimizes
> accumulation of error over a long period of time. You might be
> acceptably in sync when you start a metro, but not doing so well
> three minutes into your groove. You would notice this if you tried to
> sync your metro to a long soundfile that articulates a beat with
> sample accuracy.

This would be addressed with metro~ the patch I attached on my last mail…

> * Actually sub-sample accurate timing where the underlying clock is
> accumulating with accuracy limited only by word-size (not sampling
> rate), and is then rounded to the nearest sample.

I made a stopwatch based on the systemclock which would even survive a
time you set the computer to sleep… On Mac OS its only a 60th second
exact which seems good enough… Its not syncronized to an
audiointerface but would not drift as much as metro.
This would be another attempt to syncronize a metro…
But as I pointed out earlier. Syncronisation needs to be understood as
principle. If my metro drifts with something else and I want it to stay
together, it just points to a misconception in the patch, which is
better than a slight drift which I might not recognize imediatly and
later will create headaches to addapt my patch to correct syncronization…

Stefan

P.S. I know you know all that, just thought it might be helpfull
information for archive crawlers…


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 18, 2006 | 12:24 pm

i sold a big nested for next loop to ZX computing magazine in 1982 for


October 18, 2006 | 1:47 pm

Nicholas C. Raftis III wrote:
> Im glad you said it Eric. Now maybe people will take it to heart.
> Everyone seemed to argue when I said it.
>
>> According to my tests, even with scheduler in audio interrupt and
>> overdrive turned on, drift occurs very quickly in Max with fairly
>> minimal event input present. (Surprisingly, this is not the case
>> for Pd.) I’ve only tested this as recently as 4.5.x so if you get a
>> different result for 4.6.x please post it.

I’d like to know what in this context "drift occurs very quickly" means.
With the patch I sent recently I would notice an expected jitter of the
duration of the vectorsize, but no drift for maybe half an hour…

But one thing I did notice: It was stable as long I was not patching,
opening windows and so on. With patching around I did get drifts, but
not as something drifting out of sync, but more like one of the two
metros was interupted occasionally and the other wasn’t…

If I create one audio patch chord I would interrupt audio very shortly,
which would introduce at least one scheduler tick of delay for the audio
driven part, and thats already around one millisecond, probably longer
if I load a subpatcher…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


November 14, 2006 | 9:35 am

> matthew aidekman wrote:
>
>> (clock)JITTER: Heres a feature request. trigger the max
>> scheduler from an audio pulse such as train~ object? or MTC? that
>> at least would sync outgoing events.
>> DRAG:
>> Can I just inquire why this can’t be fixed with metro? to correct
>> drag, it would seem to me( a programming noob for sure) that you
>> could compare the mathematical ideal timing with the current cpu
>> clock and correct on the next beat.
>>
>
> Like this? Just a patch to explore sync/out of sync with different
> settings between metro and metro~ (the patch I posted in the same
> thread…)
>
>
>

sorry to bring an old flame war up. but since, stefan responded
specifically to me with a question, I felt obligated.

Believe it or not stefan, I *Just* got around to looking at your
patch. I was really interested to see some sort of back door but no
such luck.this is not really what I meant. First of all, your patch
addresses lag and not the jitter which is inherant in the max scheduler.

The point was since msp, by nature has sample accuracy. if you could
somehow, "schedule" a max tick for a specific sample using a train~
object. process midi at X audio sample. the reasons for doing this
are two fold. first of all, the clock jitter would go away, but more
importantly, you could have BETTER RHYTHM WITH TONS LESS CPU!!. this
would be because you might only decide to trigger the max scheduler
16 times a second. but when you did, it would be dead on.

And just to be clear that this is not a small issue. I’ve posted yet
another patch on the subject. As a drummer, if I had heard this
demonstration, I would never have begun to program ANYTHING having to
do with rhythm in max. its not a matter of subltly, its a matter of
feel. and in drum world, thats what separates good from bad. plain
and simple.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 535 90 48 196617 loadbang;
#P message 634 210 14 196617 0;
#P message 560 213 14 196617 1;
#P window setfont "Sans Serif" 18.;
#P message 633 110 82 196626 MSPrate;
#P window setfont "Sans Serif" 9.;
#P newex 562 179 122 196617 select MAXrate MSPrate;
#P window setfont "Sans Serif" 18.;
#P message 542 111 84 196626 MAXrate;
#P window setfont "Sans Serif" 9.;
#P newex 261 634 27 196617 *~;
#B color 5;
#P newex 147 639 27 196617 *~;
#B color 5;
#P newex 164 605 31 196617 == 0;
#B color 5;
#P newex 147 426 50 196617 clip~ 0 1;
#P newex 147 488 120 196617 comb~ 8 0.9 0.3 0. 0.95;
#B color 5;
#P user ezdac~ 185 691 229 724 0;
#P newex 273 455 37 196617 click~;
#P newex 273 422 36 196617 edge~;
#P newex 273 370 31 196617 abs~;
#P newex 272 323 40 196617 trunc~;
#P newex 272 173 32 196617 *~ 4;
#P newex 273 344 38 196617 delta~;
#P newex 273 522 32 196617 *~ 1;
#B color 5;
#P newex 273 485 120 196617 comb~ 8 0.9 0.3 0. 0.95;
#B color 5;
#P newex 272 124 40 196617 sync~;
#P window linecount 2;
#P comment 587 83 100 196617 click to hear the difference;
#P connect 7 0 12 0;
#P connect 12 0 11 0;
#P connect 11 0 14 0;
#P connect 20 0 13 0;
#P connect 19 0 13 0;
#P connect 13 0 14 1;
#P connect 14 0 10 0;
#P connect 15 0 10 0;
#P connect 14 0 10 1;
#P connect 15 0 10 1;
#P connect 3 0 15 0;
#P connect 1 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 4 0;
#P connect 4 0 7 0;
#P connect 7 0 8 0;
#P connect 8 0 9 0;
#P connect 9 0 2 0;
#P connect 2 0 3 0;
#P connect 19 0 15 1;
#P connect 20 0 15 1;
#P connect 21 0 16 0;
#P connect 17 0 19 0;
#P connect 18 0 17 0;
#P connect 16 0 17 0;
#P connect 17 1 20 0;
#P window clipboard copycount 22;


November 14, 2006 | 10:17 am

On 14 Nov 2006, at 09:35, matthew aidekman wrote:

> Believe it or not stefan, I *Just* got around to looking at your
> patch. I was really interested to see some sort of back door but
> no such luck.this is not really what I meant. First of all, your
> patch addresses lag and not the jitter which is inherant in the max
> scheduler.

Many, many, many years ago (possibly even before MSP) there was talk
of being run Max in a special "slightly in the future" mode, where it
would pre-render events (and, in this context, audio) with high
precision, at the cost of being able to respond in realtime to input
(either events or audio). This always struck me as ideal for things
like interactive step sequencers where the timing is critical, but a
20th of a second or so lag to pushing a button is less so.

In the meantime, perhaps all we can hope for is computers fast enough
to run with a signal vector size of 1…

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com


November 14, 2006 | 6:51 pm

That patch is a real eye opener. Thanks for posting it. Oh Max…..

v a d e //

http://www.vade.info
abstrakt.vade.info


November 14, 2006 | 10:30 pm

> I wouldn’t know how to fix this though. I can imagine putting a big warning IF YOU’RE BAD AT MATH, GO AWAY! sign on the first page of the manual wouldn’t encourage artists to get to work with max.

> Mattijs

"MAXING CAN CAUSE BRAIN CANCER"

"MAXARETTES DO HARM TO YOUR UNBORN CHILD"

but on the topic – in danger of repeating myself – the
easiest was to get a proper click system is staying
on the signal layer all through the "sequencer".

i have been trying to use some phasor~/edge~ thing instead
of metro from time to time, and it usualy is not running
much better than metro – at my preferred runtime vector
size anyway.

-110


November 14, 2006 | 10:42 pm

Quote: Axiom-Crux wrote on Wed, 11 October 2006 11:05
—————————————————-
> Metro~ would output bangs at signal rate, so we wouldn’t have to sit here with 10 different versions of phasor and train with edge and notice that they all are out of sync.

yes we all want that, but this isnt possible for
a "technical" reason, ar beyond the metro object.

>At least when I ran that test patch above, they were all ms >off, and they were reading that they were up to 2 ms off each >metro beat.

2ms is hardly noticalbe in music, it would better than most
midi interfaces (including the midi interfaces at hw synths).

my problems with metro begin, generally speaking, with
1/32 notes. with 2 ms you have no reason to whine. :)

> A trustworthy metro or tempo object that stays on exact beat so I can put it into logic and it will fit with anything else, and that I don’t have to know how to program in C to use.
>

inside plug-ins (in logic/cubase/nuendo) i am not aware of
serious "timing" problems – only in max standalones.

the only thing youre asking for i am able to name it
concrete would be a signal (click) output for the plugsync~
object. but like i said, i am fine with its number and bang
output until now.

-110


November 14, 2006 | 11:54 pm

> i have been trying to use some phasor~/edge~ thing instead
> of metro from time to time, and it usualy is not running
> much better than metro – at my preferred runtime vector
> size anyway.

Haven’t been following this thread closely, but the above seemed
noteworthy to perhaps comment on. There’s nothing to suggest that
phasor~ -> edge~ would perform better than metro (with the exception
that metro will drop bangs under heavy scheduler loads if scheduler
time drops behind actual time by more than the scheduler slop time).
If people wish to perform sample accurate timing, then it is
necessary *stay* in the signal domain. Moving from signal to event
(i.e. phasor~ -> edge~) is where you move to the timing irregularity
of the event scheduler.

In my sample accurate work I typically use a master phasor~ driving
either %~, pong~, or rate~ for local clocks, but a very useful object
in the existing object set which may have been overlooked is zigzag~.
This is a sample accurate signal triggerable and looping breakpoint
envelope. You can sync as many as you like with one click~ object or
phasor~ object, or whatever as well. And don’t overlook that sfplay~
is signal triggerable.

For more information about scheduler slop, scheduler loads, and other
topics, you might find the article I have on the subject informative:

http://www.cycling74.com/story/2005/5/2/133649/9742

-Joshua


November 15, 2006 | 12:27 am

> Haven’t been following this thread closely, but the above seemed
> noteworthy to perhaps comment on. There’s nothing to suggest that
> phasor~ -> edge~ would perform better than metro

yes i know joshua – but there are abot 10 people which
made custom [metro~] objects working this way (using
DSP to output bang messages) – claiming that would
be more accurate ;)

> In my sample accurate work I typically use a master phasor~ driving
> either %~, pong~, or rate~ for local clocks, but a very useful object
> in the existing object set which may have been overlooked is zigzag~.
> This is a sample accurate signal triggerable and looping breakpoint
> envelope. You can sync as many as you like with one click~ object or
> phasor~ object, or whatever as well. And don’t overlook that sfplay~
> is signal triggerable.

yes – but what is with say, giving a command to
[groove~] that it should change its buffer.

at that point its now useful to learn about how to make
messages as "fast" as possible, though the main focus
here will be always the little problem to keep 20 of such messages as much in sync as possible. :) – would be no
problem in a DSP system – but is by definition impossible
to do with message commands.

> http://www.cycling74.com/story/2005/5/2/133649/9742

yes.

-110


November 15, 2006 | 3:36 am

On Nov 14, 2006, at 4:27 PM, Roman Thilenius wrote:

> yes i know joshua – but there are abot 10 people which
> made custom [metro~] objects working this way (using
> DSP to output bang messages) – claiming that would
> be more accurate ;)

I think Eric’s solution in the instance that it uses edge~ to
generate events is primarily advantageous in that it eliminates the
need to increase the scheduler slop to some very large level for a
metro based solution. He obviously also has lots of other convenient
things like specifying the units of the periodicity and such, but as
far as I can tell, the basic issue of any metronomes not retaining
appropriate synchronization over long periods of time is only
accounted for by this scheduler slop behavior, which is user
configurable to have better long term or short term correlation to
wall time. Internally there is a main scheduler where time advances
with the CPU clock, and period is accumulated with double precision
floating point numbers, so if the scheduler slop is increased to
something large (say 500ms), there should be no noticeable difference
between Eric’s object -> edge~ and several metro objects. If someone
sends me an example patch that illustrates some other issue, we can
investigate it for future MSP releases.

From reading Eric’s ICMC paper on the subject, it would seem that he
is not considering the scheduler slop behavior in Max/MSP. Please
note that this is not at all an attempt to discount Eric’s analysis
of the Max scheduler or his custom external based solutions. I only
hope to clarify some aspects of the scheduler, and some already
existing sample accurate tools that are present in MSP (arguably
under-advertised, however).

Eric’s solution is convenient and useful for a pure signal based
event structure (i.e. no scheduler events). I believe that almost all
of the tasks described in his paper can be done with existing MSP
objects (as I typically use to accomplish similar goals), but it can
be cumbersome. First, note that the speculated "clickline~" object
actually exists under the name zigzag~. This object (which seems like
it can be used to simulate Eric’s mask~ object) has several other
advantages over line~ including variable speed playback, sample
accurate looping, the ability to dynamically edit the breakpoint
envelope, and more. Second, there’s all sorts of things you can do
with a phasor~ or zigzag~ driven buffer~ as a sequence table of
sample accurate click events. This is how I typically accomplish
things Eric seems to accomplish with the dmask~ object.

Again, this is not to dismiss Eric’s great work, but only to clarify
a few points that seem to have been overlooked.

> yes – but what is with say, giving a command to
> [groove~] that it should change its buffer.

Yes, this is a tricky one to guaranteedly synchronize amongst
multiple objects. However, keep in mind that all scheduler events are
processed "deep". That is to say that if you have one source event
("bang"), and have not introduced any asynchrony via defer, pipe, or
delay, then the single scheduler event will be processed, switching
all the buffers before the next scheduler event is processed. This
becomes an issue for the MSP user if the scheduler is not run in
audio interrupt, since the audio can interrupt the single Max
scheduler event as it is processing. My recommendations in this or
other settings which require scheduler event completion prior to DSP
execution would be to run the scheduler in audio interrupt.

Caveats w/r/t scheduler in audio interrupt, and I/O vector size: if
the I/O vector size is large, and the DSP usage is low, metronome
events will "clump" towards the beginning of an entire I/O vector.

Anyway, there are many competing interests to consider in getting
optimal timing, optimal performance, and optimal latency in the
context of mixed media systems where different entities have
different priorities. I’m probably going to drop out of the thread at
this point to get more programming done, but maybe some of this is
useful info.

-Joshua


November 15, 2006 | 5:28 am

> I’m probably going to drop out of the thread at this point to get
> more programming done, but maybe some of this is useful info.

Thank you, Joshua, your input is always knowledge driven and
diplomatic. These are especially critical trates when covering
heavily debatable and debated topics such as this.

sorry to rikindle this topic.

-matt


November 15, 2006 | 2:07 pm

>> I’m probably going to drop out of the thread at this point to get
>> more programming done, but maybe some of this is useful info.
>
> Thank you, Joshua, your input is always knowledge driven and
> diplomatic.

Yes,
Thanks Joshua.


November 17, 2006 | 9:56 am

Hi,

I’m doing a gig tonight so any help with this would be appreciated. I
have been preparing for a month now, and the day before a gig
everything is seemingly screwed up. Here’s the problem. I’m using three
patches at a time, one with msp objects, one with jitter objects and
the performance setup from the jitter tutorials. if I am using the msp
patch and the Jitter patch the audio is completely screwed up. it
sounds like a loud, wavering low frequency, and the movie doesn’t run
so well. And when I try to toggle a metro object on and off it takes a
couple seconds to respond. If I close the jitter patch every thing is
normal again with the audio.

Like I said this problem wasn’t happening till today. I tried deleting
a bunch of stuff off my hard drive, so now I have 30 gigs of free
space, and I defragmented my hard drive. that didn’t help. I tried
turning overdrive on and off, messing with the performance options,
changing the cpu limit. nothing is helping or working.

I have a funny feeling I accidentally changed some setting that is
causing all these problems, I really don’t know how else something like
this could spontaneously happen.

I have a 1.25 GHz mac powerbook g4 with 1 gig of ram. running osx 10.3.9
max 4.5 and jitter 1.5.2

If anyone has any suggestions I would really appreciate it. thanks,
nick


November 17, 2006 | 10:33 am

17/11/06, kl. 10:56 +0100 , skrev Nick:

>I have a funny feeling I accidentally changed some setting that is
>causing all these problems, I really don’t know how else something like
>this could spontaneously happen.

Signal Vector Size?
What are your settings anyway…?

J


November 17, 2006 | 1:51 pm

signal vector is 512, sampling rate 44100, audio interrupt on,
overdrive on, optimize on, cpu limit 80%. I’m using a M- audio ozone
interface, but i don’t think it has anything to do with the interface
as other audio sounds fine through it.

nick.

On Nov 17, 2006, at 5:33 AM, Jakob Riis wrote:

> 17/11/06, kl. 10:56 +0100 , skrev Nick:
>
>> I have a funny feeling I accidentally changed some setting that is
>> causing all these problems, I really don’t know how else something
>> like
>> this could spontaneously happen.
>
> Signal Vector Size?
> What are your settings anyway…?
>
> J
>
>


November 17, 2006 | 1:56 pm

> maybe you should think less of MaxMSP in terms of being a piece of
> software than a programming language? If tempo/metro were to stay synced
> to audio it would have to be implemented in a similar way to control
> rate in Csound. That might put severe limitations on how much you could
> expect to do following one bang without getting audio stutter due to
> severe CPU spikes. Some of us might be quite dependent on the ability to
> have the metro running in a different scheduler to audio.

*Very* nicely put, Trond. I’m not sure that this would be intuitively obvious to anyone who’s looking for a Reaktor stand-in or some other subset of the functionality of an entire graphic programming environment, though.

But if you’re the sort of person who just *has* to have a problem solved in precisely the way *you* visualize the solution as being rather than repatching or investigating issues of operating system timing or other tiresome stuff, there’s always "the google" or "the internets," which would turn something like this up (even if you missed all his postings to the Max forum):

http://lac.zkm.de/2006/papers/lac2006_eric_lyon.pdf

I commend the paper to you for its clear description of the issues which surround this problem not only in Max, but in Pd as well. A bit more investigation and reading (and some email) would suggest that the paper’s author is going to be making the externals described above and their source code available quite soon. Given Eric’s compositional output [he actually does interesting things with the drum machine paradigm], it’s not too surprising that he would put his hand to this (and to do so with elegance and grace). Lots of people are about to owe him a pint, methinks.

I’d expect to see him announce the availability of his externals on the Max list generally, at which point they’ll no doubt show up on maxobjects.com.


November 17, 2006 | 2:00 pm

I usually keep:
overdrive=off && audio interrupt = off
as they used to cause (embarrassing live performance crashing)
problems for me
not sure if this helps but worth a try…

On Nov 17, 2006, at 5:59 AM, Nick wrote:

> signal vector is 512, sampling rate 44100, audio interrupt on,
> overdrive on, optimize on, cpu limit 80%. I’m using a M- audio
> ozone interface, but i don’t think it has anything to do with the
> interface as other audio sounds fine through it.
>
> nick.
>
>
> On Nov 17, 2006, at 5:33 AM, Jakob Riis wrote:
>
>> 17/11/06, kl. 10:56 +0100 , skrev Nick:
>>
>>> I have a funny feeling I accidentally changed some setting that is
>>> causing all these problems, I really don’t know how else
>>> something like
>>> this could spontaneously happen.
>>
>> Signal Vector Size?
>> What are your settings anyway…?
>>
>> J
>>
>>
>


November 17, 2006 | 2:48 pm

Nick :

> signal vector is 512, sampling rate 44100, audio interrupt on,
> overdrive on, optimize on, cpu limit 80%. I’m using a M- audio ozone
> interface, but i don’t think it has anything to do with the interface
> as other audio sounds fine through it.

You should remove the overdrive when using Jitter


November 17, 2006 | 3:03 pm

I changed the I/O Vector size to 1024 and the Signal Vector size to
1024. I had Signal Vector on 1. I think that was the problem because
now everything is fine again. I don’t know what those things do, but i
must have accidentally changed them. thanks very much for your
suggestions, nick

On Nov 17, 2006, at 9:48 AM, julien breval wrote:

> Nick :
>
>> signal vector is 512, sampling rate 44100, audio interrupt on,
>> overdrive on, optimize on, cpu limit 80%. I’m using a M- audio ozone
>> interface, but i don’t think it has anything to do with the interface
>> as other audio sounds fine through it.
>
> You should remove the overdrive when using Jitter
>


November 17, 2006 | 3:26 pm

On 17 Nov 2006, at 14:48, julien breval wrote:

> You should remove the overdrive when using Jitter

Overdrive is necessary for accurate (if not sample-accurate) timing
of events.

Jitter provides its own mechanisms (qmetro and friends) for running
cooperatively in an overdriven Max.

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com


November 17, 2006 | 6:16 pm

> But if you’re the sort of person who just *has* to have a problem
> solved in precisely the way *you* visualize the solution as being
> rather than repatching or investigating issues of operating system
> timing or other tiresome stuff,

thats not true about me. I’ve attempted to be very humble in a
touchy thread. obviously I haven’t tried enough.

-matt


November 17, 2006 | 10:21 pm

> I’ve attempted to be very humble in a
> touchy thread. obviously I haven’t tried enough.

You’ve been a model of tact, as far as I’m
concerned. Given our discussions of this in
the past, I am generally of the opinion that
you may find Eric’s solutions to be to your
liking – although, as Joshua says, remaining in
the signal domain for clocking is a good solution.

The advantage here is that the choice is yours,
providing that you can remain patient until Eric
posts his stuff. :-)


November 18, 2006 | 6:35 am

matthew aidekman wrote:
> sorry to bring an old flame war up. but since, stefan responded
> specifically to me with a question, I felt obligated.
>
> Believe it or not stefan, I *Just* got around to looking at your
> patch. I was really interested to see some sort of back door but no
> such luck.this is not really what I meant. First of all, your patch
> addresses lag and not the jitter which is inherant in the max scheduler.

That is correct…

> And just to be clear that this is not a small issue. I’ve posted yet
> another patch on the subject. As a drummer, if I had heard this
> demonstration, I would never have begun to program ANYTHING having to
> do with rhythm in max. its not a matter of subltly, its a matter of
> feel. and in drum world, thats what separates good from bad. plain
> and simple.

I’d never want to tell a drummer something about rythm accuracy…
When I tried your patch, which could make it into a standard for
explaining some Max basics by the way, I thought: oh, never heard
somthing that out of sync – jittery for a long time. But when I turned
my signal vector size from 1024 down to 64, and set scheduler in audio
interupt I can’t hear the difference anymore, but that might be my
untight ears which would not care about a jitter of 1.5 milliseconds (I
wouldn’t be able to play that exact anyway… ;-)

But it seems scheduler in audio interupt is a requirement for exact
timing…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


November 18, 2006 | 6:25 pm

yeah mine were already at 128. but going lower helped me too. I
would say a purist might have a problem with 64 but… it’s more
than good enough for me.

makes me wonder what happens if I put this patch inside a poly~ object.

I’m glad that we finally found a trade off. great news. I’ll
admit defeat. Sorry to anyone I pissed off.

-matt


November 20, 2006 | 7:21 am

matthew aidekman wrote:
> yeah mine were already at 128. but going lower helped me too. I
> would say a purist might have a problem with 64 but… it’s more than
> good enough for me.

Glad to hear that…

> I’m glad that we finally found a trade off. great news. I’ll admit
> defeat. Sorry to anyone I pissed off.

I believe this is an important discussion, its also about deeper
knowledge of the tool you are using. Specialized tools which concentrate
on one thing might seem to deal better with for example sample accurate
timing, but a general purpose tool like Max has to deal with all kinds
of trade-offs. All you need to tweak it, is there, but you usually need
some kind of hands on experience to be able to understand whats behind
the scene. You can’t put this easily into the manual. (It is in the
manual, but you might still not know what it means until you touch the
limits of your system and experiment with it.)

Within this process you also focus on your special needs. That way you
develop skills which let you better justify other tools as well. I’d
wonder if anybody who could hear the difference in timing with a setting
of 64 samples signal vector, would again compare Max to tools which had
been a kind of reference for good timing. It might be that they only
seemed so much better, and after the tweaking of Max they might be even
worse in comparison…

In principal all audio software is facing similar problems and they all
cook with water (don’t know if this german mot translates well to
english… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


November 20, 2006 | 11:02 am

I can’t resist: http://xkcd.com/c165.html

I promise I won’t post these links in at least three months, or maybe more?

best,
nesa


November 20, 2006 | 6:40 pm

> In principal all audio software is facing similar problems and they all
> cook with water (don’t know if this german mot translates well to
> english… ;-)

A friend of mine put it quite well: If you have a huge
rail yard with trains coming in and out at all hours of
the day and night at all kinds of different speeds, having
an engineer who insists on going exactly 40 MPH is pretty
dangerous – to himself and to everyone else. :-)


Viewing 70 posts - 1 through 70 (of 70 total)