Mattijs

Seeing the recent fuzz about sequencers and timing accuracy on this forum; here is a very very simple sequencer made out of very very basic max objects.

I guess it can be useful as an illustration of how a sequencer works.

http://www.arttech.nl/basic-sequencer.zip

Furthermore: is there a timing problem with this sequencer?

http://www.arttech.nl/basic-sequencer.zip
Just enable Play.

sharing-is-fun-basic-sequencer

Mind you, since you made it easy to load many duplicate events, you might try loading up multiple copies of all of them. If you give it 4 or 5 copies of each event, and let it play for a while, you'll probably see/hear what people are talking about. Every once in a while you get pronounced flamming between parts. The flams vary from just funky phasing, to outright flams. Which attack in the flam is the right one? Which one's on time?

This is on a PPC G5 dual 1.8, os x 10.4.9, max 4.6.3. Maybe it's my machine, but I'm not exactly running a centris 660av anymore! ;-)

Mind you, since you made it easy to load many duplicate events, you might try loading up multiple copies of all of them. If you give it 4 or 5 copies of each event, and let it play for a while, you'll probably see/hear what people are talking about. Every once in a while you get pronounced flamming between parts. The flams vary from just funky phasing, to outright flams. Which attack in the flam is the right one? Which one's on time? 

Quote: jbm wrote on Thu, 14 June 2007 16:05

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

> Mind you, since you made it easy to load many duplicate events, you might try loading up multiple copies of all of them. If you give it 4 or 5 copies of each event, and let it play for a while, you'll probably see/hear what people are talking about. Every once in a while you get pronounced flamming between parts. The flams vary from just funky phasing, to outright flams. Which attack in the flam is the right one? Which one's on time?

But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.

Let's for a moment assume you won't add two equal events on the same position.

> This is on a PPC G5 dual 1.8, os x 10.4.9, max 4.6.3. Maybe it's my machine, but I'm not exactly running a centris 660av anymore! ;-)

If you only enable Play after starting the patch (without adding any more events) there is no problem, right?

Quote: jbm wrote on Thu, 14 June 2007 16:05
----------------------------------------------------
> That's a nice model!

>
> Mind you, since you made it easy to load many duplicate events, you might try loading up multiple copies of all of them. If you give it 4 or 5 copies of each event, and let it play for a while, you'll probably see/hear what people are talking about. Every once in a while you get pronounced flamming between parts. The flams vary from just funky phasing, to outright flams. Which attack in the flam is the right one? Which one's on time? 

Let's for a moment assume you won't add two equal events on the same position. 

> But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.

hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get the same effect adding two or more notes on top of one another in Logic. If you did, they wouldn't have sold many copies. I only did this to show the fact that the timing problems that I think people generally complain about aren't really timing, per se, but are scheduling problems. That's where timing problems seem to come from, and Max seems to be really sensitive in this regard.

> Let's for a moment assume you won't add two equal events on the same position. 

Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords. If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.

As always, I'm open to being proven wrong...

>
>
> But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.
>

> Let's for a moment assume you won't add two equal events on the same position. 
>

Mind that in this patch the events are loaded with a loadbang. Don't load them yourself. If I load the patch and do nothing but enable dsp and then press Play I get a very straight little beat loop and I don't experience timing/phasing/flamming problems in any form.

So I'm curious what you might be meaning. Is there a chance you could record what you hear and post it on the forum?

I'm so keen on this because I have the strong feeling we can make a strong statement towards this ongoing timing discussion by providing examples like the patch I posted.

Btw I just saw I forgot to connect the clear bang properly. I updated the link: 

Quote: jbm wrote on Thu, 14 June 2007 16:24

> > But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.

> hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get the same effect adding two or more notes on top of one another in Logic. If you did, they wouldn't have sold many copies. I only did this to show the fact that the timing problems that I think people generally complain about aren't really timing, per se, but are scheduling problems. That's where timing problems seem to come from, and Max seems to be really sensitive in this regard.

> > Let's for a moment assume you won't add two equal events on the same position. 

> Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords. If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.

> As always, I'm open to being proven wrong...

Mind that in this patch the events are loaded with a loadbang. Don't load them yourself. If I load the patch and do nothing but enable dsp and then press Play I get a very straight little beat loop and I don't experience timing/phasing/flamming problems in any form. 

So I'm curious what you might be meaning. Is there a chance you could record what you hear and post it on the forum? 

Btw I just saw I forgot to connect the clear bang properly. I updated the link: http://www.arttech.nl/basic-sequencer.zip

Quote: jbm wrote on Thu, 14 June 2007 16:24
----------------------------------------------------
> >
> > But wait, that has nothing to do with timing. That is about trying to play equal events multiple times at once. If you add two notes on top of each other in Logic you get the same effect.
> >
>
> hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get the same effect adding two or more notes on top of one another in Logic. If you did, they wouldn't have sold many copies. I only did this to show the fact that the timing problems that I think people generally complain about aren't really timing, per se, but are scheduling problems. That's where timing problems seem to come from, and Max seems to be really sensitive in this regard.
>
> > Let's for a moment assume you won't add two equal events on the same position. 
> >
>
> Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords. If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.
>
> As always, I'm open to being proven wrong...
>
> J.
>
>
>
>
----------------------------------------------------


On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?

> Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords.

Note, I was talking about two -equal- events on the same position. So chords and multiple tracks are no problem since these events are different, even though they might be triggered at the same time. In my example hihats are triggered simultaneously with bassdrums.

> If you let it play for a while, you'll see what I mean. Sometimes you get a full-on flam. That is, I think, what gets people all wound-up about timing problems and the scheduler.

Ok, I believe you're taking two steps at a time here where you shouldn't.

1) there are flams after you added the events to the sequencer multiple times -> This is expected behaviour since in that case two or more bassdrums will be sequenced to be triggered at the same time.

2) people get wound-up about timing problems and the scheduler. -> I don't think the flams have anything to do with timing or the scheduler, as mentioned above. The reason -I- think people get wound-up about timing and scheduler problems is because they don't understand how those systems work. Which we can't expect them to because there is no proper documentation about this for non-software-engineers. This patch is meant as an illustration how to use max correctly in case you want to build a sequencer.

Quote: jbm wrote on Thu, 14 June 2007 16:24
----------------------------------------------------
> > Let's for a moment assume you won't add two equal events on the same position. 
> >
>
> Fair enough. But if we're running more than one track, chances are we'll have multiple events on the same position. What about a chord, for example? Or, heaven forbid, two chords. 

So 
1) there are flams after you added the events to the sequencer multiple times -> This is expected behaviour since in that case two or more bassdrums will be sequenced to be triggered at the same time.

>
> As always, I'm open to being proven wrong...
>
> J.
>
>
>
>
----------------------------------------------------


Quote: Mattijs wrote on Thu, 14 June 2007 16:28

> On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?

Well, I added them accidentally at first, then started messing around with that. I realize it may not have been exactly "fair" to do that, as the patch is clearly not made with that sort of polyphony in mind... But I thought it was interesting, and symptomatic of the sorts of problems people talk about, that it did start phasing and flamming. I mean, it's common practice to define a chord, in midi, as a series of pitches sent at (essentially) the same time.

Anyway, yes, for the most part, I deliberately loaded multiple events. gulp... I realize that the flamming problems may have been more related to the little sampler's monophonic design, than to any problems with timing.

Quote: Mattijs wrote on Thu, 14 June 2007 16:28
----------------------------------------------------
> On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?
>

Either way, I ran it for about 2 minutes with only single events loaded. It didn't flam, but it did drop a number of events altogether. I recorded the output with an sfrecord~. Maybe I can post it on my site and send you a link.

I'm going to make a version of this using 4 instances of your basic patch, with one start toggle, just to see if the flamming still occurs.

Either way, I ran it for about 2 minutes with only single events loaded. It didn't flam, but it did drop a number of events altogether. I recorded the output with an sfrecord~. Maybe I can post it on my site and send you a link. 

Quote: jbm wrote on Thu, 14 June 2007 17:39

> Quote: Mattijs wrote on Thu, 14 June 2007 16:28

> ----------------------------------------------------

> > On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?

> Well, I added them accidentally at first, then started messing around with that. I realize it may not have been exactly "fair" to do that, as the patch is clearly not made with that sort of polyphony in mind...

> But I thought it was interesting, and symptomatic of the sorts of problems people talk about, that it did start phasing and flamming.

Perhaps, but for the moment let's try to seperate the ambiguity about timing and sequencing from other possible problems people may have.

> I mean, it's common practice to define a chord, in midi, as a series of pitches sent at (essentially) the same time.

Yes, but again, even though a chord may consist of multiple events defined at the same time, these are not -equal- events. A chord is built with events that differ in pitch.

In my example events are indeed played at the same time: hihats, snares and bassdrums. They are played by a deliberately simple monophonic drum sampler. As you said, it requires a polyphonic engine to play a chord, but there is no restriction to playing a chord as far as the sequencer is concerned.

> Anyway, yes, for the most part, I deliberately loaded multiple events. gulp... I realize that the flamming problems may have been more related to the little sampler's monophonic design, than to any problems with timing.

Thanks a lot for confirming. This is important because in fact I am hoping to refer to this patch from now on whenever someone starts another topic about perceived inherent timing flaws in Max.

Any additions are of course welcome. This includes changes to the interface that could lower the risk of possible user mistakes such as adding multiple copies of events ;)

Quote: jbm wrote on Thu, 14 June 2007 17:39
----------------------------------------------------
> Quote: Mattijs wrote on Thu, 14 June 2007 16:28
> ----------------------------------------------------
> > On second thought I might have interpreted your post incorrectly. Did you mean you added the events multiple times on purpose?
> >
>
> Well, I added them accidentally at first, then started messing around with that. I realize it may not have been exactly "fair" to do that, as the patch is clearly not made with that sort of polyphony in mind... 

> But I thought it was interesting, and symptomatic of the sorts of problems people talk about, that it did start phasing and flamming. 

Yes, but again, even though a chord may consist of multiple events defined at the same time, these are not -equal- events. A chord is built with events that differ in pitch. 

>
> Anyway, yes, for the most part, I deliberately loaded multiple events. gulp... I realize that the flamming problems may have been more related to the little sampler's monophonic design, than to any problems with timing.

Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.

oh, and btw, it's kind of a cool effect when they do start to wander! ;-)

Quote: jbm wrote on Thu, 14 June 2007 17:48

> Either way, I ran it for about 2 minutes with only single events loaded. It didn't flam, but it did drop a number of events altogether.

You are right about that. When I minimize/unlock patches and switch programs sometimes it happens that events are dropped. I am curious what that could be.

> I recorded the output with an sfrecord~. Maybe I can post it on my site and send you a link.

I think I already experienced what you mean. I'll look into the patch some more to see how this can be explained.

> I'm going to make a version of this using 4 instances of your basic patch, with one start toggle, just to see if the flamming still occurs.

Quote: jbm wrote on Thu, 14 June 2007 17:48
----------------------------------------------------
> Either way, I ran it for about 2 minutes with only single events loaded. It didn't flam, but it did drop a number of events altogether. 

You are right about that. When I minimize/unlock patches and switch programs sometimes it happens that events are dropped. I am curious what that could be. 

> I recorded the output with an sfrecord~. Maybe I can post it on my site and send you a link. 

>
> I'm going to make a version of this using 4 instances of your basic patch, with one start toggle, just to see if the flamming still occurs.

Ah, thanks. I'll check out your patch, I hope in a few more hours.

Quote: jbm wrote on Thu, 14 June 2007 18:04

> Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.

Quote: jbm wrote on Thu, 14 June 2007 18:04
----------------------------------------------------
> Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
>


Well personally I prefer a system to work flawlessly. If I want a cool effect I will program it myself. ;)

Quote: jbm wrote on Thu, 14 June 2007 18:07

> oh, and btw, it's kind of a cool effect when they do start to wander! ;-)

Quote: jbm wrote on Thu, 14 June 2007 18:07
----------------------------------------------------
> oh, and btw, it's kind of a cool effect when they do start to wander! ;-)
>
----------------------------------------------------


Quote: Mattijs wrote on Thu, 14 June 2007 17:20

> Well personally I prefer a system to work flawlessly. If I want a cool effect I will program it myself. ;)

It would be nice to get to the bottom of this, as this exchange has really exemplified some of my joys and frustrations with Max. 

Joy: being able to make simple, elegant, and functional music machines, like your little sequencer object. 

Frustration: that such nice, clean objects as yours can have problems scaling to larger environments, when used as abstractions.

Quote: Mattijs wrote on Thu, 14 June 2007 17:20
----------------------------------------------------
> Well personally I prefer a system to work flawlessly. If I want a cool effect I will program it myself. ;)
>

It would be nice to get to the bottom of this, as this exchange has really exemplified some of my joys and frustrations with Max. 
Joy: being able to make simple, elegant, and functional music machines, like your little sequencer object. 
Frustration: that such nice, clean objects as yours can have problems scaling to larger environments, when used as abstractions.

I tested your patch. Here is a recording of what happens when I play the sequence (overdrive enabled) and then start opening applications, browsing to heavy flash websites, etc, on a Powerbook G4 1.25.

http://www.arttech.nl/basic-sequencer-recording.aif

As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).

And then there are the moments that everything halts for a short moment, which I assume happens when the cpu is overloaded and can't be used by max for a short moment. Note that no events are dropped in such a case and no cumulative error occurs (something a lot of people complain about when using metro and counter).

Based on these results I'd say everything works as expected.

An interesting find regarding the dropping out of events: on the powerbook this problem doesn't occur! A few hours ago I was on a MacPro Quadcore where the dropouts occurred approximately once in a minute.

Could this have something to do with multiple cores (i.e. the dsp thread running on a separate processor)? Would you have the oppurtunity to do a test on a single-core computer?

Quote: jbm wrote on Thu, 14 June 2007 18:04
----------------------------------------------------
> Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
>

Based on these results I'd say everything works as expected. 

An interesting find regarding the dropping out of events: on the powerbook this problem doesn't occur! A few hours ago I was on a MacPro Quadcore where the dropouts occurred approximately once in a minute. 

cool patch, and i didnt expect it to be built that way!

i have to admit the thought never crossed my mind to use cpuclock and the time divisions as float for events.

but then again i'm not a software engineer... i tend to go for signal based clocks as i find them more reliable, especially past 1/32 divisions - which isn't that fast when doing intricate rhythms.

to illustrate the grudge i have with metro (or event scheduler?), see patch below. it doesnt seem to matter if i have overdrive on / off with metro. BTW, this is also on a dual core MBP.

sometimes i feel Max timing goes through a Logic humanise effect!

Quote: Mattijs wrote on Thu, 14 June 2007 19:37

> Quote: jbm wrote on Thu, 14 June 2007 18:04

> > Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.

> I tested your patch. Here is a recording of what happens when I play the sequence (overdrive enabled) and then start opening applications, browsing to heavy flash websites, etc, on a Powerbook G4 1.25.

> As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).

> And then there are the moments that everything halts for a short moment, which I assume happens when the cpu is overloaded and can't be used by max for a short moment. Note that no events are dropped in such a case and no cumulative error occurs (something a lot of people complain about when using metro and counter).

> Based on these results I'd say everything works as expected. 

> An interesting find regarding the dropping out of events: on the powerbook this problem doesn't occur! A few hours ago I was on a MacPro Quadcore where the dropouts occurred approximately once in a minute. 

> Could this have something to do with multiple cores (i.e. the dsp thread running on a separate processor)? Would you have the oppurtunity to do a test on a single-core computer?

This is actually very interesting, and a little disconcerting. I can't post my recording right now, but I'll post it tomorrow. My playback had pronounced flamming, which went in phases - and I would guess, coincidentally, that it happened around every minute. It would flam for 2 or 3 bars, then go back to normal for around a minute, then start flamming again. My machine is dual G5 - though not dual-core. What machine was your recording made on? I'm now *very* curious about this... I can try disabling one of my CPUs tomorrow in the CHUD tools as well, just to see if the periodic flamming goes away. I'll report back at some point tomorrow, and post my recording as well.

Quote: Mattijs wrote on Thu, 14 June 2007 19:37
----------------------------------------------------
> Quote: jbm wrote on Thu, 14 June 2007 18:04
> ----------------------------------------------------
> > Okay, so what I just did was to pull out the sampler, and give it a changeable argument, just to specify independent buffers. I made a patcher with 4 instances of your sequencer, with arguments for the buffers. The all start on the same toggle. The outputs feed into a stereo sfrecord~. I put two of the instances into the left channel and two into the right, so any timing problems would be really obvious. Basically, it does okay. When playback timing is really locked, the output is mono, dead centre. When it wavers the stereo channels really "pop" out. As I say, it didn't do too badly, but it's not stellar. And we're really not talking about sample-accuracy here. They flam, which means they're many ms apart.
> >
>
> I tested your patch. Here is a recording of what happens when I play the sequence (overdrive enabled) and then start opening applications, browsing to heavy flash websites, etc, on a Powerbook G4 1.25.
>
> http://www.arttech.nl/basic-sequencer-recording.aif
>
> As far as I can hear there is indeed some stereo/phasing-ish effect, but I can hear no flamming. So I'd say that there may be an error of 1 or 2 ms (in the range of phasing), but not around 30 ms (in the range of flamming).
>
> And then there are the moments that everything halts for a short moment, which I assume happens when the cpu is overloaded and can't be used by max for a short moment. Note that no events are dropped in such a case and no cumulative error occurs (something a lot of people complain about when using metro and counter).
>
> Based on these results I'd say everything works as expected. 
>
> An interesting find regarding the dropping out of events: on the powerbook this problem doesn't occur! A few hours ago I was on a MacPro Quadcore where the dropouts occurred approximately once in a minute. 
>
> Could this have something to do with multiple cores (i.e. the dsp thread running on a separate processor)? Would you have the oppurtunity to do a test on a single-core computer?
>
> Mattijs
----------------------------------------------------

Quote: justin wrote on Thu, 14 June 2007 21:13

> cool patch, and i didnt expect it to be built that way!

Thanks justin! For the record, I assume seq~ works exactly this way, the difference is that this allows for a look inside and can be educative in that aspect.

> i have to admit the thought never crossed my mind to use cpuclock and the time divisions as float for events.

> but then again i'm not a software engineer... i tend to go for signal based clocks as i find them more reliable, especially past 1/32 divisions - which isn't that fast when doing intricate rhythms.

> to illustrate the grudge i have with metro (or event scheduler?), see patch below. it doesnt seem to matter if i have overdrive on / off with metro. BTW, this is also on a dual core MBP.

> sometimes i feel Max timing goes through a Logic humanise effect!

I tested your patch and recorded a few seconds of audio at a subdivision of 32. On a powerbook G4. In the middle of the recording I switch from the metro output to the phasor output. I don't hear a difference.

http://www.arttech.nl/justin-recording.aif

Maybe you could also post a recording so that we can compare..

btw: a tip: you might have named the number boxes of the bpm and subdivision. Sending a loadmess with a functional value is also a pro.. One could be less tempted to try your patch if one had to guess what those number boxes are for. ;)

Quote: justin wrote on Thu, 14 June 2007 21:13
----------------------------------------------------
> cool patch, and i didnt expect it to be built that way!

>
> i have to admit the thought never crossed my mind to use cpuclock and the time divisions as float for events.
>
> but then again i'm not a software engineer... i tend to go for signal based clocks as i find them more reliable, especially past 1/32 divisions - which isn't that fast when doing intricate rhythms.
>
> to illustrate the grudge i have with metro (or event scheduler?), see patch below. it doesnt seem to matter if i have overdrive on / off with metro. BTW, this is also on a dual core MBP.
>
> sometimes i feel Max timing goes through a Logic humanise effect!

btw: a tip: you might have named the number boxes of the bpm and subdivision. Sending a loadmess with a functional value is also a pro.. One could be less tempted to try your patch if one had to guess what those number boxes are for. ;)


Getting something rather strange when I try to download the patch (updated

link) - it starts to download as 'basic-sequencer.zip', then changes into an

XL file called " staff_rota_wb_11.06.07_with_no_end_times.xls" !

Subsequent attempts to download it result in exactly the same behaviour,

with the original being overwritten, instead of the usual Safari behaviour

However, I can say that when I downloaded the original patch at work and

ran it, the timing was not good (Intel iMac 2GHz); no flamming, but obvious

timing glitches. Unfortunately I can't try it again here at home, for the

On 14/6/07 16:01, "Mattijs Kneppers" wrote:

> Mind that in this patch the events are loaded with a loadbang. Don't load them

> yourself. If I load the patch and do nothing but enable dsp and then press

> Play I get a very straight little beat loop and I don't experience

> timing/phasing/flamming problems in any form.

> So I'm curious what you might be meaning. Is there a chance you could record

> what you hear and post it on the forum?

> I'm so keen on this because I have the strong feeling we can make a strong

> statement towards this ongoing timing discussion by providing examples like

> Btw I just saw I forgot to connect the clear bang properly. I updated the

> Quote: jbm wrote on Thu, 14 June 2007 16:24

>>> But wait, that has nothing to do with timing. That is about trying to play

>>> equal events multiple times at once. If you add two notes on top of each

>>> other in Logic you get the same effect.

>> hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get

>> the same effect adding two or more notes on top of one another in Logic. If

>> you did, they wouldn't have sold many copies. I only did this to show the

>> fact that the timing problems that I think people generally complain about

>> aren't really timing, per se, but are scheduling problems. That's where

>> timing problems seem to come from, and Max seems to be really sensitive in

>>> Let's for a moment assume you won't add two equal events on the same

>> Fair enough. But if we're running more than one track, chances are we'll have

>> multiple events on the same position. What about a chord, for example? Or,

>> heaven forbid, two chords. If you let it play for a while, you'll see what I

>> mean. Sometimes you get a full-on flam. That is, I think, what gets people

>> all wound-up about timing problems and the scheduler.

>> As always, I'm open to being proven wrong...

Getting something rather strange when I try to download the patch (updated
link) - it starts to download as 'basic-sequencer.zip', then changes into an
XL file called " staff_rota_wb_11.06.07_with_no_end_times.xls" !
Subsequent attempts to download it result in exactly the same behaviour,
with the original being overwritten, instead of the usual Safari behaviour
of adding a '1' to the file name...
 However, I can say that when I downloaded the original patch at work and
ran it, the timing was not good (Intel iMac 2GHz); no flamming, but obvious
timing glitches. Unfortunately I can't try it again here at home, for the
reason above,
Cheers
Roger

On 14/6/07 16:01, "Mattijs Kneppers"  wrote:

>
> Mind that in this patch the events are loaded with a loadbang. Don't load them
> yourself. If I load the patch and do nothing but enable dsp and then press
> Play I get a very straight little beat loop and I don't experience
> timing/phasing/flamming problems in any form.
>
> So I'm curious what you might be meaning. Is there a chance you could record
> what you hear and post it on the forum?
>
> I'm so keen on this because I have the strong feeling we can make a strong
> statement towards this ongoing timing discussion by providing examples like
> the patch I posted.
>
> Mattijs
>
> Btw I just saw I forgot to connect the clear bang properly. I updated the
> link: http://www.arttech.nl/basic-sequencer.zip
>
> Quote: jbm wrote on Thu, 14 June 2007 16:24
> ----------------------------------------------------
>>>
>>> But wait, that has nothing to do with timing. That is about trying to play
>>> equal events multiple times at once. If you add two notes on top of each
>>> other in Logic you get the same effect.
>>>
>>
>> hehe... Sorry I had to be a pest. Mind you, I have to say that you don't get
>> the same effect adding two or more notes on top of one another in Logic. If
>> you did, they wouldn't have sold many copies. I only did this to show the
>> fact that the timing problems that I think people generally complain about
>> aren't really timing, per se, but are scheduling problems. That's where
>> timing problems seem to come from, and Max seems to be really sensitive in
>> this regard.
>>
>>> Let's for a moment assume you won't add two equal events on the same
>>> position. 
>>>
>>
>> Fair enough. But if we're running more than one track, chances are we'll have
>> multiple events on the same position. What about a chord, for example? Or,
>> heaven forbid, two chords. If you let it play for a while, you'll see what I
>> mean. Sometimes you get a full-on flam. That is, I think, what gets people
>> all wound-up about timing problems and the scheduler.
>>
>> As always, I'm open to being proven wrong...
>>
>> J.
>>
>>
>>
>>
> ----------------------------------------------------
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling

That seems pretty weird indeed. My recordings were done on a powerbook G4 1.25 GHz (1 processor) with MaxMSP 4.6.2 with overdrive on and default dsp settings (I/O vector size 512, signal vector size 64, scheduler in audio interrupt off)

My guess was there could be a relation between the dropping out of events and multiple cores. But not between multiple cores and periodic flamming..

Quote: jbm wrote on Thu, 14 June 2007 21:38

> This is actually very interesting, and a little disconcerting. I can't post my recording right now, but I'll post it tomorrow. My playback had pronounced flamming, which went in phases - and I would guess, coincidentally, that it happened around every minute. It would flam for 2 or 3 bars, then go back to normal for around a minute, then start flamming again. My machine is dual G5 - though not dual-core. What machine was your recording made on? I'm now *very* curious about this... I can try disabling one of my CPUs tomorrow in the CHUD tools as well, just to see if the periodic flamming goes away. I'll report back at some point tomorrow, and post my recording as well.

Quote: jbm wrote on Thu, 14 June 2007 21:38
----------------------------------------------------
> This is actually very interesting, and a little disconcerting. I can't post my recording right now, but I'll post it tomorrow. My playback had pronounced flamming, which went in phases - and I would guess, coincidentally, that it happened around every minute. It would flam for 2 or 3 bars, then go back to normal for around a minute, then start flamming again. My machine is dual G5 - though not dual-core. What machine was your recording made on? I'm now *very* curious about this... I can try disabling one of my CPUs tomorrow in the CHUD tools as well, just to see if the periodic flamming goes away. I'll report back at some point tomorrow, and post my recording as well.
>
> cheers,
>
> J.
>
----------------------------------------------------


Quote: roger.carruthers wrote on Thu, 14 June 2007 21:57

> Getting something rather strange when I try to download the patch (updated

> link) - it starts to download as 'basic-sequencer.zip', then changes into an

> XL file called " staff_rota_wb_11.06.07_with_no_end_times.xls" !

> Subsequent attempts to download it result in exactly the same behaviour,

> with the original being overwritten, instead of the usual Safari behaviour

> However, I can say that when I downloaded the original patch at work and

> ran it, the timing was not good (Intel iMac 2GHz); no flamming, but obvious

The question is: did this timing glitches occur without your cpu being busy with other stuff? When the cpu is at 100% it is quite normal that timing glitches will occur.

> Unfortunately I can't try it again here at home, for the

Quote: roger.carruthers wrote on Thu, 14 June 2007 21:57
----------------------------------------------------
> Getting something rather strange when I try to download the patch (updated
> link) - it starts to download as 'basic-sequencer.zip', then changes into an
> XL file called " staff_rota_wb_11.06.07_with_no_end_times.xls" !
> Subsequent attempts to download it result in exactly the same behaviour,
> with the original being overwritten, instead of the usual Safari behaviour
> of adding a '1' to the file name...
>  However, I can say that when I downloaded the original patch at work and
> ran it, the timing was not good (Intel iMac 2GHz); no flamming, but obvious
> timing glitches. 

> Unfortunately I can't try it again here at home, for the
> reason above,
> Cheers
> Roger
>
>
>


Scrub that: /everything/ I tried to download with Safari after that came out

as the mystery XL file until I quit & reopened Safari! Bizarre...

[sharing is fun] basic sequencer