issues with MSP timing
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
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
> 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
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
And it's interesting to compare phasor with train ...
David
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
Quote: david stevens wrote on Sat, 07 October 2006 03:39
----------------------------------------------------
> And it's interesting to compare phasor with train ...
>
> David
>
More like depressing....
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.
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.
>
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?
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
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...
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:
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
Quote: mattijs@samplemadness.nl wrote on Tue, 10 October 2006 19:44
> Reaktor turns all cpu off!
Eh.. cpu processing.
For more on the scheduler and event timing, please check out Joshua's article
-A
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?
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.
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
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
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
>
>
----------------------------------------------------
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
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
----------------------------------------------------
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.
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.
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=-
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.
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=-
>
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.
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:
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
>
> 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
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
(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
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
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
> 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.
>
> > 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
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
----------------------------------------------------
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
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
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
i sold a big nested for next loop to ZX computing magazine in 1982 for
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
> 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.
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
That patch is a real eye opener. Thanks for posting it. Oh Max.....
v a d e //
www.vade.info
abstrakt.vade.info
> 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
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
> 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
> 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
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
> 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
>> 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.
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
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
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
>
>
> 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.
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
>>
>>
>
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
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
>
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
> 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
> 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. :-)
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
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
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
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
> 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. :-)