Talking 'bout tightness

Mar 7, 2007 at 8:55am

Talking 'bout tightness

As a musician one would like a sound system to be tight, as in sample TIGHT.
For instance, if i go ahead an recorded, say my little max/msp drummacine output, i would expect it to be TIGHT, if the samples were played with the same interval in samples over and over again. Noting less!

Now that i am beginning to design my system, I don’t really know whether I’ll face a problem or not.

But I see people talking bout the metro object not being tight. Is that really true?

What tightness-issues should i keep in mind when designing my system?
Should i do a lot of prep work with buffers, or should i just trigger playing/recording based on metro or alike.

I am trynig to build a audio loop system of audio buffers for sync recording and loop playback.
Theese can have diffent lenghts but cannot “slide” out of synch with each other. Also a simple drum machine is running, playing oneshot samples.

#30667
Mar 7, 2007 at 9:31am

I can’t give you all the answers, but can relate specific experience:

I work with my own loop-player which is based on [stutter] objects, which are basically two buffers configured to work together. The first buffer acts as a constant record of what has been played (or not played) during the last x miliseconds. The second can be told to grab a part of the first buffer and repeat it. The playback speed and position is controlled by a [phasor] object, as is common for [stutter]. This constantly goes from 0 to 1. Now, the (samplerate / number of samples)*playbackspeed (where 1. is normal playbackspeed) will cause the [phasor] to complete its ramp in the same number of samples as the playback buffer.
Since I needed to sync the playback with other routines, including MIDI, I needed a bang at the beginning of the cycle. I did this by connecting two objects to the output of the [phasor]: ->[>=~ 0.98]->[edge~]
There may be another way, but since this works fine for me, I didn’t look any further (yet). I also set the Max scheduler to audio interrupt (DSP Status).
All of the [stutter] objects have their own [phasor] objects, but the frequency of each is quantized beforehand in relation to the first frequency. For instance, if I record the first “master” loop and it turns out to be almost one second long, but not quite (let’s say 44099 samples) but I have my quantization set to allow half-notes, then the first loop is bumped up to a rounded-off value of half of the number of samples (round(44099/2))*2. This assures synchronized lengths. Even if the beginning of the [phasor] cycle is off by a few samples, you won’t hear it, and this displacement will remain constant.
I have never needed to use more than six audio loops at a time, and I commonly use the looping function for no more than two or three minutes before starting new loops, usually not more than one minute, so I cannot empirically say that it is perfectly in sync. The few times that I have left it looping for ten minutes and more, however, it was still in sync. Also, using it with Jitter-loops in real-time performance processing, it has stayed in sync with itself, MIDI and the frame-rate of the video for five or six minutes at a time during all performances and rehearsals.

#98380
Mar 7, 2007 at 9:58am

Max is perfectly capable of playing loops very tightly synced.

But in some cases you have to be aware of a few in-depth technical ‘details’ about how max works internally. The whole metro issue is about knowing what you’re doing. I am afraid to really know what you’re doing you’ll have to read this carefully:

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

I’d say, first try to make your setup based on what you know from the tutorials and manuals, 90% chance that you’ll succeed. If you get sync problems read the article and then post your patch on this forum so that ppl can point you in the right direction.

Good luck,
Mattijs

Quote: McSkelle wrote on Wed, 07 March 2007 09:55
—————————————————-
> As a musician one would like a sound system to be tight, as in sample TIGHT.
> For instance, if i go ahead an recorded, say my little max/msp drummacine output, i would expect it to be TIGHT, if the samples were played with the same interval in samples over and over again. Noting less!
>
> Now that i am beginning to design my system, I don’t really know whether I’ll face a problem or not.
>
> But I see people talking bout the metro object not being tight. Is that really true?
>
> What tightness-issues should i keep in mind when designing my system?
> Should i do a lot of prep work with buffers, or should i just trigger playing/recording based on metro or alike.
>
> –
>
> I am trynig to build a audio loop system of audio buffers for sync recording and loop playback.
> Theese can have diffent lenghts but cannot “slide” out of synch with each other. Also a simple drum machine is running, playing oneshot samples.
>
—————————————————-

#98381
Mar 7, 2007 at 10:37am

its all right what Mattijs said but i want to add something
which looks like the opposite to it.

if you use metro, you are using a message system.

2 messages (bang) coming out of metro, connected to 2
somethings, will NEVER arrive at their aims at the same time.

2 samples (for example an “1.” sample, a click),
will ALWAYS arrive at the same time when connected to 2
aims. (or to be exact, _within the same sample)

so the more time accuracy you want, the more you should try
to build everything in DSP.
messages might be faster (1 sample lasts 1/44100 second) but
messages are impossible to sync to each other.

there are 2 problems with using only signals:

• DSP significantly uses more CPU than messages (if the data
amount to be transferred is low, like using signal clicks as
metro replacement)

• there are quite a few audio objects which simply do
not take signals; you cant start sfplay~ using a signal
for example.

now have some coffee, look at your objects library again,
and choose wisely.

:)

-110

#98382
Mar 7, 2007 at 10:58am

Looking back at my archives I found this test, which is just a visualisation of what R. T. just wrote. Try changing the on/off settings for overdrive and audio interrupt scheduler while using it.

max v2;
#N vpatcher 15 55 615 524;
#P window setfont “Sans Serif” 10.;
#P flonum 327 292 95 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 327 254 32 9109514 timer;
#P message 272 95 17 9109514 0.;
#P button 272 71 15 0;
#P button 253 210 15 0;
#P button 225 210 15 0;
#P newex 225 180 38 9109514 edge~;
#P newex 225 148 57 9109514 >=~ 0.58;
#P newex 225 118 57 9109514 phasor~ 1.;
#P user number~ 150 373 236 389 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 150 337 27 9109514 -~;
#P flonum 119 290 95 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 119 252 32 9109514 timer;
#P message 113 95 17 9109514 0.;
#P button 113 71 15 0;
#P toggle 156 30 15 0;
#P newex 405 117 62 9109514 metro 1000;
#P button 94 210 15 0;
#P button 66 210 15 0;
#P newex 66 180 38 9109514 edge~;
#P newex 66 148 44 9109514 >=~ 0.58;
#P newex 66 118 57 9109514 phasor~ 1.;
#P user ezdac~ 18 43 62 76 0;
#P window linecount 3;
#P comment 177 242 100 9109514 ms difference between bang outputs from [edge];
#P window linecount 4;
#P comment 362 236 100 9109514 ms difference between bang output from [edge] and [metro];
#P window linecount 2;
#P comment 182 338 100 9109514 actual difference between signals;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 7 0;
#P connect 6 1 8 0;
#P fasten 10 0 11 0 161 55 118 55;
#P connect 11 0 12 0;
#P connect 12 0 4 1;
#P fasten 8 0 13 0 99 234 124 234;
#P connect 13 0 14 0;
#P fasten 21 0 13 1 258 233 146 233;
#P fasten 4 0 15 0 71 143 47 143 47 317 155 317;
#P connect 15 0 16 0;
#P fasten 17 0 15 1 230 143 172 143;
#P connect 17 0 18 0;
#P connect 18 0 19 0;
#P connect 19 0 20 0;
#P connect 19 1 21 0;
#P fasten 10 0 22 0 161 55 277 55;
#P connect 22 0 23 0;
#P connect 23 0 17 1;
#P fasten 21 0 24 0 258 233 332 233;
#P connect 24 0 25 0;
#P fasten 9 0 24 1 410 232 354 232;
#P fasten 10 0 9 0 161 55 410 55;
#P pop;

#98383
Mar 7, 2007 at 11:01am

>
>But I see people talking bout the metro object not being tight. Is
>that really true?
>

it is SO true…….

that i came to think it is a running gag at C74 office… “hey,
let’s make the metro even sloppier!!!!”

(yes i know the usual answers are about us, users, not understanding
what the OS does – and this is true, i don’t – but all
sequencers/apps I know have a working metro-like tightness… well,
ok….)

best

kasper

#98384
Mar 7, 2007 at 11:34am

Quote: Kasper T Toeplitz wrote on Wed, 07 March 2007 12:01
—————————————————-
> >
> >But I see people talking bout the metro object not being tight. Is
> >that really true?
> >
>
>
> it is SO true…….
>
> that i came to think it is a running gag at C74 office… “hey,
> let’s make the metro even sloppier!!!!”

I really wouldn’t say these kind of things if you’re obviously not a dsp/multithreading programmer.. Your remarks should be aimed towards the documentation or the learning curve, not the application.

>
> (yes i know the usual answers are about us, users, not understanding
> what the OS does – and this is true, i don’t – but all
> sequencers/apps I know have a working metro-like tightness… well,
> ok….)

I agree with you about this. Users shouldn’t be blamed that they don’t understand. I think cycling is obliged to

a) add a chapter to the max fundamentals that explains exactly how to use metro (and threading) and how not to, with overly clear examples,
-or-
b) open the description of max with “max is a graphic programming language with a huge standard library for event handling, audio processing and communication with hardware”. System requirements: “a bachelors degree in technical engineering or a lot of luck”.

Mattijs

#98385
Mar 7, 2007 at 11:40am

If we could bundle this test with a few others, together with clear and simple clarifications and finally notes and examples how to approach possible issues in the correct way, we’d have a real solution for the everlasting ‘metro’ misunderstanding.

Mattijs

Quote: Dayton wrote on Wed, 07 March 2007 11:58
—————————————————-
> Looking back at my archives I found this test, which is just a visualisation of what R. T. just wrote. Try changing the on/off settings for overdrive and audio interrupt scheduler while using it.
>
> max v2;
> #N vpatcher 15 55 615 524;
> #P window setfont “Sans Serif” 10.;
> #P flonum 327 292 95 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P newex 327 254 32 9109514 timer;
> #P message 272 95 17 9109514 0.;
> #P button 272 71 15 0;
> #P button 253 210 15 0;
> #P button 225 210 15 0;
> #P newex 225 180 38 9109514 edge~;
> #P newex 225 148 57 9109514 >=~ 0.58;
> #P newex 225 118 57 9109514 phasor~ 1.;
> #P user number~ 150 373 236 389 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 150 337 27 9109514 -~;
> #P flonum 119 290 95 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 119 252 32 9109514 timer;
> #P message 113 95 17 9109514 0.;
> #P button 113 71 15 0;
> #P toggle 156 30 15 0;
> #P newex 405 117 62 9109514 metro 1000;
> #P button 94 210 15 0;
> #P button 66 210 15 0;
> #P newex 66 180 38 9109514 edge~;
> #P newex 66 148 44 9109514 >=~ 0.58;
> #P newex 66 118 57 9109514 phasor~ 1.;
> #P user ezdac~ 18 43 62 76 0;
> #P window linecount 3;
> #P comment 177 242 100 9109514 ms difference between bang outputs from [edge];
> #P window linecount 4;
> #P comment 362 236 100 9109514 ms difference between bang output from [edge] and [metro];
> #P window linecount 2;
> #P comment 182 338 100 9109514 actual difference between signals;
> #P connect 4 0 5 0;
> #P connect 5 0 6 0;
> #P connect 6 0 7 0;
> #P connect 6 1 8 0;
> #P fasten 10 0 11 0 161 55 118 55;
> #P connect 11 0 12 0;
> #P connect 12 0 4 1;
> #P fasten 8 0 13 0 99 234 124 234;
> #P connect 13 0 14 0;
> #P fasten 21 0 13 1 258 233 146 233;
> #P fasten 4 0 15 0 71 143 47 143 47 317 155 317;
> #P connect 15 0 16 0;
> #P fasten 17 0 15 1 230 143 172 143;
> #P connect 17 0 18 0;
> #P connect 18 0 19 0;
> #P connect 19 0 20 0;
> #P connect 19 1 21 0;
> #P fasten 10 0 22 0 161 55 277 55;
> #P connect 22 0 23 0;
> #P connect 23 0 17 1;
> #P fasten 21 0 24 0 258 233 332 233;
> #P connect 24 0 25 0;
> #P fasten 9 0 24 1 410 232 354 232;
> #P fasten 10 0 9 0 161 55 410 55;
> #P pop;
>
—————————————————-

#98386
Mar 7, 2007 at 11:54am

>Quote: Kasper T Toeplitz wrote on Wed, 07 March 2007 12:01
>—————————————————-
>> >
>> >But I see people talking bout the metro object not being tight. Is
>> >that really true?
>> >
>>
>>
>> it is SO true…….
>>
>> that i came to think it is a running gag at C74 office… “hey,
>> let’s make the metro even sloppier!!!!”
>
>I really wouldn’t say these kind of things if you’re obviously not a
>dsp/multithreading programmer.. Your remarks should be aimed towards
>the documentation or the learning curve, not the application.
>

ok

it was a joke see. like in ;-)

i really think it i s _funny_ that maxmsp – a brillant program that i
use almost daily – does not have a tight “metro”.

I don’t blame the learning curve, the doc or wahtever

if you read what metro i supposed to do, and then you create a [metro
1000] object you expect it to bang every second, right?? kind like
when i look at the time counter in ProTools, when it says my music is
played since XX:xx time, i kind of trust it. I mean it says so and i
belive it is true.
when i ask a metro to bang every second, i – now – know it bangs when
it can which is very often evey 1000-1300 miliseconds

i might be wrong, but i never read anywhere in the metro’s doc that
if you want to output a bang every xx miliseconds you shoul NOT use
metro but go into the audio (msp) domain.

not being a dsp/multithreading programmer does not change much
here…. i just expected the objects to work as explained. Took me
time to understand it is not the case (i never trust a time counter
based on matro anymore…)

best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart

#98387
Mar 7, 2007 at 12:20pm

Wauuu…a lot of tough reading for me to do here.
I’m not sure i understand the “domain” discussion.

If i make a groove object to loop every second, would i then have made a DSP domain metro running 60 bpm?

I’m eager to move on and try the above sample code. Thanks :-) !
Any looper/overdub/sound-on-sound pathers would be greatly appriciated. I AM a beginner with max/msp.
On the other hand i am a muscician – not trying to be a programmer at all. I play with computers all right, but really I feel I shoud play my guitar instead;-)

I think the max’er community is ready to be used by “classic” muscician types like my self. Not a dj, not a coding laptop artist, just a guy playing what have you, but wanting too “team up” with some tech to reach greater ground.

thanks again all – i’m still reading your posts to understand things better:-)

#98388
Mar 7, 2007 at 12:45pm

Quote: McSkelle wrote on Wed, 07 March 2007 05:20

> If i make a groove object to loop every second, would i then have made a DSP domain metro running 60 bpm?

actually no… if you start the groove at the same time as any other groove, it will stay in sync. I put a “resync” button which uses the [edge] technique above to resync all phasors at once, but I never had to use it (it comes in handy if I am making music with loops which have varying lengths, however.) It is useful with MIDI and video. MIDI needs to be fairly synchronized (within its own latency-jitter), but video is a bit more forgiving.

> I think the max’er community is ready to be used by “classic” muscician types like my self. Not a dj, not a coding laptop artist, just a guy playing what have you, but wanting too “team up” with some tech to reach greater ground.
>

Definitely. I program, but am and always was a musician first and formost. Programming is never an end in and of itself; it is always at the service of some specific work to be done. Still, as was pointed out to me a while ago, this forum is dedicated almost exclusively at the technical aspects of art and needs to be so in order to be effective.

#98389
Mar 7, 2007 at 1:26pm

Quote: Dayton wrote on Wed, 07 March 2007 13:45
—————————————————-
> Quote: McSkelle wrote on Wed, 07 March 2007 05:20
>
> > If i make a groove object to loop every second, would i then have made a DSP domain metro running 60 bpm?
>
> actually no… if you start the groove at the same time as any other groove, it will stay in sync. I put a “resync” button which uses the [edge] technique above to resync all phasors at once, but I never had to use it (it comes in handy if I am making music with loops which have varying lengths, however.) It is useful with MIDI and video. MIDI needs to be fairly synchronized (within its own latency-jitter), but video is a bit more forgiving.

The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.

>
> > I think the max’er community is ready to be used by “classic” muscician types like my self. Not a dj, not a coding laptop artist, just a guy playing what have you, but wanting too “team up” with some tech to reach greater ground.
> >
>
>
> Definitely. I program, but am and always was a musician first and formost. Programming is never an end in and of itself; it is always at the service of some specific work to be done. Still, as was pointed out to me a while ago, this forum is dedicated almost exclusively at the technical aspects of art and needs to be so in order to be effective.
>
—————————————————-

#98390
Mar 7, 2007 at 1:38pm

one should never exspect a [metro 1000] to output a
bang every 1000.000000000000000 milliseconds.

but what makes some of us rather sad is that you can
sometimes, even with overdrive on, not produce musically
usable 1/32. or 1/64 notes with it.

and phasor~ … how many posts have there been this month
abolut how to reset phasors phase ? :)

#98391
Mar 7, 2007 at 2:03pm

>one should never exspect a [metro 1000] to output a
>bang every 1000.000000000000000 milliseconds.
>

oh, if it would stay in a 1000 – 1010 range i would be happy!!!

with working patches (audio ok, no cliks etc) i am more often in the
1000-1300 range!

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart

#98392
Mar 7, 2007 at 2:07pm

Quote: Mattijs wrote on Wed, 07 March 2007 06:26
—————————————————-

> The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.

—————————————————-

Yes, but that would preclude any possibility of pitch-bending and/or phase-shifting the individual loops, which is one of the reasons I got into Max/MSP in the first place.
My abstraction wish-list for the looping patch tried to include all forseeable musical situations. I’m sure it didn’t, but I try. Usually, half of the stuff in my patches end up in the catagory “I don’t need this now, but I might someday…”

#98393
Mar 7, 2007 at 2:27pm

#98394
Mar 7, 2007 at 2:38pm

On 7 mars 07, at 15:03, Kasper T Toeplitz wrote:

>> one should never exspect a [metro 1000] to output a
>> bang every 1000.000000000000000 milliseconds.
>
> with working patches (audio ok, no cliks etc) i am more often in the
> 1000-1300 range!

Now I understrand why your pieces are sooo long ;-)

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://users.skynet.be/crfmw/max

#98395
Mar 7, 2007 at 2:42pm

Quote: Dayton wrote on Wed, 07 March 2007 15:07
—————————————————-
> Quote: Mattijs wrote on Wed, 07 March 2007 06:26
> —————————————————-
>
> > The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.
>
> —————————————————-
>
> Yes, but that would preclude any possibility of pitch-bending and/or phase-shifting the individual loops, which is one of the reasons I got into Max/MSP in the first place.

Why?
Phase shifting:

#P user number~ 148 173 187 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 148 152 37 196617 %~ 1.;
#P user number~ 91 173 130 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 148 132 40 196617 +~ 0.5;
#P newex 91 105 46 196617 phasor~;
#P connect 0 0 2 0;
#P connect 0 0 1 0;
#P connect 3 0 4 0;
#P connect 1 0 3 0;

Pitch bending:

#P user number~ 357 173 396 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 300 173 339 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 357 132 40 196617 /~ 0.5;
#P newex 300 105 46 196617 phasor~;
#P connect 1 0 3 0;
#P connect 0 0 2 0;
#P connect 0 0 1 0;

Everything you want can be done without any syncing problems, believe me. You just need to know how. But as I agreed, the docs are inadequate in some cases if you don’t have a technical background.

Mattijs

#98396
Mar 7, 2007 at 3:26pm

and another option is to look at eric lyon’s (3rd party) sample accurate object “samm~” available here:

http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/

havent had time to test this thoroughly but it looks interesting!

j

#98397
Mar 7, 2007 at 3:30pm

Quote: Roman Thilenius wrote on Wed, 07 March 2007 14:38
—————————————————-
>
>
> one should never exspect a [metro 1000] to output a
> bang every 1000.000000000000000 milliseconds.
>
> but what makes some of us rather sad is that you can
> sometimes, even with overdrive on, not produce musically
> usable 1/32. or 1/64 notes with it.

1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms. That’s very well possible considering that the scheduler event interval is 2 ms by default. But now we’re entering the general making-music-with-computers discussion. I suppose a multithreaded OS will always have problems when we’re in this time range, that’s probably why the amiga trackers and cubase for atari are still famous for their tightness among trained listeners.

The only improvement I can imagine is that the high priority queue (= scheduler) always seems to serviced with a minimum interval. Perhaps cycling 74 could change this system so that it will be serviced as often as possible, with a maximum interval of 2 ms, as long as processor power permits. But to say anything sensible about that I would need a look at the source code and I don’t think cycling would let me :’|

But all this is not about sync. Sync is still a matter of correct implementation.

>
>
> and phasor~ … how many posts have there been this month
> abolut how to reset phasors phase ? :)

I missed those.. is there something wrong with a 0 in the right outlet?

Mattijs

#98398
Mar 7, 2007 at 3:41pm

Quoting Mattijs Kneppers :

> I agree with you about this. Users shouldn’t be blamed that they
> don’t understand. I think cycling is obliged to
>
> a) add a chapter to the max fundamentals that explains exactly
> how to use metro (and threading) and how not to, with overly
> clear examples,

Oh yeah, and not just metro. I’ve read through the docs, had it
repeatedly explained to me, but I still don’t quite get the actual
effect that things like “overdrive” and “slop” and the latency
settings on windows, all combined with sigvec and i/o vec sizes
actually have. Some of it is nomenclature (“overdrive?” — I never
even knew what that did for an automobile). Several of these
settings seem to interact, and I’ve noticed that the do so very
differently depending on whether you are using Windows or OSX.

brad

http://music.columbia.edu/~brad

PS — related comment on the dev list to this…

#98399
Mar 7, 2007 at 4:44pm

Yep, el.samm~ and it’s associated objects are well
worth checking out, if you’re on a Mac.
I started converting an old drum machine patch that
had grown really sloppy, to use these objects instead
of regular scheduler stuff, and it improved things no
end.
You can’t do everything in the signal domain, but
these objects are a great leap in that direction, and
even if you have to completely redesign the patch (as
i did), it’s worth the effort if tightness is your
goal.
You’ll find some info on samm in this thread (and some
other interesting thoughts on this subject too):
http://tinyurl.com/l49ch
cheers
Roger

#98400
Mar 7, 2007 at 5:22pm

On Mar 7, 2007, at 11:44 AM, ROGER CARRUTHERS wrote:
> Yep, el.samm~ and it’s associated objects are well
> worth checking out, if you’re on a Mac.

Amen to that. I said it before but it bears repeating: “If you had
seen Eric Lyon’s paper at ICMC 2006 you would not be having this
conversation.” Lucky for you it is online…

A Sample Accurate Triggering System for Pd and MaxMSP
http://www.sarc.qub.ac.uk/~elyon/LyonPapers/SampleAccurate-Lyon-
ICMC2006.pdf

——————-
Nathan Wolek, PhD — nwolek@stetson.edu
Assistant Professor of Music Technology
Stetson University – DeLand, FL

http://www.nathanwolek.com

#98401
Mar 7, 2007 at 5:59pm

> Quote: Dayton wrote on Wed, 07 March 2007 15:07
> —————————————————-

> Why?
> Phase shifting:
>
> #P user number~ 148 173 187 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 148 152 37 196617 %~ 1.;
> #P user number~ 91 173 130 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 148 132 40 196617 +~ 0.5;
> #P newex 91 105 46 196617 phasor~;
> #P connect 0 0 2 0;
> #P connect 0 0 1 0;
> #P connect 3 0 4 0;
> #P connect 1 0 3 0;
>
> Pitch bending:
>
> #P user number~ 357 173 396 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P user number~ 300 173 339 188 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 357 132 40 196617 /~ 0.5;
> #P newex 300 105 46 196617 phasor~;
> #P connect 1 0 3 0;
> #P connect 0 0 2 0;
> #P connect 0 0 1 0;

That threw me for a bit, so I tried it out. No go (although I don’t rule out the possibility of my being extremely dense at the moment.) There are three problems to this approach:
1. Any real-time changes cause ugly clicks
2. I can’t go backwards with one loop and forward with another
3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).

Basically, I need to be able to do anything with the (in my case) [stutter] objects individually and collectively, and sync them back up on command.
I would love to use only one phasor for this patch, so I would be more than happy if you prove me wrong.

Here is the test-patch:
max v2;
#N vpatcher 15 55 996 620;
#P origin 6 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 919 327 135 9109513 Playback Speed (pitchbend);
#P button 509 76 15 0;
#P newex 436 98 135 9109513 expr ((44100.0 / $i1)*$f2);
#P flonum 509 52 76 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 406 52 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 405 31 102 9109513 Grain Size (samples);
#P comment 510 30 78 9109513 Playback Speed;
#P window setfont “Sans Serif” 10.;
#P newex 416 394 113 9109514 receive~ masterphasor;
#P newex 435 159 101 9109514 send~ masterphasor;
#P window setfont “Sans Serif” 9.;
#P newex 417 444 27 196617 /~ 1.;
#P newex 436 130 52 196617 phasor~ 1.;
#P window setfont “Sans Serif” 10.;
#P newex 741 111 61 9109514 loadmess 1;
#P message 904 112 39 9109514 store 3;
#P message 858 112 39 9109514 store 2;
#P message 813 112 39 9109514 store 1;
#N vpreset 3;
#X append 1 2 15 341 384 number int 1 ; 16 340 490 flonum float 1. ; 17 412 54 gain~ list 122 10. ; 21 153 55 toggle int 0 ; 22 412 79 gain~ list 122 10. ; 24 153 88;
#X append 1 2 toggle int 1 ; 29 156 240 toggle int 0 ; 32 208 278 number int 1355 ; 37 345 813 number int 1 ; 38 344 919 flonum float 1. ; 48 496 681 toggle int 1 ; 51 490 252;
#X append 1 2 toggle int 1 ; 54 551 439 number~ list 0. ; 67 52 406 number int 59775 ; 68 52 509 flonum float 1. ;;
#X append 2 2 15 341 384 number int 58495 ; 16 340 490 flonum float 1. ; 17 412 54 gain~ list 122 10. ; 21 153 55 toggle int 0 ; 22 412 79 gain~ list 122 10. ; 24 153 88;
#X append 2 2 toggle int 1 ; 29 156 240 toggle int 0 ; 32 208 278 number int 1326 ; 37 345 813 number int 58495 ; 38 344 919 flonum float 1.25 ; 48 496 681 toggle int 1 ; 51 490 252;
#X append 2 2 toggle int 1 ; 54 551 439 number~ list 0. ;;
#X append 3 2 15 341 384 number int 58495 ; 16 340 490 flonum float 1. ; 17 412 54 gain~ list 122 10. ; 21 153 55 toggle int 0 ; 22 412 79 gain~ list 122 10. ; 24 153 88;
#X append 3 2 toggle int 1 ; 29 156 240 toggle int 0 ; 32 208 278 number int 1326 ; 37 345 813 number int 58495 ; 38 344 919 flonum float 2. ; 48 496 681 toggle int 1 ; 51 490 252;
#X append 3 2 toggle int 1 ; 54 551 439 number~ list 0. ;;
#P preset 813 143 47 27;
#P message 334 302 14 9109514 0;
#P user number~ 439 551 525 567 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 439 515 27 9109514 -~;
#P window linecount 2;
#P comment 471 516 100 9109514 actual difference between signals;
#P toggle 252 490 15 0;
#P window linecount 1;
#P newex 252 511 53 9109514 gate~ 1 1;
#P newex 252 551 58 9109514 send~ st01;
#P toggle 681 496 15 0;
#P newex 681 517 53 9109514 gate~ 1 1;
#P message 423 224 14 9109514 1;
#P newex 29 314 35 9109514 gate~;
#P newex 692 348 102 9109514 receive~ fromsource;
#P button 724 434 15 0;
#P newex 681 557 58 9109514 send~ st01;
#P button 919 369 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 846 429 44 9109513 phasor~;
#P newex 846 391 135 9109513 expr ((44100.0 / $i1)*$f2);
#P flonum 919 344 76 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 813 345 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 724 477 133 9109513 stutter~ 441000 11025 -1 10 1;
#B color 5;
#P comment 812 328 102 9109513 Grain Size (samples);
#P window setfont “Sans Serif” 10.;
#P newex 263 344 102 9109514 receive~ fromsource;
#P button 295 280 15 0;
#P number 278 208 35 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 240 207 32 9109514 timer;
#P newex 240 175 52 9109514 togedge;
#P toggle 240 156 15 0;
#P newex 240 234 65 9109514 mstosamps~;
#P newex 74 346 70 9109514 receive~ st01;
#P newex 54 270 102 9109514 receive~ fromsource;
#P newex 55 234 90 9109514 send~ fromsource;
#P toggle 88 153 15 0;
#P message 88 176 44 9109514 loop $1;
#P user gain~ 79 412 24 100 158 0 1.071519 7.94321 10.;
#P toggle 55 153 15 0;
#P window setfont “Sans Serif” 9.;
#P message 54 176 28 9109513 open;
#N sfplay~ 1 120960 0 ;
#P newobj 54 199 48 9109513 sfplay~ 1;
#B color 5;
#P user ezdac~ 53 556 97 589 0;
#P user gain~ 54 412 24 100 158 0 1.071519 7.94321 10.;
#P flonum 490 340 76 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 384 341 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 295 473 133 9109513 stutter~ 441000 11025 -1 10 1;
#B color 5;
#P comment 383 324 102 9109513 Grain Size (samples);
#P comment 491 323 135 9109513 Playback Speed (pitchbend);
#P window setfont “Sans Serif” 10.;
#P comment 445 226 100 9109514 reset (stop loops);
#P comment 351 303 132 9109514 reset both phasors to 0;
#P window linecount 2;
#P comment 1 29 130 9109514 Use a “Master Phasor” or seperate phasors….;
#P comment 232 123 61 9109514 toggle to record loop;
#P comment 52 120 70 9109514 use soundfile as source;
#P window linecount 1;
#P comment 594 75 100 9109514 “master phasor”;
#P window linecount 2;
#P comment 300 409 100 9109514 Stutter responding to “master phasor”;
#P comment 731 391 100 9109514 Stutter responding to its own phasor;
#P user panel 241 321 394 195;
#X brgb 255 250 157;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P user panel 675 321 394 195;
#X brgb 207 215 255;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P user panel 223 120 105 147;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P user panel 381 27 218 159;
#X brgb 176 255 157;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P fasten 21 0 45 0 60 174 34 174;
#P connect 17 0 18 0;
#P connect 21 0 19 0;
#P fasten 23 0 19 0 93 197 59 197;
#P connect 20 0 19 0;
#P fasten 26 0 45 1 59 304 59 304;
#P fasten 45 0 17 0 34 388 59 388;
#P fasten 27 0 17 0 79 376 59 376;
#P connect 19 0 25 0;
#P fasten 45 0 22 0 34 388 84 388;
#P fasten 27 0 22 0 79 376 84 376;
#P connect 17 1 22 0;
#P fasten 22 0 18 1 84 542 92 542;
#P connect 24 0 23 0;
#P connect 29 0 30 0;
#P fasten 30 0 31 0 245 200 245 200;
#P connect 31 0 28 0;
#P connect 51 0 50 0;
#P connect 50 0 49 0;
#P fasten 30 1 31 1 287 199 267 199;
#P hidden connect 31 0 32 0;
#P fasten 28 1 33 0 300 259 300 259;
#P connect 33 0 14 0;
#P fasten 15 0 14 0 389 467 300 467;
#P fasten 34 0 14 0 268 458 300 458;
#P connect 14 0 50 1;
#P fasten 33 0 55 0 300 297 339 297;
#P fasten 28 1 15 0 300 275 389 275;
#P fasten 46 0 15 0 428 253 389 253;
#P fasten 28 1 67 0 300 260 315 260 315 47 411 47;
#P connect 64 0 62 0;
#P connect 62 0 14 2;
#P fasten 16 0 62 1 495 426 439 426;
#P connect 61 0 63 0;
#P fasten 70 0 69 0 514 94 441 94;
#P fasten 67 0 69 0 411 94 441 94;
#P connect 69 0 61 0;
#P fasten 62 0 53 0 422 468 444 468;
#P connect 53 0 54 0;
#P fasten 40 0 53 1 851 455 461 455;
#P fasten 55 0 61 1 339 327 330 327 330 115 483 115;
#P fasten 68 0 70 0 514 71 514 71;
#P fasten 68 0 69 1 514 70 566 70;
#P connect 48 0 47 0;
#P connect 47 0 42 0;
#P fasten 28 1 43 0 300 275 729 275;
#P fasten 37 0 36 0 818 471 729 471;
#P connect 43 0 36 0;
#P fasten 44 0 36 0 697 462 729 462;
#P connect 36 0 47 1;
#P fasten 60 0 56 0 746 135 818 135;
#P fasten 59 0 56 0 909 135 818 135;
#P fasten 58 0 56 0 863 135 818 135;
#P connect 57 0 56 0;
#P fasten 28 1 37 0 300 275 818 275;
#P fasten 46 0 37 0 428 253 818 253;
#P fasten 37 0 39 0 818 387 851 387;
#P fasten 41 0 39 0 924 387 851 387;
#P connect 39 0 40 0;
#P connect 40 0 36 2;
#P fasten 55 0 40 1 339 378 885 378;
#P fasten 38 0 41 0 924 364 924 364;
#P fasten 38 0 39 1 924 363 976 363;
#P pop;

#98402
Mar 7, 2007 at 7:15pm

If you are going to do anything with signal rate timing, I highly
recommend looking into and fully understanding the following objects:
sync~
rate~
zigzag~
adsr~
pong~
edge~
>~,< ~,*~,+~,/~,!/~, etc.
index~
+=~
and of course clever use of buffer~.

Being able to use these objects with some finesse should allow you to
solve most problems that you will come up against with managing a
signal-based timing structure.
FWIW, I have not checked out Eric’s objects, but most of the problems
given in his paper can be solved with some combination of the above objects.

Cheers,
Andrew B.

#98403
Mar 7, 2007 at 7:48pm

>> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
>> That’s very well possible considering that the scheduler
>> event interval is 2 ms by default.

a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
on how you count.
well or 8 – depending how you count! :)

but try this:

max v2;
#N vpatcher 60 709 784 1054;
#P toggle 49 42 38 0;
#P user ezdac~ 49 194 93 227 0;
#P newex 49 140 105 196617 click~;
#P newex 49 102 105 196617 metro 125;
#P connect 3 0 0 0;
#P connect 0 0 1 0;
#P connect 1 0 2 0;
#P connect 1 0 2 1;
#P pop;

if there is anybody who can tell if those beats are straight
or punctuated he/she obviously know more about metro than
kasper and me. :) to me it sounds more like “random” than
like “sequencing”.

(btw, according to your theory above those are half notes, LOL.)

> > and phasor~ … how many posts have there been this month
> > abolut how to reset phasors phase ? :)
>
> I missed those.. is there something wrong with a 0 in the right outlet?

… it does not accept signals, so when you need to sync 35
phasors (which is why we want to reset phase) you have
a problem.

or was it cycle~ what i had in mind here?

#98404
Mar 7, 2007 at 8:05pm

> >> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
> >> That’s very well possible considering that the scheduler
> >> event interval is 2 ms by default.
>
>
> a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
> on how you count.
> well or 8 – depending how you count! :)

we are all a bit retarded i think.

i just noticed that on my “developer” computer i had the
signal vector size set to “1024″ for maximum CPU resources.

at “32″ it works well.

i normally only use my max stuff in pluggo form (where you
have exactly that, a vector size of 32 all over the runtime
due to the VST interface.) so i didnt notice this weird
setting for about 2 years.

still, there is this little hickup syndrome in my metro, even
at a proper vector size.

-110

#98405
Mar 7, 2007 at 8:38pm

Quote: andrewb@cycling74.com wrote on Wed, 07 March 2007 12:15
—————————————————-
> If you are going to do anything with signal rate timing, I highly
> recommend looking into and fully understanding the following objects:
> sync~
> rate~
> zigzag~
> adsr~
> pong~
> edge~
> >~,< ~,*~,+~,/~,!/~, etc.
> index~
> +=~
> and of course clever use of buffer~.
>
> Being able to use these objects with some finesse should allow you to
> solve most problems that you will come up against with managing a
> signal-based timing structure.

Definitely true, but none of them can be used effectively in the example I posted earlier in order to synchronize the rates of the signals needed for the [stutter] objects.

rate~ comes the closest, but it suffers from two drawbacks:
1. it can easily be made to crash by fooling around with the time-scale around 0.
2. it cannot be made to stop independantly.

It also needs the ability to rescale itself accurately to buffers of varying lengths with sample accuracy, which it could, but there are no explicit messages to send it to do so (both floats and signals do not give this accuracy. For instance, if the first buffer is 1003ms and the second is 905, how can you express this to rate~ in order to have both samples played back with the right velocity?)

All of this is not to say that what I want cannot be done; I have been happily using my looper for quite a while now with several phasors. It is just good to see if I missed something useful.

#98406
Mar 8, 2007 at 8:08am

#98407
Mar 8, 2007 at 8:12am

#98408
Mar 8, 2007 at 9:31am

Dayton skrev:
> Quote: Mattijs wrote on Wed, 07 March 2007 06:26
> —————————————————-
>
>
>> The correct answer is that if you want to have different loops play in sync, drive them all with one phasor. I can imagine that to do this, groove~ is less suitable than for instance play~.
>>
>
> —————————————————-
>
> Yes, but that would preclude any possibility of pitch-bending and/or phase-shifting the individual loops, which is one of the reasons I got into Max/MSP in the first place.

I am sorry if this has been replied to before:
If you drive all your loops from one phasor~ you can indeed to
pitch-bending and phase-shifting – pitchbending can be done by adding or
subtracting with an envelope from the phasor output (or manipulating
rate~ objects?), and phase-shifting is as simple as adding or
subtracting static values.

I am sure that you have tried these options though, so I am curious as
to why they do not do what you want?

#98409
Mar 8, 2007 at 11:24am

Quote: Wetterberg wrote on Thu, 08 March 2007 02:31
—————————————————-

> I am sure that you have tried these options though, so I am curious as
> to why they do not do what you want?

—————————————————-

I went back and tried them again to make sure that I hadn’t missed something back then. The pitchbend-comparison is in the patch above. Here are my experiences:

rate~ can crash if you have it locked-mode and pass the time-scale through 0 a few times. (Max/MSP ver. 4.5.5, Pentium 4 3GHz, 1GB RAM, MAudio MobilePre, 44100Hz, I/Ov128 sv64) Also, it can’t be made to stop (although, of course it can be gated.) In addition, if I am dealing with loops of different lengths, the rate~ must be adjusted accordingly, and it cannot be adjusted with sample accuracy by either a float or a signal due to the decimal-precision. There are workarounds, but multiple phasors are more straightforward.

Simple mathematical manipulation of the phasor’s signal is fine for fixed values, but doesn’t work for changing dynamically. Try it out in the patch; it sounds awful with both floats and signals (why? I don’t know).

In theory, there should be another solution, but I tried everything I could think of and this was what worked. The functionality must allow:
Complete freedom of playback-rate and direction for each loop
Complete freedom of length for each loop
Recalibration of the phase for each loop
Quantizable loop-lengths
Dynamic changes in each aspect (for use in live-performances)

Believe me, I would prefer to work with rate~, and there may be some unwanted upper limits in the use of individual phasors, but this is what works.

#98410
Mar 8, 2007 at 11:45am

if you use +=~ and play~ you can easily create smooth pitchbending/pitch curves. i use a master phasor~ to trigger a sah~ object that samples the current value of +=~ and subtracts that value from the output of said +=~ effectively resetting it at sample rate. the only drawback is that +=~ gets enormous quite quickly, and this can cause roundoff errors, the sound gets crunchy, so you have to reset it to zero now and again.

maybe not so elegant but it works for me

#98411
Mar 8, 2007 at 12:23pm

I find it kind of interesting to how this debate have evolved.
I ask something i think is very simple(looping, overdubbing) from a musical point of view, and of you go discussing lowlevel technical aspects of the software proposed for creating the mucisians tools :-)

It is i think part of the big problem.

Why isn’t this as simple to model as it is simpel to me to “think” i wonder?

I (just) need some loop audio reels running. I need a possibillity to record on these reels. And above all i need the reels to spin in synch. It is to me a simple problem, no matter how much i understand your discussion.
I guess i visualize it as and old tape loop system. Now thats simple right :-7

Not to be a drag or anything, but could we get this thread back on the looper/sound-on-sound track?

Please post working examples of small working looper systems, prefereable with overdubbing. Otherwize please provide more perspective on how to design with dsp versus messaging to.

thanks all so far!

#98412
Mar 8, 2007 at 12:55pm

Why isn’t this as simple to model as it is simpel to me to “think” i wonder?

because your concious mind is filtering out nearly all of the information processing which is ocurring in your brain.
if you don’t want to code then use Radial or Live or Traktor. max msp is akin to your computer taking LSD. anything is possible, but mostly its overwhelmingly incomprehensible and you cant even work out how to make first steps. your community will support you!

#98413
Mar 8, 2007 at 1:28pm

-frankly, Using an visually oriented system as Max, i’d expect NOT to code.

If you go ahead and model pieces of inner computer machinery at a certain abstraction level, i’d say you perhaps need to complement that with severel models from the music-world to reach something greater. -To pair the to worlds i mean.

I find completely “funny” to expect musicians to work with max when it dosn’t model stuff like:
String, Drum head, Reel, and so on….

Drugs….hmmm – i guess also bad for computers :-!

#98414
Mar 8, 2007 at 2:36pm

it will do all of that stuff if you tell it how to do it. have a look at the SOS synth secrets series for ideas for basic concepts to start from in modelling real instruments.
maxmsp doesnt assume anything about what is musically useful, which makes it harder to use, but is also the reason why i personally am using it.
tools such as drugs or software are neither necessarily good nor bad imo. is a knife good?

#98415
Mar 8, 2007 at 2:45pm

In stead of talking, let’s just use your knife to cut to the case:

Any sampleaccurate loopers/overdubber example pathers would be greatly appreciated!

#98416
Mar 8, 2007 at 3:08pm

I see what you are working on.

First a very basic question: you are aware of the fact that if you want to pitch a loop down, it will also play slower, right? When one loop plays slower than the other, you’ll agree that there is no notion of sync anymore…

To answer your questions directly:
> 1. Any real-time changes cause ugly clicks

That’s true. See above, not only the pitch changes, the position changes too. So your cursor jumps to another point in the sample, causing a click. This is a basic design issue. My original statement about playing a loop with a different pitch is not of much use in most synced sample loop situations but was merely to show that anything you want to do should be derived from one audiorate sync source. I think in your case you need pitch shifting (granular or spectrum based, for an example see help file of gizmo~) instead of resampling (which is what you do if you play at another rate than 1).

> 2. I can’t go backwards with one loop and forward with another

Why not? You can all derive it from the master phasor. Like this for example:

#P user number~ 124 142 163 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 67 142 106 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 124 120 36 196617 !-~ 1.;
#P newex 67 93 46 196617 phasor~;
#P connect 0 0 2 0;
#P connect 0 0 1 0;
#P connect 1 0 3 0;

> 3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).

I don’t understand this point. What numbers do you feed to them? What representation do you want them to give you? Of which sound? What do you mean with dynamic scaling? Not to be annoying, just to give you an impression of where my understanding goes wrong.

I’m tempted to let you explain your final goal and implement it for you, just to prove my point to everyone on the forum ;) But I don’t have many spare time at the moment..

Best,
Mattijs

Quote: Dayton wrote on Wed, 07 March 2007 18:59
—————————————————-

> That threw me for a bit, so I tried it out. No go (although I don’t rule out the possibility of my being extremely dense at the moment.) There are three problems to this approach:
> 1. Any real-time changes cause ugly clicks
> 2. I can’t go backwards with one loop and forward with another
> 3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).
>
> Basically, I need to be able to do anything with the (in my case) [stutter] objects individually and collectively, and sync them back up on command.
> I would love to use only one phasor for this patch, so I would be more than happy if you prove me wrong.

#98417
Mar 8, 2007 at 3:45pm

Quote: Roman Thilenius wrote on Wed, 07 March 2007 20:48
—————————————————-
>
> >> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
> >> That’s very well possible considering that the scheduler
> >> event interval is 2 ms by default.
>
>
> a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
> on how you count.
> well or 8 – depending how you count! :)

Ah, sorry, I was thinking about 1/64 beat instead of 1/64 note, hehe, sorry. Of course 1/64 note is around 31 ms. But then I don’t understand your problem.

>
> but try this:
>
> max v2;
> #N vpatcher 60 709 784 1054;
> #P toggle 49 42 38 0;
> #P user ezdac~ 49 194 93 227 0;
> #P newex 49 140 105 196617 click~;
> #P newex 49 102 105 196617 metro 125;
> #P connect 3 0 0 0;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P connect 1 0 2 1;
> #P pop;
>
> if there is anybody who can tell if those beats are straight
> or punctuated he/she obviously know more about metro than
> kasper and me. :) to me it sounds more like “random” than
> like “sequencing”.

But.. am I crazy or do I totally miss the point? I hear a steady sequence of clicks. No hearable randomness at all. I can imagine that the clicks are up to 2 ms off but I can’t hear that. Could you record what you hear and then attach it?

>
> (btw, according to your theory above those are half notes, LOL.)

My bad. Sorry. Lol :)

>
>
>
> > > and phasor~ … how many posts have there been this month
> > > abolut how to reset phasors phase ? :)
> >
> > I missed those.. is there something wrong with a 0 in the right outlet?
>
>
> … it does not accept signals, so when you need to sync 35
> phasors (which is why we want to reset phase) you have
> a problem.

Ok, that really sounds like a situation where you should have used one master phasor.

Mattijs

>
> or was it cycle~ what i had in mind here?
>
>
>
>
>
—————————————————-

#98418
Mar 8, 2007 at 3:53pm

Quote: McSkelle wrote on Thu, 08 March 2007 14:28
—————————————————-
> -frankly, Using an visually oriented system as Max, i’d expect NOT to code.

I think a visual programming language might very well require more technical skill than textbased code. But…

> I find completely “funny” to expect musicians to work with max when it dosn’t model stuff like:
> String, Drum head, Reel, and so on….

…the question is: is max aimed towards musicians? I say: no. And voila, there’s the reason for this ongoing discussion.

I hope I didn’t just mess up cycling 74′s marketing stretegy? ;)

Cheers,
Mattijs

#98419
Mar 8, 2007 at 4:07pm

Quote: Roman Thilenius wrote on Wed, 07 March 2007 21:05
—————————————————-
>
> > >> 1/64 note at 120 bpm =~ 8 ms, a factor 0.25 off =~ 2 ms.
> > >> That’s very well possible considering that the scheduler
> > >> event interval is 2 ms by default.
> >
> >
> > a 64th is normally 31.25 or 62.5 ms long @ 120 bpm, depending
> > on how you count.
> > well or 8 – depending how you count! :)
>
>
> we are all a bit retarded i think.
>
> i just noticed that on my “developer” computer i had the
> signal vector size set to “1024″ for maximum CPU resources.
>
> at “32″ it works well.

Ah, I see. Forget my previous reply then.

> i normally only use my max stuff in pluggo form (where you
> have exactly that, a vector size of 32 all over the runtime
> due to the VST interface.) so i didnt notice this weird
> setting for about 2 years.
>
> still, there is this little hickup syndrome in my metro, even
> at a proper vector size.

Not in mine.. as far as I can hear.

>
>
> -110
>
>
>
>
>
>
—————————————————-

#98420
Mar 8, 2007 at 4:26pm

Quote: McSkelle wrote on Thu, 08 March 2007 15:45
—————————————————-
> In stead of talking, let’s just use your knife to cut to the case:
>
> Any sampleaccurate loopers/overdubber example pathers would be greatly appreciated!
—————————————————-

This is how I would start:

#P message 191 191 40 196617 import;
#P newex 33 317 41 196617 *~ 0.5;
#P user ezdac~ 33 340 77 373 0;
#P newex 191 228 105 196617 info~ loop1;
#P newex 93 251 27 196617 *~;
#P newex 93 271 62 196617 play~ loop2;
#P hidden newex 33 35 48 196617 loadbang;
#N vpatcher 50 119 189 293;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 50 70 29 196617 * 8.;
#P newex 50 90 31 196617 !/ 1.;
#P newex 50 50 37 196617 !/ 60.;
#P inlet 69 30 15 0;
#P inlet 50 30 15 0;
#P outlet 50 112 15 0;
#P connect 1 0 3 0;
#P connect 3 0 5 0;
#P connect 5 0 4 0;
#P connect 4 0 0 0;
#P connect 2 0 5 1;
#P pop;
#P newobj 33 101 73 196617 p beatsToFreq;
#P hidden newex 33 54 44 196617 t 120 8;
#P message 191 130 40 196617 import;
#P number 33 83 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 70 83 43 196617 bpm;
#P number 117 83 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 33 120 43 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 33 137 46 196617 phasor~;
#P newex 93 188 27 196617 *~;
#P newex 191 166 105 196617 info~ loop1;
#P newex 93 208 62 196617 play~ loop1;
#P newex 191 208 71 196617 buffer~ loop2;
#P newex 191 147 71 196617 buffer~ loop1;
#P comment 154 83 43 196617 beats;
#P connect 19 0 18 0;
#P connect 19 0 18 1;
#P connect 6 0 5 0;
#P connect 6 0 16 0;
#P connect 20 0 2 0;
#P fasten 15 0 19 0 98 292 38 292;
#P fasten 3 0 19 0 98 227 38 227;
#P fasten 17 6 16 1 274 248 115 248;
#P connect 2 1 17 0;
#P connect 16 0 15 0;
#P hidden connect 14 0 12 0;
#P connect 8 0 13 1;
#P connect 10 0 13 0;
#P connect 13 0 7 0;
#P hidden connect 12 0 10 0;
#P hidden connect 12 1 8 0;
#P connect 11 0 1 0;
#P connect 5 0 3 0;
#P connect 7 0 6 0;
#P fasten 4 6 5 1 274 185 115 185;
#P connect 1 1 4 0;

Mattijs

#98421
Mar 8, 2007 at 4:28pm

> …the question is: is max aimed towards musicians? I say: no. And voila, there’s the reason for this ongoing discussion.
>

yeah, where’ all the uber Max music to be found? I have heard very little music made with Max/PD…

#98422
Mar 8, 2007 at 4:37pm

I guess http://cycling74.com/c74music might be a good
place to start…
cheers
Roger

— jamez wrote:
>
> yeah, where’ all the uber Max music to be found? I
> have heard very little music made with Max/PD…
>
>

#98423
Mar 8, 2007 at 4:38pm

Depends on the Circles you travel and the type of music you listen
to. But I hear it all the time….

On Mar 8, 2007, at 11:28 AM, jamez wrote:

>
>
>> …the question is: is max aimed towards musicians? I say: no. And
>> voila, there’s the reason for this ongoing discussion.
>>
>
>
> yeah, where’ all the uber Max music to be found? I have heard very
> little music made with Max/PD…
>
>

v a d e //

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

#98424
Mar 8, 2007 at 5:03pm

>yeah, where’ all the uber Max music to be found? I have heard very
little music made with >Max/PD…

I guess you haven’t visited the Cycling ’74 myspace page. Seems all of
our friends are making music:

http://www.myspace.com/cycling74

>…the question is: is max aimed towards musicians?
> I say: no.

To clarify, Max doesn’t really make too many assumptions about what you
are – musician, artist, civil engineer, interaction designer, video
artist, VJ, etc. You get to decide what MaxMSP is for.

Happy Patching,
Andrew B.

#98425
Mar 8, 2007 at 5:23pm

Well I think it takes a smart musician to learn how to
use max. I would say most electronic music producers
end up using easier tools like Reason-ish apps.
I think you can tell when someone is really trying to
do something innovative, more often than not they are
using Max or SuperCollider. For example: can you tell the
difference between Autechre and Richard Devine?

But if you were to go see a laptop musician, I doubt you
would be able to tell what all was used in producing
every aspect of the production. I regularly see a lot of
music that uses Max, in fact they all tend to be live electro
acoustic music performances because that is what Max excels
at: the performance environment.

Anthony

—– Original Message —–
From: vade
Date: Thursday, March 8, 2007 10:44 am
Subject: Re: [maxmsp] Re: Talking ’bout tightness

> Depends on the Circles you travel and the type of music you listen
>
> to. But I hear it all the time….
>
> On Mar 8, 2007, at 11:28 AM, jamez wrote:
>
> >
> >
> >> …the question is: is max aimed towards musicians? I say: no.
> And
> >> voila, there’s the reason for this ongoing discussion.
> >>
> >
> >
> > yeah, where’ all the uber Max music to be found? I have heard
> very
> > little music made with Max/PD…
> >
> >
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
>

#98426
Mar 8, 2007 at 6:32pm

Mattijs: Thanks!

#98427
Mar 8, 2007 at 8:19pm

Here is a super-simple example of doing a signal-based loop/overdub
patch. This should maintain timing “tightness”.

Happy Patching,
Andrew B.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 428 148 57 196617 click-track;
#P toggle 412 148 15 0;
#N vpatcher 20 74 620 474;
#P inlet 93 92 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 50 117 27 196617 *~;
#P outlet 50 153 15 0;
#P newex 50 92 41 196617 *~ 0.2;
#P newex 50 71 39 196617 < ~ 10.;
#P newex 50 50 90 196617 pong~ 1 0. 22050;
#P inlet 50 30 15 0;
#P connect 0 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 5 0;
#P connect 5 0 4 0;
#P connect 6 0 5 1;
#P pop;
#P newobj 354 168 68 196617 p click-track;
#P user scope~ 354 260 484 390 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P newex 173 49 35 196617 * 0.5;
#P flonum 172 31 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 169 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 242 46 33 196617 clear;
#N vpatcher 20 74 411 372;
#P window setfont “Sans Serif” 9.;
#P message 50 89 14 196617 1;
#P message 93 90 14 196617 0;
#P newex 92 70 38 196617 sel 32;
#P newex 50 70 38 196617 sel 32;
#P newex 92 50 40 196617 keyup;
#P newex 50 50 40 196617 key;
#P outlet 50 109 15 0;
#P connect 1 0 3 0;
#P connect 3 0 6 0;
#P connect 5 0 0 0;
#P connect 6 0 0 0;
#P connect 2 0 4 0;
#P connect 4 0 5 0;
#P pop;
#P newobj 40 64 63 196617 p space-bar;
#P message 40 107 37 196617 $1 10;
#P newex 40 126 32 196617 line~;
#P toggle 40 88 15 0;
#P newex 9 187 41 196617 *~ 0.5;
#P newex 173 225 35 196617 *~ 1.;
#P user scope~ 221 260 351 390 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P user ezdac~ 173 260 217 293 0;
#P newex 9 150 41 196617 *~;
#P newex 9 45 31 196617 adc~;
#P newex 173 160 67 196617 index~ loop1;
#P newex 173 131 40 196617 trunc~;
#P newex 173 111 40 196617 +~ 0.5;
#P newex 173 89 56 196617 *~ 88200;
#P newex 173 68 64 196617 phasor~ 0.5;
#P newex 242 68 98 196617 buffer~ loop1 2000;
#P newex 34 236 63 196617 poke~ loop1;
#P comment 58 89 39 196617 record;
#P comment 210 31 70 196617 playback rate;
#P connect 9 0 10 0;
#P connect 10 0 14 0;
#P fasten 14 0 2 0 14 206 39 206;
#P fasten 8 0 2 0 178 206 39 206;
#P connect 18 0 15 0;
#P connect 15 0 17 0;
#P connect 17 0 16 0;
#P connect 16 0 10 1;
#P connect 20 0 14 1;
#P fasten 7 0 2 1 178 156 65 156;
#P connect 21 0 22 0;
#P connect 22 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 8 0;
#P fasten 24 0 13 0 359 206 178 206;
#P fasten 14 0 13 0 14 206 178 206;
#P connect 8 0 13 0;
#P connect 13 0 11 0;
#P fasten 13 0 11 1 178 251 212 251;
#P fasten 13 0 12 0 178 251 226 251;
#P connect 19 0 3 0;
#P fasten 7 0 24 0 178 156 359 156;
#P connect 24 0 23 0;
#P connect 25 0 24 1;
#P window clipboard copycount 27;

#98428
Mar 8, 2007 at 8:38pm

…and if you want an interpolating buffer writer (when you go faster
than 1 sample per sample) use my free ipoke~

http://www.no-tv.org/MaxMSP

pa

btw, real-time triggered loopers, with 2 ms tighness, is still
tighter than most drummer on earth… here is my real-time looper
that I use with real musicians… you need hr objects though

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 243 183 33 196617 gate~;
#P newex 321 548 32 196617 defer;
#P newex 243 228 131 196617 hr./~ 1.;
#P newex 361 319 53 196617 hr.+~ 0.5;
#P message 83 169 14 196617 0;
#B color 15;
#P newex 83 150 27 196617 gate;
#P message 107 108 14 196617 0;
#B color 12;
#P message 321 531 31 196617 clear;
#B color 6;
#P window linecount 2;
#P comment 261 573 33 196617 audio output;
#P window linecount 1;
#P comment 283 34 54 196617 vari-speed;
#P window linecount 4;
#P comment 87 15 64 196617 cue input 1 : rec 2 : loop play 3 : mute;
#N comlet audio output;
#P outlet 243 579 15 0;
#N comlet vari-speed;
#P inlet 266 33 15 0;
#N comlet cue input (1:rec ; 2:loop play ; 3:mute);
#P inlet 68 33 15 0;
#N comlet audio input;
#P inlet 45 33 15 0;
#P window linecount 1;
#P message 539 105 14 196617 1;
#B color 6;
#P newex 305 489 27 196617 gate;
#P message 509 105 29 196617 0 10;
#B color 6;
#P message 305 101 14 196617 0;
#B color 15;
#P message 213 107 29 196617 1 10;
#B color 15;
#P newex 243 489 33 196617 *~ 0.;
#P newex 266 460 66 196617 line~ 0.;
#P message 305 509 14 196617 0;
#B color 6;
#P newex 243 205 64 196617 hr.*~ 1000.;
#P newex 431 150 27 196617 * 2.;
#P newex 361 383 117 196617 hr.play~ $1;
#P newex 361 363 117 196617 hr.*~;
#P newex 243 383 117 196617 hr.play~ $1;
#P newex 243 363 117 196617 hr.*~;
#P newex 361 340 62 196617 hr.wrap~ 1.;
#P newex 243 250 72 196617 hr.phasor~;
#P message 243 127 14 196617 1;
#B color 15;
#P newex 431 114 33 196617 timer;
#P message 183 107 29 196617 0 10;
#B color 15;
#P message 29 169 14 196617 1;
#B color 12;
#P message 68 108 29 196617 1 10;
#B color 12;
#P newex 45 150 33 196617 *~ 0.;
#P newex 68 126 42 196617 line~ 0.;
#P newex 68 66 536 196617 sel 1 2 3;
#P newex 45 195 90 196617 record~ $1;
#P newex 321 567 217 196617 buffer~ $1 $2;
#P window linecount 2;
#P comment 14 28 28 196617 audio input;
#P fasten 3 2 26 0 423 85 544 85;
#P lcolor 7;
#P fasten 3 2 24 0 423 85 514 85;
#P lcolor 7;
#P connect 15 1 16 1;
#P fasten 3 1 8 0 248 95 188 95;
#P lcolor 16;
#P fasten 3 1 22 0 248 95 218 95;
#P lcolor 16;
#P connect 3 1 10 0;
#P lcolor 16;
#P fasten 3 1 23 0 248 95 310 95;
#P lcolor 16;
#P fasten 3 1 9 1 248 95 459 95;
#P lcolor 16;
#P fasten 17 0 13 2 436 305 318 305;
#P lcolor 16;
#P fasten 17 0 39 2 436 190 328 190;
#P lcolor 16;
#P connect 17 0 15 2;
#P lcolor 16;
#P connect 9 0 17 0;
#P lcolor 16;
#P fasten 3 0 7 0 73 90 34 90;
#P lcolor 13;
#P connect 3 0 6 0;
#P lcolor 13;
#P fasten 3 0 35 0 73 90 112 90;
#P lcolor 13;
#P fasten 3 0 9 0 73 90 436 90;
#P lcolor 13;
#P fasten 12 1 15 1 418 360 401 360;
#P fasten 38 1 12 1 409 337 383 337;
#P fasten 11 1 13 1 310 276 283 276;
#P fasten 11 1 38 1 310 276 380 276;
#P connect 15 0 16 0;
#P connect 12 0 15 0;
#P connect 38 0 12 0;
#P connect 11 0 13 0;
#P fasten 11 0 38 0 248 293 366 293;
#P connect 13 1 14 1;
#P connect 20 1 25 1;
#P connect 40 0 1 0;
#P connect 34 0 40 0;
#P connect 25 0 19 0;
#P fasten 25 0 34 0 310 507 326 507;
#P lcolor 7;
#P fasten 26 0 25 0 544 487 310 487;
#P lcolor 7;
#P connect 23 0 25 0;
#P lcolor 16;
#P connect 23 0 11 2;
#P lcolor 3;
#P fasten 18 1 39 1 302 225 288 225;
#P fasten 39 1 11 1 369 247 279 247;
#P connect 20 0 21 1;
#P fasten 24 0 20 0 514 457 271 457;
#P lcolor 7;
#P fasten 22 0 20 0 218 457 271 457;
#P lcolor 16;
#P connect 29 0 41 1;
#P connect 21 0 30 0;
#P fasten 16 0 21 0 366 402 248 402;
#P connect 14 0 21 0;
#P connect 13 0 14 0;
#P connect 39 0 11 0;
#P connect 18 0 39 0;
#P connect 41 0 18 0;
#P fasten 19 0 41 0 310 526 240 526 240 180 248 180;
#P lcolor 7;
#P fasten 10 0 36 0 248 145 88 145;
#P lcolor 16;
#P connect 10 0 41 0;
#P lcolor 16;
#P connect 4 1 36 1;
#P lcolor 16;
#P connect 36 0 37 0;
#P lcolor 16;
#P fasten 35 0 36 0 112 147 88 147;
#P lcolor 13;
#P connect 4 0 5 1;
#P connect 6 0 4 0;
#P fasten 8 0 4 0 188 124 73 124;
#P lcolor 16;
#P connect 28 0 3 0;
#P fasten 7 0 2 0 34 186 50 186;
#P lcolor 13;
#P connect 5 0 2 0;
#P fasten 37 0 2 0 88 186 50 186;
#P lcolor 16;
#P connect 27 0 5 0;
#P window clipboard copycount 42;

#98429
Mar 8, 2007 at 8:54pm

Can’t seem to find a download site for the hr object. Could anybody provide an URI?

#98430
Mar 8, 2007 at 9:08pm

#98431
Mar 9, 2007 at 12:50pm

You were right, but perhaps not in the same way you thought:

Quote: Mattijs wrote on Thu, 08 March 2007 08:08
—————————————————-
> I see what you are working on.
>
> First a very basic question: you are aware of the fact that if you want to pitch a loop down, it will also play slower, right? When one loop plays slower than the other, you’ll agree that there is no notion of sync anymore…

Only until you stop pitch-bending, then the sync is the relationship between the length of the loops, which is what I consider important, not to get them all the same length

> > 2. I can’t go backwards with one loop and forward with another
>
> Why not? You can all derive it from the master phasor. Like this for example:
>
> #P user number~ 124 142 163 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P user number~ 67 142 106 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 124 120 36 196617 !-~ 1.;
> #P newex 67 93 46 196617 phasor~;
> #P connect 0 0 2 0;
> #P connect 0 0 1 0;
> #P connect 1 0 3 0;

I mean dynamically (twiddling dials and such.) The above code cannot go from forward playback to backward playback by going from positive to negative while playback is going on. Using this discussion as an impetus, however, I have come to agree with you that I can, indeed use only one controlling instance, although for my purposes this is not phasor (patch below)

> > 3. The numbers I feed to [/] or [+] do not give me an accurate representation about what I am doing to the sound (although a bit of dynamic scaling would).
>
> I don’t understand this point. What numbers do you feed to them? What representation do you want them to give you? Of which sound? What do you mean with dynamic scaling? Not to be annoying, just to give you an impression of where my understanding goes wrong.

This is just to say that I wanted to express the manipulations in terms of samples instead of mathematical operations based on frequency, miliseconds, etc. (Solution below)

OK, I spent some time experimenting this morning, and found the answer to my problems in the [count~] object, which I hadn’t used before. This finally gave me the opportunity to give [stutter] a specific number of samples to grab as well as a playback signal based on exactly that number of samples. When using loops of different lengths simultaneously, the relationships of length given as a proportion to the [rate] object could cause anomalies which resulted in small differences of playback rate, specifically in the case of lengths of a third, sixth, etc. In the past, I had been measuring in miliseconds and converting them back to samples, then to frequencies. In this patch, you can choose the [count] object instead of the phasor and at least start with an accurate number of samples.
Using [rate] allows for smooth bending (as long as it is set to “sync off”) and accurate multiples of the first loop-length, but if the subsequent loop-length doesn’t divide evenly into the first, it will get out of rhythm (particularly crucial in cases of loops being three times the original length). In my performance patch, I deal with this by quantizing the original loop-length to allow for the pre-selected subdivisions and quantizing the subsequent loops as well. When using free lengths it is unimportant that the loops are a few samples off.

So, you were right, it is possible to use a single playback-signal to drive multiple loops regardless of direction, length and rate, but not without preparing the output first.

Here is the updated test-patch, allowing experimentation with various types of signal-manipulation:

max v2;
#N vpatcher 20 33 1015 659;
#P origin 20 6;
#P button 1185 445 15 0;
#P window setfont “Sans Serif” 10.;
#P window linecount 1;
#P newex 301 223 41 9109514 cycle 2;
#N vpatcher 25 70 625 470;
#P window setfont “Sans Serif” 10.;
#P window linecount 0;
#P message 54 101 44 9109514 goto $1;
#P window linecount 1;
#P newex 54 72 36 9109514 r reset;
#P window linecount 0;
#P newex 7 331 35 9109514 gate~;
#P window linecount 1;
#P newex 365 165 29 9109514 != 0.;
#P toggle 365 200 15 0;
#P newex 379 131 71 9109514 expr $f1 * $f2;
#P flonum 365 73 93 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 2;
#P comment 408 166 100 9109514 stops playback at speed 0.;
#P comment 474 75 100 9109514 pitchbend expressed as factor of speed;
#P window linecount 0;
#P newex 113 88 70 9109514 expr $f1 / $f2;
#N comlet master loop length;
#P inlet 173 47 15 0;
#N comlet loop length;
#P inlet 113 47 15 0;
#N comlet playback signal;
#P outlet 7 368 15 0;
#N comlet playback signal;
#P inlet 32 48 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 176 236 49 9109513 sync lock;
#P message 129 236 45 9109513 sync off;
#P window setfont “Sans Serif” 10.;
#P newex 43 224 33 9109514 sel 0.;
#P flonum 66 266 93 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 32 292 44 9109514 rate~ 1.;
#P window linecount 2;
#P comment 166 267 181 9109514 playback rate expressed as factor of master playback rate;
#P fasten 15 0 17 0 370 323 12 323;
#P fasten 17 0 7 0 12 357 12 357;
#P fasten 19 0 1 0 59 125 37 125;
#P connect 6 0 1 0;
#P fasten 4 0 1 0 134 262 37 262;
#P fasten 5 0 1 0 181 263 37 263;
#P connect 1 0 17 1;
#P fasten 10 0 3 0 118 140 48 140;
#P fasten 14 0 3 0 384 160 48 160;
#P connect 18 0 19 0;
#P fasten 3 1 2 0 71 258 71 258;
#P connect 2 0 1 1;
#P connect 8 0 10 0;
#P connect 9 0 10 1;
#P connect 13 0 16 0;
#P connect 16 0 15 0;
#P fasten 13 0 14 0 370 100 384 100;
#P fasten 10 0 14 1 118 116 445 116;
#P pop;
#P newobj 1239 295 35 9109514 p rate;
#P newex 1165 401 55 9109514 r tostutters;
#P toggle 1140 513 15 0;
#P newex 1140 534 53 9109514 gate~ 1 1;
#P newex 1140 574 58 9109514 send~ st01;
#P newex 1151 367 102 9109514 receive~ fromsource;
#P window setfont “Sans Serif” 9.;
#P number 1272 364 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 1183 496 133 9109513 stutter~ 441000 11025 -1 10 1;
#B color 5;
#P comment 1271 347 102 9109513 Grain Size (samples);
#P user panel 1129 344 394 195;
#X brgb 255 250 157;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window setfont “Sans Serif” 10.;
#N vpatcher 25 70 625 470;
#N comlet length in samples;
#P outlet 203 344 15 0;
#N comlet toggle;
#P inlet 115 34 15 0;
#P window setfont “Sans Serif” 10.;
#P user number~ 85 306 188 322 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P message 157 122 27 9109513 stop;
#P flonum 220 307 73 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 203 264 51 9109513 snapshot~;
#P newex 115 180 49 9109513 count~;
#B color 5;
#P window setfont “Sans Serif” 10.;
#P newex 115 72 52 9109514 togedge;
#P fasten 1 0 5 0 120 235 90 235;
#P connect 6 0 0 0;
#P fasten 4 0 1 0 162 175 120 175;
#P connect 0 0 1 0;
#P fasten 0 1 4 0 162 97 162 97;
#P fasten 1 0 2 0 120 235 208 235;
#P fasten 0 1 2 0 162 103 208 103;
#P connect 2 0 7 0;
#P fasten 2 0 3 0 208 294 225 294;
#P pop;
#P newobj 277 176 75 9109514 p sampletimer;
#P window setfont “Sans Serif” 14.;
#N vpatcher 92 55 692 650;
#P button 189 360 15 0;
#P button 149 361 15 0;
#P window setfont “Sans Serif” 10.;
#P window linecount 1;
#P newex 149 382 50 9109514 onebang;
#P button 149 407 15 0;
#P window setfont “Sans Serif” 9.;
#P message 196 430 49 9109513 sync lock;
#P message 149 430 45 9109513 sync off;
#N comlet reset to 0;
#P inlet 345 44 15 0;
#P window setfont “Sans Serif” 10.;
#P user number~ 70 261 173 277 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 334 462 52 9109514 togedge;
#P newex 334 392 29 9109514 != 0.;
#P toggle 334 427 15 0;
#P newex 334 353 61 9109514 expr 1 / $f1;
#P flonum 334 329 93 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 91 427 33 9109514 sel 0.;
#P flonum 86 460 93 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 52 486 44 9109514 rate~ 1.;
#P message 477 138 14 9109514 0;
#P message 434 138 38 9109514 10000;
#P newex 53 297 29 9109514 /~ 1.;
#P user number~ 81 335 184 351 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 198 219 15 0;
#N comlet length of loop;
#P inlet 224 44 15 0;
#P outlet 51 588 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P comment 295 99 127 9109513 set count minimum on next loop without immediately affecting output;
#P window linecount 1;
#P message 295 139 51 9109513 min 1500;
#P number 224 171 67 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 159 139 27 9109513 stop;
#P flonum 180 272 73 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 180 242 51 9109513 snapshot~;
#P button 53 140 15 0;
#P newex 53 197 181 9109513 count~;
#B color 5;
#P window linecount 3;
#P comment 53 99 83 9109513 start counting from current minimum;
#P comment 156 100 94 9109513 stop counting , just put out the current minimum;
#P window linecount 1;
#P comment 296 173 526 9109513 set count limit/modulo (never actually reaches this number) This means that it will loop between minimum and this number.;
#P window setfont “Sans Serif” 10.;
#P window linecount 2;
#P comment 435 104 100 9109514 start counting from this number (min);
#P window linecount 1;
#P comment 88 300 251 9109514 convert sample number into signal ramp 0. to 1.;
#P window linecount 2;
#P comment 377 393 100 9109514 stops playback at speed 0.;
#P comment 443 330 100 9109514 pitchbend expressed as factor of speed;
#P connect 22 0 15 0;
#P connect 19 0 22 0;
#P fasten 33 0 22 0 201 457 57 457;
#P fasten 32 0 22 0 154 456 57 456;
#P fasten 11 0 7 0 164 162 58 162;
#P fasten 21 0 7 0 482 164 58 164;
#P fasten 20 0 7 0 439 167 58 167;
#P fasten 13 0 7 0 300 165 58 165;
#P connect 8 0 7 0;
#P connect 7 0 19 0;
#P fasten 7 0 30 0 58 245 75 245;
#P fasten 12 0 19 1 229 293 77 293;
#P fasten 19 0 18 0 58 324 86 324;
#P fasten 24 1 23 0 119 452 91 452;
#P connect 23 0 22 1;
#P fasten 26 0 24 0 339 379 96 379;
#P fasten 25 0 36 0 339 355 154 355;
#P connect 36 0 35 0;
#P connect 35 0 34 0;
#P connect 34 0 32 0;
#P fasten 29 1 11 0 381 497 164 497;
#P fasten 7 0 9 0 58 224 185 224;
#P fasten 17 0 9 0 203 238 185 238;
#P connect 9 0 10 0;
#P fasten 31 0 37 0 350 318 194 318;
#P connect 37 0 35 1;
#P fasten 31 0 33 0 350 296 201 296;
#P connect 11 0 17 0;
#P connect 16 0 12 0;
#P connect 12 0 7 1;
#P connect 25 0 26 0;
#P connect 25 0 28 0;
#P connect 28 0 27 0;
#P fasten 27 0 29 0 339 457;
#P fasten 31 0 21 0 350 67 482 67;
#P fasten 29 0 21 0 339 514 482 514;
#P pop 1;
#P newobj 606 155 55 9109518 p count;
#P window setfont “Sans Serif” 10.;
#P newex 1028 415 58 9109514 r tophasors;
#P newex 593 91 58 9109514 r tophasors;
#P newex 190 309 59 9109514 s tophasors;
#P newex 747 396 55 9109514 r tostutters;
#P newex 314 402 55 9109514 r tostutters;
#P newex 175 338 56 9109514 s tostutters;
#P window setfont “Sans Serif” 9.;
#P comment 956 351 135 9109513 Playback Speed (pitchbend);
#P button 546 70 15 0;
#P newex 473 92 113 9109513 expr ((44100.0 / $i1)*$f2);
#P flonum 546 46 76 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 443 46 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 442 25 102 9109513 Grain Size (samples);
#P comment 547 24 78 9109513 Playback Speed;
#P newex 473 124 52 9109513 phasor~ 1.;
#P window setfont “Sans Serif” 10.;
#P newex 778 105 61 9109514 loadmess 1;
#P message 941 106 39 9109514 store 3;
#P message 895 106 39 9109514 store 2;
#P message 850 106 39 9109514 store 1;
#N vpreset 3;
#X append 1 2 18 365 421 number int 116160 ; 19 408 54 gain~ list 122 10. ; 23 149 55 toggle int 0 ; 24 408 79 gain~ list 122 10. ; 26 149 88 toggle int 1 ; 30 150 277;
#X append 1 2 toggle int 0 ; 35 369 850 number int 116160 ; 36 368 956 flonum float 1. ; 46 520 718 toggle int 0 ; 49 514 289 toggle int 1 ; 52 583 476 number~ list 0. ; 62 46 443;
#X append 1 2 number int 116160 ; 63 46 546 flonum float 1. ; 78 364 1272 number int 36672 ; 82 513 1140 toggle int 1 ;;
#X append 2 2 18 365 421 number int 58495 ; -1 365 421 flonum float 1. ; 19 408 54 gain~ list 122 10. ; 23 149 55 toggle int 0 ; 24 408 79 gain~ list 122 10. ; 26 149 88;
#X append 2 2 toggle int 1 ; 30 150 277 toggle int 0 ; 78 364 1272 number int 1326 ; 35 369 850 number int 58495 ; 36 368 956 flonum float 1.25 ; 46 520 718 toggle int 1 ; 49 514 289;
#X append 2 2 toggle int 1 ; 52 583 476 number~ list 0. ;;
#X append 3 2 18 365 421 number int 58495 ; -1 365 421 flonum float 1. ; 19 408 54 gain~ list 122 10. ; 23 149 55 toggle int 0 ; 24 408 79 gain~ list 122 10. ; 26 149 88;
#X append 3 2 toggle int 1 ; 30 150 277 toggle int 0 ; 78 364 1272 number int 1326 ; 35 369 850 number int 58495 ; 36 368 956 flonum float 2. ; 46 520 718 toggle int 1 ; 49 514 289;
#X append 3 2 toggle int 1 ; 52 583 476 number~ list 0. ;;
#P preset 850 137 47 27;
#P message 190 64 17 9109514 0.;
#P user number~ 476 583 562 599 10 139 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 476 547 27 9109514 -~;
#P window linecount 2;
#P comment 508 548 100 9109514 actual difference between signals;
#P toggle 289 514 15 0;
#P window linecount 1;
#P newex 289 535 53 9109514 gate~ 1 1;
#P newex 289 575 58 9109514 send~ st01;
#P toggle 718 520 15 0;
#P newex 718 541 53 9109514 gate~ 1 1;
#P message 175 37 14 9109514 1;
#P newex 29 310 35 9109514 gate~;
#P newex 729 372 102 9109514 receive~ fromsource;
#P button 761 458 15 0;
#P newex 718 581 58 9109514 send~ st01;
#P button 956 393 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 883 453 44 9109513 phasor~;
#P newex 883 415 135 9109513 expr ((44100.0 / $i1)*$f2);
#P flonum 956 368 76 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 850 369 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 761 501 133 9109513 stutter~ 441000 11025 -1 10 1;
#B color 5;
#P comment 849 352 102 9109513 Grain Size (samples);
#P window setfont “Sans Serif” 10.;
#P newex 300 368 102 9109514 receive~ fromsource;
#P button 277 274 15 0;
#P toggle 277 150 15 0;
#P newex 74 342 70 9109514 receive~ st01;
#P newex 54 266 102 9109514 receive~ fromsource;
#P newex 55 230 90 9109514 send~ fromsource;
#P toggle 88 149 15 0;
#P message 88 172 44 9109514 loop $1;
#P user gain~ 79 408 24 100 158 0 1.071519 7.94321 10.;
#P toggle 55 149 15 0;
#P window setfont “Sans Serif” 9.;
#P message 54 172 28 9109513 open;
#N sfplay~ 1 120960 0 ;
#P newobj 54 195 48 9109513 sfplay~ 1;
#B color 5;
#P user ezdac~ 53 552 97 585 0;
#P user gain~ 54 408 24 100 158 0 1.071519 7.94321 10.;
#P number 421 365 75 9 1 0 1 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 332 497 133 9109513 stutter~ 441000 11025 -1 10 1;
#B color 5;
#P comment 420 348 102 9109513 Grain Size (samples);
#P window setfont “Sans Serif” 10.;
#P comment 197 39 100 9109514 reset (stop loops);
#P comment 215 65 132 9109514 reset all phasors to 0;
#P window linecount 2;
#P comment 1 25 130 9109514 Use a “Master Phasor” or seperate phasors….;
#P comment 269 117 61 9109514 toggle to record loop;
#P comment 52 116 70 9109514 use soundfile as source;
#P window linecount 1;
#P comment 640 32 100 9109514 “master phasor”;
#P window linecount 2;
#P comment 713 297 100 9109514 Stutter responding to its own phasor;
#P user panel 278 345 394 195;
#X brgb 255 250 157;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P user panel 712 345 394 195;
#X brgb 207 215 255;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window linecount 1;
#P comment 298 275 100 9109514 grab last x samples;
#P window setfont “Sans Serif” 14.;
#N vpatcher 5 75 947 475;
#P window setfont “Sans Serif” 10.;
#P number 32 33 35 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 184 64 59 9109514 selector~ 2;
#N comlet counter;
#P inlet 357 34 15 0;
#P newex 666 267 29 9109514 print;
#P window setfont “Sans Serif” 9.;
#P number 808 219 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 763 274 35 9109513 click~;
#P toggle 763 219 15 0;
#P newex 763 246 55 9109513 metro 500;
#P comment 761 201 122 9109513 or an audio ‘click track’;
#P comment 761 177 118 9109513 or bang for tap-tempo;
#P comment 761 151 114 9109513 or use float to set BPM;
#P flonum 723 149 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 743 175 15 0;
#P comment 702 130 114 9109513 adjust ramp output;
#P message 664 148 51 9109513 offset $1;
#P flonum 664 128 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 589 183 60 9109543 1 64 199 0;
#X add fold;
#X add wrap;
#P message 589 204 45 9109513 mode $1;
#P comment 540 231 42 9109513 lo val;
#P comment 595 231 36 9109513 hi val;
#P flonum 596 248 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 540 248 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 10.;
#P newex 580 38 53 9109514 loadbang;
#P window setfont “Sans Serif” 9.;
#P message 517 153 55 9109513 sync cycle;
#P message 416 153 45 9109513 sync off;
#P message 464 153 50 9109513 sync lock;
#P window setfont “Sans Serif” 10.;
#P flonum 437 184 83 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 527 285 40 9109514 pong~;
#P newex 403 214 44 9109514 rate~ 1.;
#P newex 651 238 40 9109514 sync~;
#N comlet signal from masterphasor;
#P inlet 207 35 15 0;
#N comlet playback signal;
#P outlet 30 362 15 0;
#P number 31 81 35 10 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 31 331 757 9109514 selector~ 6;
#P window setfont “Sans Serif” 9.;
#P newex 279 156 27 9109513 /~ 1.;
#P flonum 296 125 76 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 299 110 135 9109513 Playback Speed (pitchbend);
#P window setfont “Sans Serif” 10.;
#P comment 72 34 100 9109514 select input;
#P comment 73 83 100 9109514 select output;
#P comment 227 35 100 9109514 master phasor;
#P comment 375 34 51 9109514 counter;
#P connect 7 0 9 0;
#P connect 8 0 7 0;
#P fasten 39 0 7 1 189 164 160 164;
#P fasten 40 0 39 0 37 59 170 59 170 59 189 59;
#P connect 10 0 39 1;
#P fasten 38 0 39 2 362 55 237 55;
#P fasten 39 0 6 0 189 94 284 94;
#P fasten 6 0 7 2 284 246 284 246;
#P connect 5 0 6 1;
#P fasten 39 0 12 0 189 94 408 94;
#P fasten 17 0 12 0 522 178 427 178 427 195 408 195;
#P fasten 15 0 12 0 469 175 424 175 424 197 408 197;
#P fasten 16 0 12 0 421 196 408 196;
#P fasten 12 0 7 3 408 266 408 266;
#P connect 14 0 12 1;
#P fasten 18 0 15 0 585 87 469 87;
#P fasten 39 0 13 0 189 95 532 95;
#P fasten 23 0 13 0 594 278 532 278;
#P connect 13 0 7 4;
#P fasten 19 0 13 1 545 271 547 271;
#P fasten 20 0 13 2 601 271 562 271;
#P connect 24 0 23 0;
#P fasten 39 0 11 0 189 95 656 95;
#P fasten 29 0 11 0 728 180 656 180;
#P fasten 35 0 11 0 768 299 733 299 733 228 656 228;
#P fasten 28 0 11 0 748 201 656 201;
#P fasten 26 0 11 0 669 171 656 171;
#P connect 11 0 7 5;
#P connect 25 0 26 0;
#P connect 11 1 37 0;
#P connect 34 0 33 0;
#P connect 33 0 35 0;
#P connect 36 0 33 1;
#P pop 1;
#P newobj 476 196 192 9109518 p selectmode;
#P window setfont “Sans Serif” 10.;
#P comment 611 135 122 9109514 an alternative to phasor;
#P user panel 418 21 325 162;
#X brgb 176 255 157;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window linecount 2;
#P comment 1134 296 100 9109514 Stutter responding to rate;
#P window linecount 3;
#P comment 345 217 253 9109514 record loops sequencially: the first two stutter objects both record with the first toggle , and the third with the second.;
#P user panel 260 114 105 147;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P fasten 23 0 43 0 60 170 34 170;
#P connect 19 0 20 0;
#P connect 23 0 21 0;
#P connect 22 0 21 0;
#P fasten 25 0 21 0 93 193 59 193;
#P fasten 28 0 43 1 59 300 59 300;
#P fasten 43 0 19 0 34 384 59 384;
#P fasten 29 0 19 0 79 372 59 372;
#P connect 21 0 27 0;
#P fasten 43 0 24 0 34 384 84 384;
#P fasten 29 0 24 0 79 372 84 372;
#P connect 19 1 24 0;
#P fasten 24 0 20 1 84 538 92 538;
#P connect 26 0 25 0;
#P fasten 31 0 67 0 282 294 180 294;
#P fasten 44 0 67 0 180 62 180 62;
#P fasten 53 0 70 0 195 114 195 114;
#P connect 30 0 74 0;
#P fasten 85 0 31 0 306 270 282 270;
#P connect 49 0 48 0;
#P connect 48 0 47 0;
#P fasten 74 0 85 0 282 213 306 213;
#P fasten 68 0 17 0 319 471 337 471;
#P fasten 32 0 17 0 305 482 337 482;
#P fasten 18 0 17 0 426 491 337 491;
#P connect 17 0 48 1;
#P fasten 85 0 18 0 306 312 426 312;
#P fasten 85 0 62 0 306 263 388 263 388 44 448 44;
#P fasten 5 0 17 2 481 252 459 252;
#P fasten 62 0 64 0 448 88 478 88;
#P fasten 65 0 64 0 551 88 478 88;
#P connect 64 0 59 0;
#P fasten 59 0 5 0 478 149 481 149;
#P connect 5 0 51 0;
#P connect 51 0 52 0;
#P fasten 84 0 51 1 1244 332 498 332;
#P fasten 71 0 59 1 598 118 520 118;
#P fasten 63 0 65 0 551 65 551 65;
#P fasten 63 0 64 1 551 64 581 64;
#P fasten 62 0 73 0 448 148 611 148;
#P fasten 71 0 73 1 598 130 656 130;
#P fasten 73 0 5 1 611 187 663 187;
#P connect 46 0 45 0;
#P connect 45 0 40 0;
#P fasten 35 0 34 0 855 495 766 495;
#P fasten 69 0 34 0 752 493 766 493;
#P fasten 42 0 34 0 734 486 766 486;
#P connect 41 0 34 0;
#P connect 34 0 45 1;
#P connect 55 0 54 0;
#P fasten 56 0 54 0 900 129 855 129;
#P fasten 57 0 54 0 946 129 855 129;
#P fasten 58 0 54 0 783 129 855 129;
#P fasten 85 0 35 0 306 312 855 312;
#P fasten 35 0 37 0 855 411 888 411;
#P fasten 39 0 37 0 961 411 888 411;
#P connect 37 0 38 0;
#P connect 38 0 34 2;
#P fasten 72 0 38 1 1033 443 922 443;
#P fasten 36 0 39 0 961 388 961 388;
#P fasten 36 0 37 1 961 387 1013 387;
#P connect 82 0 81 0;
#P connect 81 0 80 0;
#P connect 86 0 77 0;
#P fasten 78 0 77 0 1277 490 1188 490;
#P fasten 79 0 77 0 1156 481 1188 481;
#P fasten 83 0 77 0 1170 470 1188 470;
#P connect 77 0 81 1;
#P fasten 78 0 86 0 1277 430 1190 430;
#P fasten 5 0 84 0 481 234 1244 234;
#P fasten 85 1 84 1 337 266 1256 266;
#P fasten 85 0 84 2 306 267 1268 267;
#P fasten 85 1 78 0 337 267 1277 267;
#P fasten 84 0 77 2 1244 448 1310 448;
#P pop;

#98432
Mar 9, 2007 at 1:34pm

Quote: Dayton wrote on Fri, 09 March 2007 13:50
—————————————————-
> You were right, but perhaps not in the same way you thought:
>
> Quote: Mattijs wrote on Thu, 08 March 2007 08:08
> —————————————————-
> > I see what you are working on.
> >
> > First a very basic question: you are aware of the fact that if you want to pitch a loop down, it will also play slower, right? When one loop plays slower than the other, you’ll agree that there is no notion of sync anymore…
>
> Only until you stop pitch-bending, then the sync is the relationship between the length of the loops, which is what I consider important, not to get them all the same length

Ok, that’s an option. That means that the loop has a time offset after bending back to pitch 1 and every time you bend the pitch this offset will change, correct? Or maybe the loop will jump to the beginning every cycle?

>
> > > 2. I can’t go backwards with one loop and forward with another
> >
> > Why not? You can all derive it from the master phasor. Like this for example:
> >
> > #P user number~ 124 142 163 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P user number~ 67 142 106 157 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
> > #P newex 124 120 36 196617 !-~ 1.;
> > #P newex 67 93 46 196617 phasor~;
> > #P connect 0 0 2 0;
> > #P connect 0 0 1 0;
> > #P connect 1 0 3 0;
>
> I mean dynamically (twiddling dials and such.) The above code cannot go from forward playback to backward playback by going from positive to negative while playback is going on. Using this discussion as an impetus, however, I have come to agree with you that I can, indeed use only one controlling instance, although for my purposes this is not phasor (patch below)

Allright, if I understand you correctly this is similar to the pitch controller, only pitch also enters negative values.

Good that you found an alternative, but after a quick glance at your patch I still have the strong feeling that your approach is unnecessarily difficult. Preparing the output shouldn’t be necessary. Your idea is in the line of a project I am working on so if I have time this weekend I’ll try to remake your patch according to my ideas, if you don’t mind of course.

Best,
Mattijs

#98433
Mar 9, 2007 at 6:46pm

Quote: Mattijs wrote on Fri, 09 March 2007 06:34
so if I have time this weekend I’ll try to remake your patch according to my ideas, if you don’t mind of course.

On the contrary; I would be flattered.
After trying a few different approaches and looking back over what I did a year ago, I am came very close today to having a general looping-platform which enables me to loop using a number of approaches. Since all of them seem to work, however, it is difficult to decide how to test them against each other.

The only reason I ended up using [Stutter] was for a live-improvisation situation in which the musicians (or, in my case, actors) could decide after playing or saying a phrase if they wanted to use it (there is no start-record, stop-record; just “loop everything since the beginning of the last phrase” (using a threshhold trigger)). This still seems the best approach for that purpose, but I think the patch I am finishing up now will allow me to use several approaches by simply replacing the subpatch-name in the [poly]. Stutter takes up more than twice the memory that a buffer-based approach would, so I will see if I can get what I normally need without it.

#98434
Mar 9, 2007 at 11:33pm

Roman Thilenius schrieb:
> if you use metro, you are using a message system.
>
> 2 messages (bang) coming out of metro, connected to 2
> somethings, will NEVER arrive at their aims at the same time.
>
> 2 samples (for example an “1.” sample, a click),
> will ALWAYS arrive at the same time when connected to 2
> aims. (or to be exact, _within the same sample)

messages and samples do not differ in principle, but in the time range
they occur. Your NEVER and your ALWAYS apply to both:
ALWAYS in the sense of your “to be exact, _within the same sample”, is
for messages mostly “within the same tick”. If you overload the
scheduler your messages get backlogged though, in audio rate you’d get
crackles if you overload the processor (sounds worse than untightness…)
In audio rate samples will not always arrive in the same sample, that
depends on the type of process/external you are using, some things
happen once within a signal vector. And if “scheduler in audio
interrupt” is switched on, the scheduler interval is bound to the signal
vector…

If you overload your processor you will have timing problems. If you
don’t it doesn’t make such a big difference. If you have a signal vector
of 64 samples, you’ll have your timing tight to less than 1.5 ms…

If you feel fine with Midi tightness, you should be fine with scheduler
control as well, but you have to set your performance options carefully…

Stefan


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

#98435
Mar 9, 2007 at 11:38pm

Mattijs Kneppers schrieb:
> If we could bundle this test with a few others, together with clear
> and simple clarifications and finally notes and examples how to
> approach possible issues in the correct way, we’d have a real
> solution for the everlasting ‘metro’ misunderstanding.

Yes, I modified the patch a bit, to be able to see the exact difference
as well as to be able to play with the settings within the patch. It
verifies quite clearly my statement about less than 1.5 ms with a vector
size of 64 and scheduler in audio interrupt/overdrive on…

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P hidden newex 413 438 29 196617 t 1;
#P comment 287 399 134 196617 Max Scheduler in Overdrive;
#P comment 287 417 135 196617 Scheduler in Audio Interrupt;
#P user umenu 435 396 49 196645 1 64 412 0;
#X add Off;
#X add On;
#P hidden newex 501 397 94 196617 adstatus overdrive;
#P user umenu 435 415 49 196645 1 64 431 0;
#X add Off;
#X add On;
#P hidden newex 501 416 89 196617 adstatus takeover;
#P user umenu 435 371 72 196645 1 64 387 0;
#X add 1;
#X add 2;
#X add 4;
#X add 8;
#X add 16;
#X add 32;
#X add 64;
#X add 128;
#X add 256;
#X add 512;
#X add 1024;
#X add 2048;
#X add 4096;
#P hidden newex 541 372 73 196617 adstatus sigvs;
#P comment 331 373 90 196617 Signal Vector Size;
#P newex 327 284 65 196617 split 0. 500.;
#P newex 346 313 50 196617 – 1000.;
#P window setfont “Sans Serif” 10.;
#P flonum 327 339 95 10 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 327 254 38 196618 timer;
#P message 272 95 17 196618 0.;
#P button 272 71 15 0;
#P button 253 210 15 0;
#P button 225 210 15 0;
#P newex 225 180 38 196618 edge~;
#P newex 225 148 57 196618 >=~ 0.58;
#P newex 225 118 71 196618 phasor~ 1.;
#P user number~ 150 373 236 389 10 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221
221 222 222 222 0 0 0;
#P newex 150 337 27 196618 -~;
#P flonum 119 290 95 10 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 119 252 39 196618 timer;
#P message 113 95 17 196618 0.;
#P button 113 71 15 0;
#P toggle 156 30 15 0;
#P newex 405 117 76 196618 metro 1000;
#P button 94 210 15 0;
#P button 66 210 15 0;
#P newex 66 180 38 196618 edge~;
#P newex 66 148 63 196618 >=~ 0.58;
#P newex 66 118 71 196618 phasor~ 1.;
#P user ezdac~ 18 43 62 76 0;
#P window linecount 3;
#P comment 177 242 114 196618 ms difference between bang outputs from
[edge];
#P window linecount 4;
#P comment 400 239 100 196618 ms difference between bang output from
[edge] and [metro];
#P window linecount 2;
#P comment 182 338 100 196618 actual difference between signals;
#P hidden connect 37 0 10 0;
#P hidden connect 34 0 37 0;
#P hidden fasten 34 0 33 0 440 413 460 413 486 392 506 392;
#P hidden connect 32 0 37 0;
#P hidden fasten 32 0 31 0 440 432 481 432 507 411 506 411;
#P hidden connect 30 0 37 0;
#P hidden fasten 30 0 29 0 440 389 516 389 542 368 546 368;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 7 0;
#P connect 6 1 8 0;
#P fasten 10 0 11 0 161 55 118 55;
#P connect 11 0 12 0;
#P fasten 8 0 13 0 99 234 124 234;
#P connect 13 0 14 0;
#P connect 12 0 4 1;
#P fasten 21 0 13 1 258 233 153 233;
#P fasten 4 0 15 0 71 143 47 143 47 317 155 317;
#P connect 15 0 16 0;
#P fasten 17 0 15 1 230 143 172 143;
#P connect 17 0 18 0;
#P connect 18 0 19 0;
#P connect 19 0 20 0;
#P connect 19 1 21 0;
#P fasten 10 0 22 0 161 55 277 55;
#P connect 22 0 23 0;
#P connect 23 0 17 1;
#P fasten 21 0 24 0 258 233 332 233;
#P connect 24 0 27 0;
#P connect 27 0 25 0;
#P connect 26 0 25 0;
#P connect 27 1 26 0;
#P fasten 9 0 24 1 410 232 360 232;
#P fasten 10 0 9 0 161 55 410 55;
#P hidden fasten 29 0 30 0 546 391 542 391 512 369 440 369;
#P hidden fasten 33 0 34 0 506 415 486 415 456 393 440 393;
#P hidden fasten 31 0 32 0 506 434 507 434 477 412 440 412;
#P window clipboard copycount 38;


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

#98436
Mar 10, 2007 at 7:33am

Kasper T Toeplitz schrieb:
> with working patches (audio ok, no cliks etc) i am more often in the
> 1000-1300 range!

Then you didn’t set “scheduler in audio interrupt” on…
Or you totally overload the scheduler which is also possible. Then you
have to get rid of all these snapshot~s and replace them with edge~
constructions. And avoid very short metros if possible. Anything which
is polled, needs some time to eat CPU for breakfast, lunch and dinner.
They are always hungry those objects…
Especially some of the fft analysis objects are hungry, and need to be
offset against each other, elsewise they want to eat CPU all at the same
time and you get the typical traffic jam you know from the peripherique
in Paris… (If you ask your metro/friend to be in time, for sure
they’ll be late… ;-)
On the Mac you can see how much you push the processor with the activity
monitor…

Stefan


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

#98437
Mar 10, 2007 at 8:08am

f.e schrieb:
> @ Stefan Tiedje :
>
> 1 – i took a look at your metro~ (cf. abhaxions), but without any help
> file, i still wonder what to do with the 3rd inlet…

BPM instead of milliseconds (you could open them and see… ;-)

> 2 – why did you set the initial phase to 0.499 instead of 0.5 ? it
> scares me to think this is a workaround because even phasor~ has its own
> problem ?

I forgot, why I did it, probably to get the first bang out immediately.
You can experiment with some settings and change the values, maybe it
was stupid… I usually just leave things as they are if they work for
me. If you find concrete problems, don’t hesitate to correct them and/or
report them…

The help file should be in the collection…, but here it is again:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 9 279 105 196617 Abhaxions.Copyright;
#P newex 316 169 31 196617 dac~;
#P message 316 149 28 196617 stop;
#P message 245 149 66 196617 startwindow;
#P number 205 149 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 3;
#P comment 251 86 55 196617 int in right inlet sets BPM;
#P window linecount 4;
#P comment 9 220 344 196617 Metro takes one optional argument which is
the metronome time in milliseconds. The left inlet takes int which
starts it with a non-zero value and stops it with the value zero. The
right inlet takes int to change the metronome speed. The outlet sends bang.;
#P window linecount 5;
#P comment 9 143 55 196617 An int starts it if nonzero , otherwise
stops it.;
#P window linecount 2;
#P comment 17 98 57 196617 bang starts metronome;
#P toggle 67 152 15 0;
#P button 76 113 15 0;
#P comment 98 86 40 196617 stop stops it;
#P window linecount 1;
#P newex 103 168 112 196617 metro~ 500;
#B color 5;
#P message 103 113 28 196617 stop;
#P button 103 192 15 0;
#P slider 154 66 13 51 0 1;
#P newex 154 127 28 196617 * 40;
#P number 154 149 33 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 2;
#P comment 222 169 86 196617 optional argument to initialize time;
#P window linecount 4;
#P comment 218 23 137 196617 Argument: int (optional) ; Left inlet: int
, bang or stop ; Right inlet: int ; Outlet: bang;
#P window setfont “Sans Serif” 14.;
#P window linecount 1;
#P comment 10 20 56 196622 metro~;
#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P comment 10 40 151 196617 Metronome that outputs bangs~. It works like
metro but is based on audiorate.;
#P comment 170 86 79 196617 int in middle inlet sets time in milliseconds;
#P connect 20 0 21 0;
#P connect 19 0 21 0;
#P connect 18 0 10 2;
#P connect 5 0 10 1;
#P connect 6 0 5 0;
#P connect 7 0 6 0;
#P connect 10 0 8 0;
#P connect 9 0 10 0;
#P connect 13 0 10 0;
#P connect 12 0 10 0;
#P window clipboard copycount 23;


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

#98438
Mar 10, 2007 at 12:40pm

>Kasper T Toeplitz schrieb:
>>with working patches (audio ok, no cliks etc) i am more often in
>>the 1000-1300 range!
>
>Then you didn’t set “scheduler in audio interrupt” on…
>Or you totally overload the scheduler which is also possible. Then
>you have to get rid of all these snapshot~s and replace them with
>edge~ constructions. And avoid very short metros if possible.
>Anything which is polled, needs some time to eat CPU for breakfast,
>lunch and dinner. They are always hungry those objects…
>Especially some of the fft analysis objects are hungry, and need to
>be offset against each other, elsewise they want to eat CPU all at
>the same time and you get the typical traffic jam you know from the
>peripherique in Paris… (If you ask your metro/friend to be in
>time, for sure they’ll be late… ;-)
>On the Mac you can see how much you push the processor with the
>activity monitor…

hi stefan
no I didn’t set “scheduler in audio interrupt” on

but then no snapshot~ and no very short metros ( 5000 is not short, right ?)

I use metro in paris and am never late

i wish the one in max would work as it is supposed to. It does not,
so i build my own metro~ (which i discovered to be very close to your
metro~ so I changed the name)

all the best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart

#98439
Mar 10, 2007 at 2:29pm

Quote: Kasper T Toeplitz wrote on Sat, 10 March 2007 13:40
—————————————————-

> i wish the one in max would work as it is supposed to. It does not,

I can’t believe that you keep insisting that metro doesn’t work correctly if so many experienced people repeat over and over that there’s nothing wrong with it.

Mattijs

#98440
Mar 10, 2007 at 5:34pm

I need an advice what’s the best equipment(laptop,
interface,etc) to use when setting up digital
Audio/Video for
corporate events, and also if anyone had ever used
MAX/MSP for
that before?
thanks
Anya

Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.

http://answers.yahoo.com/dir/?link=list&sid=396545367

#98441
Mar 10, 2007 at 5:47pm

> I can’t believe that you keep insisting that metro doesn’t work correctly if so many experienced people repeat over and over that there’s nothing wrong with it.

It’s still not clear what precisely is wrong with working
in the signal domain [metro was always an artifact of the old
event-level Max world], but I would think that the arrival
of Eric Lyon’s elegant and flexible samm~ object would
change things a little; it’s a marvelous piece of work.

#98442
Mar 10, 2007 at 6:23pm

>
>
>> i wish the one in max would work as it is supposed to. It does not,
>
>I can’t believe that you keep insisting that metro doesn’t work
>correctly if so many experienced people repeat over and over that
>there’s nothing wrong with it.

ok, i know (now) about all the reasons, blablabla, scheduler, osX,
all those things

but even if experienced people repeat over and over that all is fine
when i read in the ref manual “. At regular intervals,
metro sends a bang out the outlet.”

and my metro does not send a bang at REGULAR intervals (unless you
say than anything in the 1000-1300 range is regular) – that’s why I
keep insisting it is not working correctly.

I learned how NOT to use this object to do what i want (all my
patches have a time counter – I used to use a metro to drive them,
now i use other things, audio domain). But it seems to me it is not
working as it says it would.

G Taylor talks about samm~, there is metro~ etc… still, if talking
about metro, i feel it does not sends a bang at regular intervals. It
does it sometimes, sometimes not. Which is not how i would define
regular, belive it

all the best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart

#98443
Mar 11, 2007 at 12:52pm

Hi Dayton,

Here is my approach. It illustrates the technique I think is best for looping with separate pitch per loop, derived from one master phase without leaving the dsp domain.

Best,
Mattijs

Make sure you save and load the file to fire all loadbangs..

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 364 69 28 9109513 adc~;
#P user meter~ 99 487 179 500 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P user meter~ 423 491 503 504 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P window setfont “Sans Serif” 14.;
#P comment 500 238 16 9109518 2;
#P window setfont “Sans Serif” 9.;
#P comment 399 247 34 9109513 record;
#P newex 342 487 71 9109513 send~ loopout2;
#P newex 530 441 76 9109513 receive~ audioin;
#P comment 399 266 55 9109513 pitch offset;
#P newex 416 414 56 9109513 r buffersize;
#P newex 391 329 60 9109513 r masterfreq;
#P newex 342 375 101 9109513 receive~ masterphase;
#P newex 416 444 60 9109513 prepend size;
#P toggle 362 247 15 0;
#P newex 522 465 77 9109513 record~ sample2;
#P newex 342 422 32 9109513 %~ 1.;
#P newex 393 308 27 9109513 t 0 0;
#P button 457 266 15 0;
#P newex 362 308 27 9109513 t b f;
#P flonum 362 266 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 342 399 29 9109513 +~ 0.;
#P newex 362 330 27 9109513 * 0.;
#P newex 362 351 41 9109513 phasor~;
#P newex 342 444 43 9109513 *~ 1234.;
#P newex 416 465 100 9109513 buffer~ sample2 1000;
#P newex 342 465 69 9109513 play~ sample2;
#P comment 474 266 30 9109513 reset;
#P newex 112 539 82 9109513 receive~ loopout2;
#P newex 25 567 33 9109513 *~ 0.7;
#P newex 25 539 82 9109513 receive~ loopout1;
#P comment 82 245 34 9109513 record;
#P newex 25 485 71 9109513 send~ loopout1;
#P newex 213 439 76 9109513 receive~ audioin;
#P newex 396 91 65 9109513 send~ audioin;
#P comment 82 264 55 9109513 pitch offset;
#P newex 99 412 56 9109513 r buffersize;
#P newex 74 327 60 9109513 r masterfreq;
#P newex 77 149 58 9109513 s buffersize;
#P newex 20 191 62 9109513 s masterfreq;
#P newex 25 373 101 9109513 receive~ masterphase;
#P newex 36 170 90 9109513 send~ masterphase;
#P user hslider 122 65 10 127 128 1 0 0;
#P newex 189 40 33 9109513 * 127.;
#P newex 122 40 64 9109513 snapshot~ 40;
#P newex 99 442 60 9109513 prepend size;
#P newex 437 69 76 9109513 loadmess loop 1;
#P user meter~ 462 92 542 105 50 0 168 0 103 103 103 255 153 0 255 0 0 217 217 0 153 186 0 12 3 3 3 3;
#P toggle 427 48 15 0;
#P message 395 48 28 9109513 open;
#N sfplay~ 1 120960 0 ;
#P newobj 395 69 40 9109513 sfplay~;
#P toggle 45 245 15 0;
#P newex 205 463 77 9109513 record~ sample1;
#P newex 25 420 32 9109513 %~ 1.;
#P newex 76 306 27 9109513 t 0 0;
#P button 140 264 15 0;
#P newex 45 306 27 9109513 t b f;
#P flonum 45 264 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 25 397 29 9109513 +~ 0.;
#P newex 45 328 27 9109513 * 0.;
#P newex 45 349 41 9109513 phasor~;
#P user ezdac~ 24 596 68 629 0;
#P newex 25 442 43 9109513 *~ 1234.;
#P newex 36 39 45 9109513 loadbang;
#P newex 36 61 37 9109513 t 120 8;
#P number 77 83 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 36 83 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#N vpatcher 25 70 208 292;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 98 112 38 9109513 * 1000.;
#N comlet (float , ms) buffer size;
#P outlet 98 135 15 0;
#N comlet (float) hz;
#P outlet 38 135 15 0;
#P newex 38 112 27 9109513 !/ 1.;
#P newex 38 89 27 9109513 * 8.;
#P window linecount 0;
#P newex 38 67 30 9109513 !/ 60.;
#N comlet (int) beats;
#P inlet 82 35 15 0;
#N comlet (float) bpm;
#P inlet 38 36 15 0;
#P connect 0 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 4 0;
#P connect 4 0 5 0;
#P connect 1 0 3 1;
#P connect 3 0 7 0;
#P connect 7 0 6 0;
#P pop;
#P newobj 36 102 51 9109513 p bpmtohz;
#B color 5;
#P newex 36 125 41 9109513 phasor~;
#P newex 99 463 100 9109513 buffer~ sample1 1000;
#P newex 25 463 69 9109513 play~ sample1;
#P comment 268 65 66 9109513 master phase;
#P comment 157 264 30 9109513 reset;
#P window setfont “Sans Serif” 14.;
#P comment 183 236 16 9109518 1;
#P user panel 33 234 168 56;
#X brgb 239 239 239;
#X frgb 74 66 148;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P background;
#P user panel 350 236 168 56;
#X brgb 239 239 239;
#X frgb 74 66 148;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P background;
#P connect 8 0 36 0;
#P connect 46 0 14 0;
#P connect 35 0 17 0;
#P connect 17 0 22 0;
#P connect 22 0 13 0;
#P connect 13 0 5 0;
#P connect 5 0 43 0;
#P connect 47 0 46 0;
#P connect 45 0 46 0;
#P connect 12 0 11 0;
#P connect 11 0 9 0;
#P connect 9 0 8 0;
#P connect 8 0 7 0;
#P connect 7 0 34 0;
#P connect 15 0 17 1;
#P hidden connect 21 1 18 0;
#P hidden connect 18 0 19 0;
#P connect 38 0 16 0;
#P connect 19 0 16 0;
#P connect 16 0 15 0;
#P connect 39 0 13 1;
#P connect 46 0 14 1;
#P connect 19 1 16 1;
#P hidden connect 20 0 21 0;
#P connect 21 0 15 1;
#P connect 11 1 10 0;
#P connect 10 0 8 1;
#P connect 8 1 37 0;
#P connect 39 0 30 0;
#P connect 30 0 6 0;
#P connect 5 0 72 0;
#P connect 7 0 31 0;
#P connect 32 0 33 0;
#P connect 31 0 32 0;
#P hidden connect 24 0 23 0;
#P connect 42 0 23 0;
#P connect 63 0 54 0;
#P connect 54 0 59 0;
#P connect 59 0 51 0;
#P connect 51 0 49 0;
#P connect 49 0 68 0;
#P connect 52 0 54 1;
#P hidden connect 58 1 55 0;
#P hidden connect 55 0 56 0;
#P connect 56 0 53 0;
#P connect 64 0 53 0;
#P connect 53 0 52 0;
#P connect 65 0 51 1;
#P connect 56 1 53 1;
#P hidden connect 57 0 58 0;
#P connect 58 0 52 1;
#P connect 29 0 25 0;
#P connect 27 0 25 0;
#P connect 26 0 25 0;
#P connect 73 0 41 0;
#P connect 25 0 41 0;
#P connect 65 0 62 0;
#P connect 62 0 50 0;
#P connect 49 0 71 0;
#P connect 25 0 28 0;
#P hidden connect 61 0 60 0;
#P connect 67 0 60 0;

Quote: Dayton wrote on Fri, 09 March 2007 19:46
—————————————————-
> Quote: Mattijs wrote on Fri, 09 March 2007 06:34
> so if I have time this weekend I’ll try to remake your patch according to my ideas, if you don’t mind of course.
>
>
> On the contrary; I would be flattered.
> After trying a few different approaches and looking back over what I did a year ago, I am came very close today to having a general looping-platform which enables me to loop using a number of approaches. Since all of them seem to work, however, it is difficult to decide how to test them against each other.

#98444
Mar 11, 2007 at 5:08pm

ok… heres a FAR FAR out solution.

IF you had a matrix whose width was the vector size, and height was 1. then you could represent bangs and/or integers in audio rate.

if you made it 2 dimensional, you could represent any max message at audio rate.

if someone (**NOT ME**) wrote some objects on that principal, you could have audio rate max messages.

whoa.

I know this is going to piss some people off, but Gregory Taylor once told me that PD had an option to make any patcher run at any sampling rate. More malulable sampling rates and datatypes really seems to be a common solution.

#98445
Mar 11, 2007 at 7:56pm

this is the method i use for smooth sample rate pitchbending and curves using a phasor~ driven system. the only drawback with the bare bones system is that +=~ will get big after a while, causing round off errors

#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P comment 72 55 42 196617 pitch curve amount;
#P flonum 115 63 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 223 136 27 196617 *~;
#B color 10;
#P newex 223 113 33 196617 !-~ 1;
#B color 10;
#P newex 193 166 27 196617 +~;
#B color 10;
#P comment 108 191 52 196617 reset +=~;
#P flonum 280 54 35 9 0. 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 281 77 49 196617 !/ 1000.;
#B color 10;
#P comment 279 35 77 196617 looplength (ms);
#P comment 181 42 34 196617 pitch;
#P flonum 335 316 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 197 192 46 196617 /~ 44.1;
#B color 10;
#P newex 270 211 42 196617 ==~ -1;
#P newex 270 189 46 196617 change~;
#P button 160 191 15 0;
#P newex 181 82 29 196617 sig~;
#B color 10;
#P flonum 181 61 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user ezdac~ 197 434 241 467 1;
#P newex 280 98 46 196617 phasor~;
#B color 10;
#P message 306 423 43 196617 replace;
#P newex 306 444 85 196617 buffer~ spool1 2;
#P newex 197 352 27 196617 +~;
#P newex 197 387 76 196617 play~ spool1 2;
#P newex 197 223 25 196617 +=~;
#B color 10;
#P newex 197 278 27 196617 -~;
#P newex 238 250 40 196617 sah~ 0;
#P comment 377 315 34 196617 offset;
#P connect 8 0 23 0;
#P connect 8 0 13 0;
#P connect 3 0 2 0;
#P connect 3 0 1 0;
#P connect 25 0 24 1;
#P connect 24 0 22 1;
#P connect 23 0 24 0;
#P connect 11 0 22 0;
#P connect 22 0 15 0;
#P connect 19 0 8 0;
#P connect 20 0 19 0;
#P connect 2 0 5 0;
#P connect 5 0 4 0;
#P connect 7 0 6 0;
#P connect 16 0 5 1;
#P connect 12 0 3 0;
#P connect 10 0 11 0;
#P connect 15 0 3 0;
#P connect 14 0 1 1;
#P connect 13 0 14 0;
#P connect 1 0 2 1;
#P connect 4 1 9 1;
#P connect 4 0 9 0;
#P window clipboard copycount 27;

#98446
Mar 12, 2007 at 10:37am

Kasper T Toeplitz schrieb:
> but then no snapshot~ and no very short metros ( 5000 is not short,
> right ?)

These are the scheduler killers anyway. You do not want to use shorter
than 10 ms metros in scheduler. It’s already thought as audiorate, even
if its slower than unaudible. Musical metros will go up to 64ths, and
that’s already. And as I said before, snapshots~ do eat your non-audio
rate cycles. Try to get rid of them or bang them rarely…

This explains very well your problems… Its not the metro, its the way
you treat it…

> still, if talking about metro, i feel it does not sends a bang at
> regular intervals. It does it sometimes, sometimes not. Which is not
> how i would define regular, belive it

It does so for me,
but then if I overload my CPU I would not get a simple cycle~ put out a
sine wave, it would crackle, though the manual states it puts out a sine…
The same for scheduler overload, if I demand too much, none of any
object will be able to work as advertised…

Stefan


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

#98447
Mar 12, 2007 at 11:04am

>Kasper T Toeplitz schrieb:
>>but then no snapshot~ and no very short metros ( 5000 is not short, right ?)
>
>These are the scheduler killers anyway. You do not want to use shorter
>than 10 ms metros in scheduler. It’s already thought as audiorate, even
>if its slower than unaudible. Musical metros will go up to 64ths, and
>that’s already. And as I said before, snapshots~ do eat your non-audio
>rate cycles. Try to get rid of them or bang them rarely…
>
>This explains very well your problems… Its not the metro, its the way
>you treat it…
>
>>still, if talking about metro, i feel it does not sends a bang at
>>regular intervals. It does it sometimes, sometimes not. Which is
>>not how i would define regular, belive it
>
>It does so for me,
>but then if I overload my CPU I would not get a simple cycle~ put out a
>sine wave, it would crackle, though the manual states it puts out a sine…
>The same for scheduler overload, if I demand too much, none of any
>object will be able to work as advertised…
>

hi Stafan

sorry my answer was to be read

but then I USE no snapshot~ and USE no very short metros ( 5000 is
not short, right ? I MOSTLY USE LONG METROS, 1000 AND UP)

so thank you for your explainantion, but it does not explain my
problems. , Not at all (and i don’t overload my CPU, at least not
according to the activity monitor)

____

if you open the simple example i am sending (based on you own metro~
object) you can see that “timer” does not work very well (yes, i
know, it is the same thing than with metro – scheduler, osX etc..)

_if i suppose your metro~ works well (it should, since it is in the
audio domain) then the timer does not (the reported time is ALWAYS
superior to 1000

all the best

kasper

#P user multiSlider 97 217 174 118 1000. 1100. 1 3177 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P user ezdac~ 205 110 249 143 0;
#P window setfont “Sans Serif” 9.;
#P number 97 192 87 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 97 120 15 0;
#P window linecount 1;
#P newex 97 153 35 196617 timer;
#P toggle 97 66 15 0;
#P newex 97 97 70 196617 metro~ 1000;
#P connect 1 0 0 0;
#P fasten 1 0 5 0 102 89 210 89;
#P connect 4 0 6 0;
#P connect 3 0 2 0;
#P connect 3 0 2 1;
#P connect 0 0 3 0;
#P connect 2 0 4 0;
#P window clipboard copycount 7;

#98448
Mar 12, 2007 at 11:21am

Quote: Matthew Aidekman wrote on Sun, 11 March 2007 18:08
—————————————————-
> I know this is going to piss some people off, but Gregory Taylor once told me that PD had an option to make any patcher run at any sampling rate. More malulable sampling rates and datatypes really seems to be a common solution.

The event system in max is not sample based so the term sampling rate is not applicable to metro. Have a look at the docs about threading to find out more.

Mattijs

#98449
Mar 12, 2007 at 3:56pm

poor choice of words… it was a casual conversation.
apologies.

the point was that if the maxer could quantize time at different intervals for different applications, the problem would be solved.

I may be completely and utterly wrong about Senior Taylors implications.

#98450
Mar 12, 2007 at 8:13pm

#98451
Mar 12, 2007 at 10:49pm

Just for my 2 cents. I’ve been going through my own little slice of hell with Max lately, writing a patch that does much heavy lifting of relatively light object – that is, on basic midi info. It doesn’t use any metro objects, but it does send *lots* of messages, and I think what’s basically made my life hell is that the scheduler just can’t cope after a certain point. I realize that my mistake was in making a modular design that didn’t scale well to the number of instances I was ultimately after, so I’m going to have to rethink the modularity of the design. In that sense it’s definitley my fault.

But I would also have to say that, in my ten years experience, the scheduler has been a somewhat fragile beast. Most of what I’ve done over the past couple of years has been based on the idea of composing in real time for large ensemble and/or orchestra. And when the number of events reaches a certain point, Max gets really cranky. Timing goes for a wander (backlog), which starts a nasty process of the app basically tearing itself apart. In the past I’ve either given up, or slowly designed my way to working solutions. But on a purely superficial level, in the sense of looking at the patches in terms of what each object/external/abstraction is documented to do, how messages logically flow from one to the next, and given the basic principles of how Max works, these apps have not been incorrectly designed. Inefficiently, perhaps. But not incorrectly. So, in a sense, they ‘should’ have worked. And I think that’s the basic frustration with the so called ‘wandering’ metro. You could work your way around it with a deeper understanding of how the system uses Max. But that is actually beyond the scope of what the Max objects themselves claim to do. So, in a sense, it’s correct to say that the metro wanders, and it’s also correct to say that “used properly” it doesn’t. The question is whether or not using it properly should require more than a solid understanding of the documented functions of the built-in Max objects.

J.

Quote: Kasper T Toeplitz wrote on Sat, 10 March 2007 18:23
—————————————————-
> >
> >
> >> i wish the one in max would work as it is supposed to. It does not,
> >
> >I can’t believe that you keep insisting that metro doesn’t work
> >correctly if so many experienced people repeat over and over that
> >there’s nothing wrong with it.
>
>
> ok, i know (now) about all the reasons, blablabla, scheduler, osX,
> all those things
>
> but even if experienced people repeat over and over that all is fine
> when i read in the ref manual “. At regular intervals,
> metro sends a bang out the outlet.”
>
> and my metro does not send a bang at REGULAR intervals (unless you
> say than anything in the 1000-1300 range is regular) – that’s why I
> keep insisting it is not working correctly.
>
> I learned how NOT to use this object to do what i want (all my
> patches have a time counter – I used to use a metro to drive them,
> now i use other things, audio domain). But it seems to me it is not
> working as it says it would.
>
> G Taylor talks about samm~, there is metro~ etc… still, if talking
> about metro, i feel it does not sends a bang at regular intervals. It
> does it sometimes, sometimes not. Which is not how i would define
> regular, belive it
>
> all the best
>
> kasper
> —
> Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
>
>
—————————————————-

#98452
Mar 13, 2007 at 5:52am

How about seq~? While two dimensions wouldn’t be enough to represent a
list, seq~ is a great help for looping control-rate events.

>
> ok… heres a FAR FAR out solution.
>
> IF you had a matrix whose width was the vector size, and height was
> 1. then you could represent bangs and/or integers in audio rate.
>
> if you made it 2 dimensional, you could represent any max message at
> audio rate.
>
> if someone (**NOT ME**) wrote some objects on that principal, you
> could have audio rate max messages.
>
> whoa.
>
>
> I know this is going to piss some people off, but Gregory Taylor once
> told me that PD had an option to make any patcher run at any sampling
> rate. More malulable sampling rates and datatypes really seems to be
> a common solution.
>
>
http://www.petermcculloch.com

#98453
Mar 13, 2007 at 9:41am

Quote: jbm wrote on Mon, 12 March 2007 23:49
—————————————————-
> You could work your way around it with a deeper understanding of how the system uses Max.

-And- a deeper understanding of how Max uses the system. But that’s not working around, that’s using properly.

> But that is actually beyond the scope of what the Max objects themselves claim to do.

I agree, but only if max objects claim to be black boxes. And yes, their graphic representation strongly suggests this. But they are not, at least not when things get serious.

> So, in a sense, it’s correct to say that the metro wanders, and it’s also correct to say that “used properly” it doesn’t. The question is whether or not using it properly should require more than a solid understanding of the documented functions of the built-in Max objects.

Couldn’t have said it better. And I can answer that question: if you don’t have the level of understanding of an audio software engineer, you are going to run into trouble sooner of later. Probably later, but still.

Mattijs

#98454
Mar 13, 2007 at 11:50am

Quote: andrewb@cycling74.com wrote on Thu, 08 March 2007 18:03
—————————————————-
> To clarify, Max doesn’t really make too many assumptions about what you
> are – musician, artist, civil engineer, interaction designer, video
> artist, VJ, etc. You get to decide what MaxMSP is for.
>
> Happy Patching,
> Andrew B.
>
—————————————————-

Hi Andrew,

I think you are right to keep this open. But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.

You’ll probably agree that it’s really hard for someone without a technical background to successfully complete an interactive installation or a software synthesizer or even to sync a few loops in Max. Not only because you need a certain level of technical skill but also because you need certain basic knowledge about how the OS works, how a computer program utilizes resources, what are possible bottlenecks, how threads work, in general stuff that you learn in a computer-oriented education.

And I suspect that this is not always clear to everyone. In a way Max is a dream for a lot of people that feel that they’re never going to learn enough of C++ to make their own software from scratch. In a lot of cases this dream is shattered when the project gets more serious. It would be good if the expectations would match a little better with practice.

In my opinion easy accessible basic courses about computer programming aimed towards the different target audiences that you mention above, that has people realise the limits that come with different backgrounds and limitations in experience and knowledge, could do wonders.

Best,
Mattijs

#98455
Mar 13, 2007 at 12:27pm

Quote: Mattijs wrote on Tue, 13 March 2007 11:50
—————————————————-
> Quote: andrewb@cycling74.com wrote on Thu, 08 March 2007 18:03
> —————————————————-
> > To clarify, Max doesn’t really make too many assumptions about what you
> > are – musician, artist, civil engineer, interaction designer, video
> > artist, VJ, etc. You get to decide what MaxMSP is for.
> >
> > Happy Patching,
> > Andrew B.
> >
> —————————————————-
>
> Hi Andrew,
>
> I think you are right to keep this open. But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.
>
> You’ll probably agree that it’s really hard for someone without a technical background to successfully complete an interactive installation or a software synthesizer or even to sync a few loops in Max. Not only because you need a certain level of technical skill but also because you need certain basic knowledge about how the OS works, how a computer program utilizes resources, what are possible bottlenecks, how threads work, in general stuff that you learn in a computer-oriented education.
>
> And I suspect that this is not always clear to everyone. In a way Max is a dream for a lot of people that feel that they’re never going to learn enough of C++ to make their own software from scratch. In a lot of cases this dream is shattered when the project gets more serious. It would be good if the expectations would match a little better with practice.
>
> In my opinion easy accessible basic courses about computer programming aimed towards the different target audiences that you mention above, that has people realise the limits that come with different backgrounds and limitations in experience and knowledge, could do wonders.
>
>

I wonder if there might be some way of making a more user-friendly, and interactive debugging system. Maybe some sort of set of graphical “gauges” which would give us a sort of bird’s-eye view on how our apps are using existing resources. Kind of like “top” or the Activity Monitor, but strictly *within* Max. For example, such a gauge could be made to reflect the relative work load, over time, of the audio thread, scheduler thread, and maybe even any java thread(s). Perhaps a system of thresholds could even be devised, whereby any gauge that read over a certain level would pop open the patcher/subpatcher which was introducing the bottleneck(?) I don’t know… maybe that’s just goofy. But something along those lines would be really helpful, I think. And as a side-benefit, it would give those with less background in computers a quick and intuitive way of learning about where problems tend to occur.
Does that sound possible?

J.

#98456
Mar 13, 2007 at 3:53pm

> Mattijs Kneppers said:
> But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.
I understand your frustration, but most of us here lack any kind of
“technical background”. Granted, using Max will eventually trick you
into learning the kinds of computer science things you thought you were
avoiding by going to art school. At least, that has been my experience.

That said, I agree that we could do more in this area. In case you
hadn’t noticed, we have been updating the website pretty regularly with
rather specific articles and tutorials that attempt to service the needs
left unserved by our documentation. We know that it is not totally
comprehensive at this point, but these things take a bit of time. As an
example, check out the tutorial I just posted on using joysticks and HID
devices in Max:

http://cycling74.com/story/2007/3/12/113645/135

…or Darwin Grosse’s thorough set of Rewire tutorials.

If those of you in the community find an area that is lacking in our
documentation, feel free to add an article to Vade’s wiki, publish a
tutorial on your own site, post a thread to the forum, or contact us and
see if we’ll post your article.

For anyone who is unclear about how the scheduler and queue work in Max,
I highly recommend JKC’s rather elucidating article here:

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

Cheers,
Andrew Benson

#98457
Mar 13, 2007 at 5:36pm

Quote: andrewb@cycling74.com wrote on Tue, 13 March 2007 16:53
—————————————————-
>
> > Mattijs Kneppers said:
> > But the reactions to these threads seem to call for guides of some sorts for people with various backgrounds.

> I understand your frustration, but most of us here lack any kind of
> “technical background”.

Oh, but it’s really not a matter of frustration. I just feel sincerely sorry for all the great people out there working with max, trying to work out ideas that I would love to see realised.

With the correct expectations their work would be so much more effective. When a vj with an art school background wants to make an interactive installation in max he could either choose to do it by himself and ultimately fail or ask the computer kid next door to take care of the technical stuff and end up with a tight installation with next level visuals. But he needs the proper information to make that decision.

> Granted, using Max will eventually trick you
> into learning the kinds of computer science things you thought you were
> avoiding by going to art school. At least, that has been my experience.

That’s right, as soon as your ideas get a little complex you do need this basic computer science to work with max effectively. It’s not bad that people are tricked into it (everybody should be a technician ;) but on the other hand perhaps, as illustrated above, it would be good to enable the user to make that decision for themselves. A few simple docs could help enormously (see below).

>
> That said, I agree that we could do more in this area. In case you
> hadn’t noticed, we have been updating the website pretty regularly with
> rather specific articles and tutorials that attempt to service the needs
> left unserved by our documentation. We know that it is not totally
> comprehensive at this point, but these things take a bit of time. As an
> example, check out the tutorial I just posted on using joysticks and HID
> devices in Max:
>
> http://cycling74.com/story/2007/3/12/113645/135
>
> …or Darwin Grosse’s thorough set of Rewire tutorials.

I definitly noticed the articles, they are great. I absolutely agree that this is the way to go to solve this problem.

>
> If those of you in the community find an area that is lacking in our
> documentation, feel free to add an article to Vade’s wiki, publish a
> tutorial on your own site, post a thread to the forum, or contact us and
> see if we’ll post your article.

Well, time for someone to stand up and fix this!

>
> For anyone who is unclear about how the scheduler and queue work in Max,
> I highly recommend JKC’s rather elucidating article here:
>
> http://cycling74.com/story/2005/5/2/133649/9742

Agreed. But unfortunately I also expect that without a level of technical experience you are probably not going to understand it, even though you do need this information desperately. I believe with this thread we’re not far from an article about syncronized looping that is easier accessible than core issues such as how the scheduler and queue work in max.

Best,
Mattijs

#98458
Mar 14, 2007 at 12:45am

That sounds beautiful! Models for display might include the ‘hotspot’
style web page traffic analysis tools and the various drive storage use
visualizers.

jbmaxwell wrote:
> I wonder if there might be some way of making a more user-friendly, and interactive debugging system. Maybe some sort of set of graphical “gauges” which would give us a sort of bird’s-eye view on how our apps are using existing resources. Kind of like “top” or the Activity Monitor, but strictly *within* Max. For example, such a gauge could be made to reflect the relative work load, over time, of the audio thread, scheduler thread, and maybe even any java thread(s). Perhaps a system of thresholds could even be devised, whereby any gauge that read over a certain level would pop open the patcher/subpatcher which was introducing the bottleneck(?) I don’t know… maybe that’s just goofy. But something along those lines would be really helpful, I think. And as a side-benefit, it would give those with less background in computers a quick and intuitive way of learning about where problems tend to occur.
> Does that sound possible?

#98459
Mar 14, 2007 at 2:27pm

Kasper T Toeplitz schrieb:
> _if i suppose your metro~ works well (it should, since it is in the
> audio domain) then the timer does not (the reported time is ALWAYS
> superior to 1000

For me its between 999 and 1001 with a vector size of 64, which is
exactly as expected. (less than 1.5 ms jitter as thats the duration of
the vector size if scheduler in audio interrupt is on)

The timer can only get its bang once a scheduler tick, but anytime
within that…

Stefan


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

#98460
Mar 17, 2007 at 9:31pm

Quote: dlurk wrote on Wed, 14 March 2007 01:45
—————————————————-
>
> That sounds beautiful! Models for display might include the ‘hotspot’
> style web page traffic analysis tools and the various drive storage use
> visualizers.
>

Uhh.. guys. Shall we just start with error messages in the max window that link to the objects that caused them?

Mattijs

#98461
Mar 17, 2007 at 9:39pm

Quote: Mattijs wrote on Sat, 17 March 2007 21:31
—————————————————-
> Quote: dlurk wrote on Wed, 14 March 2007 01:45
> —————————————————-
> >
> > That sounds beautiful! Models for display might include the ‘hotspot’
> > style web page traffic analysis tools and the various drive storage use
> > visualizers.
> >
>
> Uhh.. guys. Shall we just start with error messages in the max window that link to the objects that caused them?
>
> Mattijs
—————————————————-

hehe… yeah, okay. Fair enough!

#98462
Mar 17, 2007 at 10:19pm

Quote: Dayton wrote on Sat, 17 March 2007 21:40
—————————————————-
> Hi Mattijs,
>
> I always get into these things right when I am about to go travelling; this is the first time I got back to the forum. I’ll try your patch out when I get home, and thank you.
>
>
> Here is my stab at the problem; a basic patch and a subpatch to use in the poly.

Ok, I don’t want to sound too rude cause it seems that you put quite some time in it but I’m quite sure that you could this with less than 1/4 of the amount of objects.

My example doesn’t set the loop reference according to the recorded material but still I hope it’ll help to simplify your patch.

Cheers,
Mattijs

#98463
Mar 19, 2007 at 2:44pm

A little supplement: to sync a phasor~ at audio rate you can use this:

#P user hslider 184 260 10 122 128 1 0 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 184 240 41 196617 * 127.;
#P newex 184 221 70 196617 snapshot~ 40;
#P user hslider 26 260 10 122 128 1 0 0;
#P newex 26 240 41 196617 * 127.;
#P newex 26 221 70 196617 snapshot~ 40;
#P newex 104 36 75 196617 loadmess 0.15;
#P newex 26 36 69 196617 loadmess 0.1;
#P flonum 104 55 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 26 55 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 104 72 46 196617 phasor~;
#P newex 26 182 34 196617 +~ 1.;
#P newex 26 201 37 196617 %~ 1.;
#P newex 26 163 27 196617 -~;
#P newex 104 110 42 196617 ==~ -1;
#P newex 43 144 31 196617 sah~;
#P newex 104 91 46 196617 change~;
#P newex 26 72 46 196617 phasor~;
#P comment 152 73 62 196617 sync source;
#P connect 8 0 2 0;
#P connect 8 0 16 0;
#P connect 1 0 5 0;
#P connect 1 0 3 0;
#P connect 17 0 18 0;
#P connect 16 0 17 0;
#P connect 2 0 4 0;
#P connect 10 0 8 0;
#P connect 12 0 10 0;
#P connect 4 0 3 1;
#P connect 3 0 5 1;
#P connect 14 0 15 0;
#P connect 13 0 14 0;
#P connect 6 0 13 0;
#P connect 7 0 6 0;
#P connect 5 0 7 0;
#P connect 9 0 1 0;
#P connect 11 0 9 0;
#P window clipboard copycount 19;

Cheers,
Mattijs

#98464
Mar 20, 2007 at 1:46pm

very well put.
i share your over-scheduled pain.

On Mar 12, 2007, at 10:49 PM, jbmaxwell wrote:

>
> Just for my 2 cents. I’ve been going through my own little slice of
> hell with Max lately, writing a patch that does much heavy lifting
> of relatively light object – that is, on basic midi info. It
> doesn’t use any metro objects, but it does send *lots* of messages,
> and I think what’s basically made my life hell is that the
> scheduler just can’t cope after a certain point. I realize that my
> mistake was in making a modular design that didn’t scale well to
> the number of instances I was ultimately after, so I’m going to
> have to rethink the modularity of the design. In that sense it’s
> definitley my fault.
>
> But I would also have to say that, in my ten years experience, the
> scheduler has been a somewhat fragile beast. Most of what I’ve done
> over the past couple of years has been based on the idea of
> composing in real time for large ensemble and/or orchestra. And
> when the number of events reaches a certain point, Max gets really
> cranky. Timing goes for a wander (backlog), which starts a nasty
> process of the app basically tearing itself apart. In the past I’ve
> either given up, or slowly designed my way to working solutions.
> But on a purely superficial level, in the sense of looking at the
> patches in terms of what each object/external/abstraction is
> documented to do, how messages logically flow from one to the next,
> and given the basic principles of how Max works, these apps have
> not been incorrectly designed. Inefficiently, perhaps. But not
> incorrectly. So, in a sense, they ‘should’ have worked. And I think
> that’s the basic frustration with the so called ‘wandering’ metro.
> You cou!
> ld work your way around it with a deeper understanding of how the
> system uses Max. But that is actually beyond the scope of what the
> Max objects themselves claim to do. So, in a sense, it’s correct to
> say that the metro wanders, and it’s also correct to say that “used
> properly” it doesn’t. The question is whether or not using it
> properly should require more than a solid understanding of the
> documented functions of the built-in Max objects.
>
> J.

#98465
Mar 20, 2007 at 2:22pm

Just curious: do (you think) you know exactly how the scheduler works? E.g. did you read jkc’s article about threading in max?

- Mattijs

Quote: lists@lowfrequency.or wrote on Tue, 20 March 2007 14:46
—————————————————-
> very well put.
> i share your over-scheduled pain.
>
>
> On Mar 12, 2007, at 10:49 PM, jbmaxwell wrote:
>
> >
> > Just for my 2 cents. I’ve been going through my own little slice of
> > hell with Max lately, writing a patch that does much heavy lifting
> > of relatively light object – that is, on basic midi info. It
> > doesn’t use any metro objects, but it does send *lots* of messages,
> > and I think what’s basically made my life hell is that the
> > scheduler just can’t cope after a certain point. I realize that my
> > mistake was in making a modular design that didn’t scale well to
> > the number of instances I was ultimately after, so I’m going to
> > have to rethink the modularity of the design. In that sense it’s
> > definitley my fault.
> >
> > But I would also have to say that, in my ten years experience, the
> > scheduler has been a somewhat fragile beast. Most of what I’ve done
> > over the past couple of years has been based on the idea of
> > composing in real time for large ensemble and/or orchestra. And
> > when the number of events reaches a certain point, Max gets really
> > cranky. Timing goes for a wander (backlog), which starts a nasty
> > process of the app basically tearing itself apart. In the past I’ve
> > either given up, or slowly designed my way to working solutions.
> > But on a purely superficial level, in the sense of looking at the
> > patches in terms of what each object/external/abstraction is
> > documented to do, how messages logically flow from one to the next,
> > and given the basic principles of how Max works, these apps have
> > not been incorrectly designed. Inefficiently, perhaps. But not
> > incorrectly. So, in a sense, they ‘should’ have worked. And I think
> > that’s the basic frustration with the so called ‘wandering’ metro.
> > You cou!
> > ld work your way around it with a deeper understanding of how the
> > system uses Max. But that is actually beyond the scope of what the
> > Max objects themselves claim to do. So, in a sense, it’s correct to
> > say that the metro wanders, and it’s also correct to say that “used
> > properly” it doesn’t. The question is whether or not using it
> > properly should require more than a solid understanding of the
> > documented functions of the built-in Max objects.
> >
> > J.
>
>
—————————————————-

#98466
Mar 20, 2007 at 3:11pm

Quote: Mattijs wrote on Tue, 20 March 2007 14:22
—————————————————-
> Just curious: do (you think) you know exactly how the scheduler works? E.g. did you read jkc’s article about threading in max?
>
> – Mattijs
>

I do “think” I know how the scheduler works, and yes I’ve read that article, and pretty much every other description of it I’ve found over the past 10 years. In fact, I just read it again, and I can say the same thing I said the last time I read it: what appears to be happening whenever I kill the scheduler is event backlog. Unfortunately, these are not patches that can accept any kind of speedlim procedure, since all the messaging that’s going on is in some way essential to the process. Is it a case of bad or just overly-ambitious programming on my part? Quite possibly. On the bright side, my most recent project has enjoyed a great improvement in stability by a minor redesign which greatly reduced the number of messages crossing the max/java bridge. What can I say? I try. Perhaps the biggest problem, in my case, is that most of the things I want to do with it are kind beyond my ability to realize, when I first dream them up. However, in my defense, the “little boxes” dimension of Max (i.e., Max as an application) makes my ideas seem achievable, whereas the underbelly of Max (i.e., the scheduler, queue, threads – Max as an IDE) sometimes drops the reality down squarely on my head. That’s the best I can do to explain my situation, and I’ve already said too much.

J.

#98467
Mar 20, 2007 at 4:30pm

Ok, that’s interesting. It seems like there are a lot of people screaming that stuff doesn’t work correctly while they don’t know what it is supposed to do, hence my question. (btw I understand the screaming, but it shouldn’t be about the system but about lack of documentation or perhaps about max not meeting their expectations in general, as I said earlier in this thread).

But since you are aware of the supposed behaviour, I’ve been thinking about what you could possibly mean with a backlog problem. I personally didn’t find any issues with the scheduler. Of course there will be backlog if your cpu can’t cope with the amount of events, but that is expected behaviour, right? Or do you mean that the permitted slop doesn’t work correctly? Or do you expect max to use the cpu more efficient and handle more events? It would be great if you were able to make a patch that demonstrates the issues you encounter.

Btw, cycling 74, there is a typo in the Scheduler slop ‘About’ in Performance options: “Typcially some amount of slop is desired so that..”

Cheers,
Mattijs

Quote: jbm wrote on Tue, 20 March 2007 16:11
—————————————————-
> Quote: Mattijs wrote on Tue, 20 March 2007 14:22
> —————————————————-
> > Just curious: do (you think) you know exactly how the scheduler works? E.g. did you read jkc’s article about threading in max?
> >
> > – Mattijs
> >
>
> I do “think” I know how the scheduler works, and yes I’ve read that article, and pretty much every other description of it I’ve found over the past 10 years. In fact, I just read it again, and I can say the same thing I said the last time I read it: what appears to be happening whenever I kill the scheduler is event backlog. Unfortunately, these are not patches that can accept any kind of speedlim procedure, since all the messaging that’s going on is in some way essential to the process. Is it a case of bad or just overly-ambitious programming on my part? Quite possibly. On the bright side, my most recent project has enjoyed a great improvement in stability by a minor redesign which greatly reduced the number of messages crossing the max/java bridge. What can I say? I try. Perhaps the biggest problem, in my case, is that most of the things I want to do with it are kind beyond my ability to realize, when I first dream them up. However, in my defense, the “little boxes” dimension of Max (i.e., Max as an application) makes my ideas seem achievable, whereas the underbelly of Max (i.e., the scheduler, queue, threads – Max as an IDE) sometimes drops the reality down squarely on my head. That’s the best I can do to explain my situation, and I’ve already said too much.
>
> J.
—————————————————-

#98468
Mar 20, 2007 at 4:44pm

Quote: Mattijs wrote on Tue, 20 March 2007 16:30
—————————————————-
> Ok, that’s interesting. It seems like there are a lot of people screaming that stuff doesn’t work correctly while they don’t know what it is supposed to do, hence my question. (btw I understand the screaming, but it shouldn’t be about the system but about lack of documentation or perhaps about max not meeting their expectations in general, as I said earlier in this thread).
>
> But since you are aware of the supposed behaviour, I’ve been thinking about what you could possibly mean with a backlog problem. I personally didn’t find any issues with the scheduler. Of course there will be backlog if your cpu can’t cope with the amount of events, but that is expected behaviour, right? Or do you mean that the permitted slop doesn’t work correctly? Or do you expect max to use the cpu more efficient and handle more events? It would be great if you were able to make a patch that demonstrates the issues you encounter.
>

Well, my cpu is a G5 dual 1.8, and I’m just dealing with midi data, so I’m always a bit stumped when I run into problems. Coincidentally, I’ve just had a quick exchange of dialog with a friend who does similar work to myself, and who has similar backlog problems in Max. It turns out that he’s been able to solve the majority of his issues with the liberal use of deferlows. Of course, this implies that the issue was thread related, not necessarily backlog… or maybe it’s some sort of backlog happening on the high-priority thread? Not sure. Anyway, it was encouraging. I know I’ve managed to solve some of my problems in the past with deferlows. But in those cases it followed logically as a possible solution. My more recent problems don’t appear to be related. Anyway, part of the reason I also mentioned the more detailed debugging system is that I don’t honestly know with absolute certainty that backlog is the issue. I suspect it is, but I don’t know for certain. But, in my experience, when Max gets the spinning ball, then quits, it’s usually backlog.

I’m heading out of town for a couple of weeks – a *much* needed break – so perhaps I’ll return with a clear(er) head and work these problems out. If I can’t solve it, I’ll definitely try to make a patch to demonstrate.

cheers,

J.

#98469
Mar 20, 2007 at 5:36pm

>>part of the reason I also mentioned the more detailed debugging
>>system is that I don’t honestly know with absolute certainty that
>>backlog is the issue.

FWIW, this is one of the things we have been discussing as a potential
aspect of the Max 5 trajectory.

Cheers,
Andrew B.

#98470
Mar 20, 2007 at 6:33pm

Quote: andrewb@cycling74.com wrote on Tue, 20 March 2007 18:36
—————————————————-
> FWIW, this is one of the things we have been discussing as a potential
> aspect of the Max 5 trajectory.
>
> Cheers,
> Andrew B.
>
—————————————————-

Boy, I have sooo much ideas about this. But you guys probably have enough ideas to consider.

Mattijs

#98471
Mar 20, 2007 at 6:58pm

Ok, just to make sure I understand: you don’t think something is wrong with the scheduler, the backlog probably makes sense in your situation but there is no real way for you to find out.

I agree about that. To find bugs or sort out strange behaviour I currently spend -a lot- of time making all sort of strange patches, solely to find out why an object or combination of objects behave as they do.

Sometimes I wonder, will Cycling ’74 go the same way as Macromedia, with Flash? First they make a nice tool which fills a gap in the market but is no serious development tool. Slowly it appears that people take the whole thing pretty serious and to make the concept complete, more control and flexibilty is needed so they invest in actionscript. After a while the gap in the market appears to be much bigger than they anticipated (developers start using it as a main development tool for projects where big cash is involved), so actionscript suddenly needs to match some deadly serious requirements to satify the needs of the increasing amount of pro users, even though the original aim wasn’t even close to this trajectory. Now (only just in actionscript 3!!), they include the ‘strict’ mode, a mega-essential feature for the huge professional userbase that in the meanwhile came into existence. This means that for the first time since Flash was born, debugging became a serious matter.

Funny, eh?

Mattijs

Quote: jbm wrote on Tue, 20 March 2007 17:44
—————————————————-
> Well, my cpu is a G5 dual 1.8, and I’m just dealing with midi data, so I’m always a bit stumped when I run into problems. Coincidentally, I’ve just had a quick exchange of dialog with a friend who does similar work to myself, and who has similar backlog problems in Max. It turns out that he’s been able to solve the majority of his issues with the liberal use of deferlows. Of course, this implies that the issue was thread related, not necessarily backlog… or maybe it’s some sort of backlog happening on the high-priority thread? Not sure. Anyway, it was encouraging. I know I’ve managed to solve some of my problems in the past with deferlows. But in those cases it followed logically as a possible solution. My more recent problems don’t appear to be related. Anyway, part of the reason I also mentioned the more detailed debugging system is that I don’t honestly know with absolute certainty that backlog is the issue. I suspect it is, but I don’t know for certain. But, in my experience, when Max gets the spinning ball, then quits, it’s usually backlog.
>
> I’m heading out of town for a couple of weeks – a *much* needed break – so perhaps I’ll return with a clear(er) head and work these problems out. If I can’t solve it, I’ll definitely try to make a patch to demonstrate.
>
> cheers,
>
> J.
—————————————————-

#98472
Mar 20, 2007 at 7:53pm

On Mar 20, 2007, at 2:58 PM, Mattijs Kneppers wrote:

>
> Ok, just to make sure I understand: you don’t think something is
> wrong with the scheduler, the backlog probably makes sense in your
> situation but there is no real way for you to find out.
>
> I agree about that. To find bugs or sort out strange behaviour I
> currently spend -a lot- of time making all sort of strange patches,
> solely to find out why an object or combination of objects behave
> as they do.
>
> Sometimes I wonder, will Cycling ’74 go the same way as Macromedia,
> with Flash? First they make a nice tool which fills a gap in the
> market but is no serious development tool. Slowly it appears that
> people take the whole thing pretty serious and to make the concept
> complete, more control and flexibilty is needed so they invest in
> actionscript. After a while the gap in the market appears to be
> much bigger than they anticipated (developers start using it as a
> main development tool for projects where big cash is involved), so
> actionscript suddenly needs to match some deadly serious
> requirements to satify the needs of the increasing amount of pro
> users, even though the original aim wasn’t even close to this
> trajectory. Now (only just in actionscript 3!!), they include the
> ‘strict’ mode, a mega-essential feature for the huge professional
> userbase that in the meanwhile came into existence. This means that
> for the first time since Flash was born, debugging became a serious
> matter.
>
> Funny, eh?
>
> Mattijs

I for one, would love this sort of trajectory…

v a d e //

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

#98473
Mar 20, 2007 at 7:57pm

> This means that for the first time since Flash was born, debugging
became a serious matter.

I believe that this is _exactly_ what has happened with Max – it has
evolved to a point that I’m sure was never imagined.

Without a doubt, its the best tool to prototype and develop interactive
systems. But many of us are so comfortable in Max, that we are using
it to build systems that were formerly the domain of procedural
languages.

And I guess we’re asking for some of the tools that those languages
have…

#98474
Mar 20, 2007 at 8:06pm

> Coincidentally, I’ve just had a quick exchange of dialog with a
> friend who does similar work to myself, and who has similar
backlog
> problems in Max. It turns out that he’s been able to solve the
> majority of his issues with the liberal use of deferlows.

Hey, that would be me!

Not being a “real” programmer, I can’t profess to understand the
scheduler completely. But what I can infer is that events triggered
by a bang operate at some sort of an interupt level. Unlike audio, a
fixed number of Max instructions are not pre-scheduled, so when
the instructions pile up and other matters cannot be attended, Max
coughs (the stack overflow dialog, or worse, the dreaded spinning
ball).

By putting the defer or deferlow object in strategic places, I’ve
avoided both.

In the example below, note that the left part causes a stack
overflow, whereas the right one does not.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 260 53 57 196617 Happiness!;
#P newex 264 135 50 196617 deferlow;
#P button 264 78 15 0;
#P newex 264 160 20 196617 t b;
#N counter;
#X flags 0 0;
#P newobj 264 107 66 196617 counter;
#P button 168 78 15 0;
#P newex 168 160 20 196617 t b;
#N counter;
#X flags 0 0;
#P newobj 168 107 66 196617 counter;
#P comment 152 52 82 196617 Stack overflow!;
#P connect 1 0 2 0;
#P fasten 5 0 4 0 269 184 249 184 249 103 269 103;
#P connect 6 0 4 0;
#P connect 7 0 5 0;
#P connect 4 0 7 0;
#P connect 3 0 1 0;
#P fasten 2 0 1 0 173 184 153 184 153 100 173 100;
#P window clipboard copycount 9;

This is probably old news to most people….

#98475
Mar 20, 2007 at 8:13pm

in regards to error debugging…., part of the beauty of debugging in max is that is almost exclusively manual. it really makes you mentally visualize your flow and think about what’s going wrong. I don’t know why anyone would want otherwise. But i realize I’m probably the minority here.

just say no to brainless over-efficiency.

#98476
Mar 20, 2007 at 8:21pm

Erm.

You are creating a feedback loop there on the first one. Thats your
problem : throw in a delay, or a pipe, or something, I think the
deferlow there ‘fixing’ it is more of a fluke and not appropriate (at
least in my somewhat inadequate understanding of the scheduler
underpinnings).

On Mar 20, 2007, at 4:06 PM, Arne Eigenfeldt wrote:

>
>> Coincidentally, I’ve just had a quick exchange of dialog with a
>> friend who does similar work to myself, and who has similar
> backlog
>> problems in Max. It turns out that he’s been able to solve the
>> majority of his issues with the liberal use of deferlows.
>
> Hey, that would be me!
>
> Not being a “real” programmer, I can’t profess to understand the
> scheduler completely. But what I can infer is that events triggered
> by a bang operate at some sort of an interupt level. Unlike audio, a
> fixed number of Max instructions are not pre-scheduled, so when
> the instructions pile up and other matters cannot be attended, Max
> coughs (the stack overflow dialog, or worse, the dreaded spinning
> ball).
>
> By putting the defer or deferlow object in strategic places, I’ve
> avoided both.
>
> In the example below, note that the left part causes a stack
> overflow, whereas the right one does not.
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P comment 260 53 57 196617 Happiness!;
> #P newex 264 135 50 196617 deferlow;
> #P button 264 78 15 0;
> #P newex 264 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 264 107 66 196617 counter;
> #P button 168 78 15 0;
> #P newex 168 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 168 107 66 196617 counter;
> #P comment 152 52 82 196617 Stack overflow!;
> #P connect 1 0 2 0;
> #P fasten 5 0 4 0 269 184 249 184 249 103 269 103;
> #P connect 6 0 4 0;
> #P connect 7 0 5 0;
> #P connect 4 0 7 0;
> #P connect 3 0 1 0;
> #P fasten 2 0 1 0 173 184 153 184 153 100 173 100;
> #P window clipboard copycount 9;
>
> This is probably old news to most people….

v a d e //

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

#98477
Mar 20, 2007 at 8:24pm

being able to set breakpoints or to have trace selectively triggered
would be a welcome addition. That is not brainless or over-efficient,
it is a functional addition that every other programming environment
has had since the inception of programming. (not a rag on max btw,
just a statement)

On Mar 20, 2007, at 4:13 PM, jamez wrote:

>
> in regards to error debugging…., part of the beauty of debugging
> in max is that is almost exclusively manual. it really makes you
> mentally visualize your flow and think about what’s going wrong. I
> don’t know why anyone would want otherwise. But i realize I’m
> probably the minority here.
>
> just say no to brainless over-efficiency.

v a d e //

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

#98478
Mar 20, 2007 at 8:28pm

On 20 mars 07, at 21:06, Arne Eigenfeldt wrote:

> This is probably old news to most people….

I won’t say that second version *works*, even if by “works” you mean
it doesn’t crash. I mean if you really want to count as fast as
possible, [uzi] is the object made for that. In normal life, you’ll
quite never have to use [deferlow].

ej

#98479
Mar 20, 2007 at 8:32pm

It’s not a feedback loop, but an infinite counter. Why shouldn’t it work – I’m simply asking the computer to count as high as it can, as fast as it can?

The second version doesn’t change that – it simply allows Max to “take a breath” while counting.

Obviously, one would never use deferlow in such a case – it’s simply a simple demonstration (to my mind) on how it can stop Max from choking.

#98480
Mar 20, 2007 at 8:50pm

Quote: arne wrote on Tue, 20 March 2007 21:06
—————————————————-
> But what I can infer is that events triggered
> by a bang operate at some sort of an interupt level. Unlike audio, a
> fixed number of Max instructions are not pre-scheduled, so when
> the instructions pile up and other matters cannot be attended, Max
> coughs (the stack overflow dialog, or worse, the dreaded spinning
> ball).

I.. don’t think this is what jbm’s problem is about. Have a look at the in-depth article about queue and scheduler to find out more. It’s really interesting info even if you’re not a programmer.

I’m afraid there is more to this than liberally placing deferlows, jbm..

Mattijs

>
> By putting the defer or deferlow object in strategic places, I’ve
> avoided both.
>
> In the example below, note that the left part causes a stack
> overflow, whereas the right one does not.
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P comment 260 53 57 196617 Happiness!;
> #P newex 264 135 50 196617 deferlow;
> #P button 264 78 15 0;
> #P newex 264 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 264 107 66 196617 counter;
> #P button 168 78 15 0;
> #P newex 168 160 20 196617 t b;
> #N counter;
> #X flags 0 0;
> #P newobj 168 107 66 196617 counter;
> #P comment 152 52 82 196617 Stack overflow!;
> #P connect 1 0 2 0;
> #P fasten 5 0 4 0 269 184 249 184 249 103 269 103;
> #P connect 6 0 4 0;
> #P connect 7 0 5 0;
> #P connect 4 0 7 0;
> #P connect 3 0 1 0;
> #P fasten 2 0 1 0 173 184 153 184 153 100 173 100;
> #P window clipboard copycount 9;
>
> This is probably old news to most people….
>

#98481
Mar 20, 2007 at 8:51pm

Er, I think that is a feedback look as far as Max is concerned
because it tries to do this within one scheduler tick, all of it,
counting to infinity within one scheduler ‘tock’ is not to be taken
lightly and is, for all intents and purposes a feedback look
logically patch wise, as how you have your patch set up certainly
looks like a feedback look to me.

As Emmanuel said : use uzi, or just use counter with no argument and
bang it via metro 1 or something.

On Mar 20, 2007, at 4:32 PM, Arne Eigenfeldt wrote:

>
> It’s not a feedback loop, but an infinite counter. Why shouldn’t it
> work – I’m simply asking the computer to count as high as it can,
> as fast as it can.
>
> The second version doesn’t change that – it simply allows Max to
> “take a breath” between while counting.
>
> Obviously, one would never use deferlow in such a case – it’s
> simply a simple demonstration (to my mind) on how it can stop Max
> from choking.

v a d e //

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

#98482
Mar 20, 2007 at 8:51pm

Quote: vade wrote on Tue, 20 March 2007 20:53
—————————————————-
> > Sometimes I wonder, will Cycling ’74 go the same way as Macromedia,
> > with Flash? First they make a nice tool which fills a gap in the
> > market but is no serious development tool. Slowly it appears that
> > people take the whole thing pretty serious and to make the concept
> > complete, more control and flexibilty is needed so they invest in
> > actionscript. After a while the gap in the market appears to be
> > much bigger than they anticipated (developers start using it as a
> > main development tool for projects where big cash is involved), so
> > actionscript suddenly needs to match some deadly serious
> > requirements to satify the needs of the increasing amount of pro
> > users, even though the original aim wasn’t even close to this
> > trajectory. Now (only just in actionscript 3!!), they include the
> > ‘strict’ mode, a mega-essential feature for the huge professional
> > userbase that in the meanwhile came into existence. This means that
> > for the first time since Flash was born, debugging became a serious
> > matter.
> >
> > Funny, eh?
> >
> > Mattijs
>
> I for one, would love this sort of trajectory…

Me too!

Mattijs

#98483
Mar 20, 2007 at 9:05pm

sorry I am in budapest and still suffering from jet lag and uh, beer.
feel free to replace look and loop when appropriate *wink*

On Mar 20, 2007, at 4:51 PM, vade wrote:

> Er, I think that is a feedback look as far as Max is concerned
> because it tries to do this within one scheduler tick, all of it,
> counting to infinity within one scheduler ‘tock’ is not to be taken
> lightly and is, for all intents and purposes a feedback look
> logically patch wise, as how you have your patch set up certainly
> looks like a feedback look to me.
>
> As Emmanuel said : use uzi, or just use counter with no argument
> and bang it via metro 1 or something.
>
> On Mar 20, 2007, at 4:32 PM, Arne Eigenfeldt wrote:
>
>>
>> It’s not a feedback loop, but an infinite counter. Why shouldn’t
>> it work – I’m simply asking the computer to count as high as it
>> can, as fast as it can.
>>
>> The second version doesn’t change that – it simply allows Max to
>> “take a breath” between while counting.
>>
>> Obviously, one would never use deferlow in such a case – it’s
>> simply a simple demonstration (to my mind) on how it can stop Max
>> from choking.
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

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

#98484
Mar 20, 2007 at 9:22pm

Quote: jamez wrote on Tue, 20 March 2007 21:13
—————————————————-
> in regards to error debugging…., part of the beauty of debugging in max is that is almost exclusively manual. it really makes you mentally visualize your flow and think about what’s going wrong. I don’t know why anyone would want otherwise. But i realize I’m probably the minority here.
>
> just say no to brainless over-efficiency.
—————————————————-

I don’t agree. From a certain point you know exactly what you are doing, mentally visualizing everything in the slightest detail, but some other max object has an unexpected behaviour and you just don’t feel like restarting the patch and/or max everytime you need to make another step in the debugging process. I had another one of those yesterday deleting content of bpatchers with script. I’ll try to post the bugreport tomorrow.

Mattijs

#98485
Mar 20, 2007 at 9:24pm

> I mean if you really want to count as fast as
> possible, [uzi] is the object made for that.

It wasn’t about counting. The point I was trying to make is that you
can create “a feedback loop” (as Vade would call) by asking Max to
do too much in a scheduler cycle.

For example, this type of programming can cause stack overflows
(without any feedback loops):

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N vpatcher 20 74 620 474;
#P inlet 62 52 15 0;
#P pop;
#P newobj 107 118 103 196617 p do_something_else;
#N vpatcher 20 74 620 474;
#P inlet 62 52 15 0;
#P pop;
#P newobj 127 91 79 196617 p do_something;
#P button 107 35 15 0;
#P newex 107 61 30 196617 t b b;
#P connect 0 0 3 0;
#P connect 0 1 2 0;
#P connect 1 0 0 0;
#P window clipboard copycount 4;

Simply changing the structure to this format eliminates those stack
overflows:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 107 96 50 196617 deferlow;
#N vpatcher 20 74 620 474;
#P inlet 62 52 15 0;
#P pop;
#P newobj 107 118 103 196617 p do_something_else;
#N vpatcher 20 74 620 474;
#P outlet 63 101 15 0;
#P inlet 62 52 15 0;
#P pop;
#P newobj 107 75 79 196617 p do_something;
#P button 107 35 15 0;
#P connect 3 0 2 0;
#P connect 1 0 3 0;
#P connect 0 0 1 0;
#P window clipboard copycount 4;

#98486
Mar 20, 2007 at 9:27pm

Quote: vade wrote on Tue, 20 March 2007 13:24
—————————————————-
> being able to set breakpoints or to have trace selectively triggered
> would be a welcome addition. That is not brainless or over-efficient,
> it is a functional addition that every other programming environment
> has had since the inception of programming. (not a rag on max btw,
> just a statement)
>
> On Mar 20, 2007, at 4:13 PM, jamez wrote:
>
> >
> > in regards to error debugging…., part of the beauty of debugging
> > in max is that is almost exclusively manual. it really makes you
> > mentally visualize your flow and think about what’s going wrong. I
> > don’t know why anyone would want otherwise. But i realize I’m
> > probably the minority here.
> >
> > just say no to brainless over-efficiency.
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>
—————————————————-

I agree with this. Trace is useless in big patches, or patches with any timed events like metro.

#98487
Mar 20, 2007 at 9:49pm

well, knowing what is in those do_something patches would make all
the difference in the world. I know you know this, but those patches
really dont say much (to me at least).

On Mar 20, 2007, at 5:24 PM, Arne Eigenfeldt wrote:

>> I mean if you really want to count as fast as
>> possible, [uzi] is the object made for that.
>
> It wasn’t about counting. The point I was trying to make is that you
> can create “a feedback loop” (as Vade would call) by asking Max to
> do too much in a scheduler cycle.
>
> For example, this type of programming can cause stack overflows
> (without any feedback loops):
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #N vpatcher 20 74 620 474;
> #P inlet 62 52 15 0;
> #P pop;
> #P newobj 107 118 103 196617 p do_something_else;
> #N vpatcher 20 74 620 474;
> #P inlet 62 52 15 0;
> #P pop;
> #P newobj 127 91 79 196617 p do_something;
> #P button 107 35 15 0;
> #P newex 107 61 30 196617 t b b;
> #P connect 0 0 3 0;
> #P connect 0 1 2 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 4;
>
> Simply changing the structure to this format eliminates those stack
> overflows:
>
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P newex 107 96 50 196617 deferlow;
> #N vpatcher 20 74 620 474;
> #P inlet 62 52 15 0;
> #P pop;
> #P newobj 107 118 103 196617 p do_something_else;
> #N vpatcher 20 74 620 474;
> #P outlet 63 101 15 0;
> #P inlet 62 52 15 0;
> #P pop;
> #P newobj 107 75 79 196617 p do_something;
> #P button 107 35 15 0;
> #P connect 3 0 2 0;
> #P connect 1 0 3 0;
> #P connect 0 0 1 0;
> #P window clipboard copycount 4;

v a d e //

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

#98488
Mar 21, 2007 at 1:24am

#98489
Mar 21, 2007 at 4:09am

Quote: arne wrote on Tue, 20 March 2007 15:24
—————————————————-
> > The point I was trying to make is that you
> can create “a feedback loop” (as Vade would call) by asking Max to
> do too much in a scheduler cycle.

which is what happens when you have a few dozen
bigger loadbang jobs in your program.

#98490
Mar 21, 2007 at 9:06am

Hrm. Ive never seen this personally. Maybe I just have a patching
style or way of doing things that somehow inadvertently avoids some
of these issues (and uh, introduces others :).

On Mar 21, 2007, at 5:09 AM, Roman Thilenius wrote:

>
> Quote: arne wrote on Tue, 20 March 2007 15:24
> —————————————————-
>>> The point I was trying to make is that you
>> can create “a feedback loop” (as Vade would call) by asking Max to
>> do too much in a scheduler cycle.
>
>
> which is what happens when you have a few dozen
> bigger loadbang jobs in your program.
>
> –
> http://vst-mac.info/

v a d e //

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

#98491
Mar 21, 2007 at 7:14pm

Arne Eigenfeldt schrieb:
> For example, this type of programming can cause stack overflows
> (without any feedback loops):

Wrong, only with feedback it could create stack overflow. Without
feedback never, really never any opportunity to create a stack overflow
for the simple reason that an iterative structure doesn’t need and
doesn’t use a stack…

> Simply changing the structure to this format eliminates those stack
> overflows:

But this might scramble your order of execution… ;-)

Stefan


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

#98492
Mar 21, 2007 at 7:41pm

jbmaxwell schrieb:
> But, in my experience, when Max gets the spinning ball, then quits,
> it’s usually backlog.

If it quits there is a bug, even heavy backlog should not crash Max. You
can monitor the scheduler amount with the activity monitor of OS X…

I had backlog with spinning wheels which brought the GUI to a complete
halt, but Midi and Sound of my patch would still work!!! (Scary if it
happens during a concert… ;-)

If Max is beyond 70% you reach the dangerous area…

Stefan


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

#98493
Mar 21, 2007 at 8:04pm

> > For example, this type of programming can cause stack overflows

> Wrong, only with feedback it could create stack overflow.

Not according to Ben Neville:

http://www.cycling74.com/forums/index.php?
t=msg&rid=535&S=96deef46a861e2a6ab50ee92e7daf5a5&th=1665
1&goto=56119#msg_56124

This goes back to James’ problem: stack overflows and spinning balls
in complex code that works fine in chunks by asking the scheduler to
execute too much code at once.

As I said, I ran into this all the time, and now I don’t. The only thing
I’ve changed is liberally adding deferlow throughout my code.

#98494
Mar 22, 2007 at 12:51pm

Arne Eigenfeldt schrieb:
> Not according to Ben Neville:
>
> http://www.cycling74.com/forums/index.php?
> t=msg&rid=535&S=96deef46a861e2a6ab50ee92e7daf5a5&th=1665
> 1&goto=56119#msg_56124

Even according to Ben, the examples had a feedback, but would not always
create a stack overflow, thats the other way around.
As soon you have a patch cord or a send/receive going from the end back
to the beginning of your patch, the stack is involved. Without that
connection, no need for stackin’

But you’re right, with deferlow, you can break it up…

Stefan


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

#98495
Mar 23, 2007 at 3:34pm

Quote: arne wrote on Wed, 21 March 2007 20:04
—————————————————-
> > > For example, this type of programming can cause stack overflows
>
> > Wrong, only with feedback it could create stack overflow.
>
> Not according to Ben Neville:
>
> http://www.cycling74.com/forums/index.php?
> t=msg&rid=535&S=96deef46a861e2a6ab50ee92e7daf5a5&th=1665
> 1&goto=56119#msg_56124
>
> This goes back to James’ problem: stack overflows and spinning balls
> in complex code that works fine in chunks by asking the scheduler to
> execute too much code at once.
>
> As I said, I ran into this all the time, and now I don’t. The only thing
> I’ve changed is liberally adding deferlow throughout my code.
>
—————————————————-

This stuff really is tricky to keep straight. Thanks for linking that article, Arne. It’s great to get a “refresher” on that stuff. Looking over what Ben said again I really think we were having similar problems. I tend to control program flow through different subpatchers using trigger as well, and sometimes these subpatches can develop their own form of “sprawl”, with subpatches appearing another layer down. But this is just the sort of programming which seems totally reasonable from the documented function of the objects alone, and is thus a great example of what I was talking about earlier in this thread: the question of whether knowledge of the Max objects alone is really enough… and whether it *should* be enough. That’s pretty much a rhetorical question at this point, since I doubt there’s any way c74 could improve that situation anyway. I mean, they can’t possibly know the sort of madness we users are going to come up with! ;-)

It’s good to have a clear description of what deferlow is doing in these cases. Rather than semi-superstitiously plunking it into my patches, I think I have a pretty good idea now where it will actually be useful – the big thing for me is to realize that deferlow can act as a terminal point for a particular process. I’ll also keep in mind the idea of terminating sub-processes with a bang. This is not something I generally do, rather just relying on trigger, but it would probably be a useful trick now and then.

I also understand a bit more the points that came up earlier about the importance of knowing how Max works with the system. It’s somehow easy to get tricked into thinking of Max as though it’s some sort of direct path to the hardware – that I’m just building code to run on my machine. But if I try to picture Max as a program itself, with its own internal program flow, data structures, and routines for execution, then this stuff suddenly makes a lot more sense to me. Good to keep in mind.

cheers,

J.

#98496
Mar 23, 2007 at 4:38pm

jamez wrote:
> in regards to error debugging…., part of the beauty of debugging in max is that is almost exclusively manual. it really makes you mentally visualize your flow and think about what’s going wrong. I don’t know why anyone would want otherwise. But i realize I’m probably the minority here.

kudos to your brain if you can “mentally visualise” everything that’s
going on in a complex patch =-)

I for one would like a little bit less of “exclusively manual
debugging”. A big help would be menu items in a future debug menu like
“debug inlets” and “debug outlets” that switch on printing of everything
coming in or out of selected objects, with timetags.

> just say no to brainless over-efficiency.

I’d love to be efficient without even using my brain…
…Diemo


Diemo Schwarz, PhD — http://diemo.concatenative.net
Real-Time Music Interaction Team — http://www.ircam.fr/equipes/temps-reel
IRCAM – Centre Pompidou — 1, place Igor-Stravinsky, 75004 Paris, France
Phone +33-1-4478-4879 — Fax +33-1-4478-1540

#98497
Apr 7, 2007 at 2:22pm

#98498
Apr 7, 2007 at 4:58pm

On 7 Apr 2007, at 15:22, jeanfrancois.charles wrote:

> If you ask to process new events faster than the computer can
> physically do, it will stack things to process them later. If you
> keep asking (for instance with a metro), the stack will grow little
> by little until the overflow.

My instinct would tell me that’s not the case. The stack is used for
arguments and return addresses for (recursive) procedure calls; a
backed-up event queue is not recursive.

(Unless anyone at C’74 wants to reply from a more informed vantage
point.)

Nick Rothwell / Cassiel.com Limited
http://www.cassiel.com
http://www.myspace.com/cassieldotcom
http://www.loadbang.net

#98499
Apr 7, 2007 at 10:42pm

so this thread is still alive, fine, and it has successfully
moved to questions like “what Ben said about what a stack
overflow is” and “why we need better debugger tools such
as you find in procedural languages.”

the answer to the original question is an easier one.

that new collegue wanted to build a sample exact looper
system, because he thinks music made of loops is cool,
and he thinks you need a sample exact enviroment to make
loops for music.

both assumptions are wrong:
– music made of loops has stopped beeing cool in 1995,
– you do not need to work samplexact to make loop style music.

so use [groove~], have fun, and dont be afraid of sample offsets.

#98500
Apr 8, 2007 at 7:09am

#98501
Apr 8, 2007 at 8:17am

hm. I thought being cool stopped being cool, then again, what the
fuck do I know….

I agree with having fun, but sometimes fun wants to be sample
accurate too, eh?

On Apr 7, 2007, at 6:42 PM, Roman Thilenius wrote:

>
>
>
> so this thread is still alive, fine, and it has successfully
> moved to questions like “what Ben said about what a stack
> overflow is” and “why we need better debugger tools such
> as you find in procedural languages.”
>
> the answer to the original question is an easier one.
>
> that new collegue wanted to build a sample exact looper
> system, because he thinks music made of loops is cool,
> and he thinks you need a sample exact enviroment to make
> loops for music.
>
> both assumptions are wrong:
> – music made of loops has stopped beeing cool in 1995,
> – you do not need to work samplexact to make loop style music.
>
> so use [groove~], have fun, and dont be afraid of sample offsets.
> –
> http://vst-mac.info/

v a d e //

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

#98502
Apr 8, 2007 at 8:48am

On 7 Apr 2007, at 23:42, Roman Thilenius wrote:

> – music made of loops has stopped beeing cool in 1995,

Hmm. 12 years. Doesn’t that mean it’s back in fashion again? Judging
by the gigs I’m going to at the moment, I would say so…

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

#98503
Apr 8, 2007 at 8:56am

#98504
Apr 8, 2007 at 11:12am

Quote: Roman Thilenius wrote on Sat, 07 April 2007 15:42
—————————————————-
>
>
> so this thread is still alive, fine, and it has successfully
> moved to questions like “what Ben said about what a stack
> overflow is” and “why we need better debugger tools such
> as you find in procedural languages.”
>
> the answer to the original question is an easier one.
>
> that new collegue wanted to build a sample exact looper
> system, because he thinks music made of loops is cool,
> and he thinks you need a sample exact enviroment to make
> loops for music.
>
> both assumptions are wrong:
> – music made of loops has stopped beeing cool in 1995,
> – you do not need to work samplexact to make loop style music.
>
> so use [groove~], have fun, and dont be afraid of sample offsets.
—————————————————-

sample accuracy is not going to happen in every situation. yeah, i guess just make music. if max can do it reasonably well, then, well great. You’re going to have some inconsistencies. I think, well, perhaps i’m wrong, but that’s just one of the things that comes with running off an OS. I really dont know. Maybe if max had a customized OS built especially for just running IT such a goal would be obtainable. now i’m babbling. i’m half crazy here, oh yeah. i’m all souped up on texas tea and coffee too. its funny how when you’re drunk, you wanna tell people.

#98505
Apr 8, 2007 at 5:50pm

#98506
Jun 23, 2012 at 2:40pm

great! exaclty the post i was looking for… just new to max, and was searching for information about tight timing:) so 5years to late, but the timings great :)

#98507

You must be logged in to reply to this topic.