issues with MSP timing


    Oct 02 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

    • Oct 06 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
    • Oct 06 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
    • Oct 06 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
    • Oct 07 2006 | 10:39 am
      And it's interesting to compare phasor with train ...
      David
    • Oct 07 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
    • Oct 08 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....
    • Oct 09 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.
    • Oct 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. >
    • Oct 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?
    • Oct 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
    • Oct 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...
    • Oct 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:
    • Oct 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
    • Oct 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.
    • Oct 10 2006 | 6:11 pm
      For more on the scheduler and event timing, please check out Joshua's article
      -A
    • Oct 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?
    • Oct 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.
    • Oct 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
    • Oct 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
    • Oct 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 > > ----------------------------------------------------
    • Oct 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
    • Oct 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 ----------------------------------------------------
    • Oct 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.
    • Oct 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.
    • Oct 11 2006 | 6:53 pm
      show us the ADSR simple patch that doesnt work.
      v a d e //
      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=- www.Axiom-Crux.net -=ili!ili=-
    • Oct 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.
    • Oct 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=- www.Axiom-Crux.net -=ili!ili=- >
    • Oct 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.
    • Oct 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:
    • Oct 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:
      Cheers, Eric
    • Oct 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
    • Oct 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...
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Oct 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
    • Oct 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
    • Oct 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
    • Oct 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.
    • Oct 15 2006 | 12:36 pm
    • Oct 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
    • Oct 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 ----------------------------------------------------
    • Oct 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
    • Oct 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...)
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Oct 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
    • Oct 18 2006 | 12:24 pm
      i sold a big nested for next loop to ZX computing magazine in 1982 for
    • Oct 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
    • Nov 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.
    • Nov 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:// www.cassiel.com
    • Nov 14 2006 | 6:51 pm
      That patch is a real eye opener. Thanks for posting it. Oh Max.....
      v a d e //
      www.vade.info abstrakt.vade.info
    • Nov 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
    • Nov 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
    • Nov 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:
      -Joshua
    • Nov 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.
      yes.
      -110
    • Nov 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
    • Nov 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
    • Nov 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.
    • Nov 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
    • Nov 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
    • Nov 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 > >
    • Nov 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):
      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.
    • Nov 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 >> >> >
    • Nov 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
    • Nov 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 >
    • Nov 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:// www.cassiel.com
    • Nov 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
    • Nov 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. :-)
    • Nov 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
    • Nov 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
    • Nov 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
    • Nov 20 2006 | 11:02 am
      I promise I won't post these links in at least three months, or maybe more?
      best, nesa
    • Nov 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. :-)